view Side-By-Side changes

Internet Draft                          C. Adams, Bell-Northern Research
draft-ietf-cat-spkmgss-00.txt                              June 20,
draft-ietf-cat-spkmgss-01.txt                           October 30, 1994


              The Simple Public-Key GSS-API Mechanism (SPKM)



STATUS OF THIS MEMO

   This document is an Internet Draft. Internet Drafts Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas, areas,
   and its Working Groups. working groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months. Internet Drafts
   months and may be updated, replaced, or obsoleted by
   other documents at any time. It is not appropriate inappropriate to use Internet Internet-
   Drafts as reference material or to cite them other than as a "working
   draft" or
   "work in progress."

   Please check the I-D abstract listing contained in each Internet
   Draft directory to

   To learn the current status of this or any other Internet Draft. Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

   Comments on this document should be sent to "cat-ietf@mit.edu", the
   IETF Common Authentication Technology WG discussion list.


ABSTRACT

   This specification defines protocols, procedures, and conventions to
   be employed by peers implementing the Generic Security Service
   Application Program Interface (as specified in RFCs 1508 and 1509)
   when using the Simple Public-Key Mechanism.


BACKGROUND

   Although the Kerberos Version 5 GSS-API mechanism [KRB5] is becoming well-
   established
   well-established in many environments, it is important in some
   applications to have a GSS-API mechanism which is based on a public-
   key, rather than a symmetric-key, infrastructure.  One such mechanism
   was described as part of the Distributed Authentication Security
   Service (DASS) in [RFC-1507].  However, the mechanism described in
   this document has been proposed as an alternative to the DASS
   mechanism for several reasons.

      1)  The SPKM is simpler than DASS, containing no non-essential
          functionality.




Adams                Document Expiration: 30 April 1995                1

      2)  The SPKM allows three-way both unilateral and mutual authentication, authentication
          to be accomplished without the use of secure timestamps,
          whereas DASS
          uses two-way mutual authentication; this requires timestamps for replay detection.  This
          enables environments which do not have access to secure timestamps time
          to nevertheless have access to secure mutual authentication.

Adams              Document Expiration: 31 December 1994              1

      3)  The SPKM uses Object Algorithm Identifiers to specify various
          algorithms to be used by the communicating peers.  This allows
          maximum flexibility for a variety of environments, for future
          enhancements, and for alternative algorithms.

      4)  The SPKM allows the option of a true, asymmetric algorithm-
          based, digital signature in the gss_sign() and gss_seal()
          operations, whereas DASS uses an integrity checksum based on a
          MAC computed with a symmetric algorithm (DES).  For some
          environments, the availability of true, non-repudiable digital
          signatures is a necessity.

      5)  SPKM data formats and procedures are designed to be as similar
          to those for the Kerberos mechanism as is practical.  This is
          done for ease of implementation in those environments where
          Kerberos has already been implemented.

   For the above reasons, it is felt that the SPKM will offer greater
   flexibility and functionality than DASS, without undue complexity or
   overhead.


KEY MANAGEMENT

   The key management employed in SPKM is intended to be as compatible
   as possible with both X.509 [X.509] and PEM [RFC-1422], since these
   represent large communities of interest and show relative maturity in
   standards.


ACKNOWLEDGMENTS

   Much of the material in this document is based on the Kerberos
   Version 5 GSS-API mechanism [KRB5], and is intended to be as
   compatible with it as possible.  This document also owes a great debt
   to Warwick Ford and Paul Van Oorschot of Bell-Northern Research for
   many fruitful
   discussions discussions, to Kelvin Desplanque of Domus Software
   for implementation-related clarifications, and to John Linn of
   OpenVision Technologies for helpful comments.











Adams                Document Expiration: 31 December 1994 30 April 1995                2
1. OVERVIEW

   The SPKM goal of the Generic Security Service Application Program
   Interface (GSS-API) is stated in the abstract of [RFC-1508] as
   follows:

     "This Generic Security Service Application Program Interface (GSS-
      API) definition provides security services to callers in a generic
      fashion, supportable with a range of underlying mechanisms and
      technologies and hence allowing source-level portability of
      applications to different environments. This specification defines
      GSS-API services and primitives at a level independent of
      underlying mechanism and programming language environment, and is
      to be complemented by other, related specifications:

       - documents defining specific parameter bindings for particular
         language environments;

       - documents defining token formats, protocols, and procedures to
         be implemented in order to realize GSS-API services atop
         particular security mechanisms."

   The SPKM is an instance of the latter type of document and is
   therefore termed a "GSS-API Mechanism".  This mechanism provides
   authentication, key establishment, data integrity, and data
   confidentiality in an on-line distributed application environment
   using a public-key infrastructure.  This
   mechanism  Because it conforms to the
   interface defined by the Generic Security
   Service Application Program Interface [RFC-1508] and [RFC-1508], SPKM can therefore be used as a drop-in
   replacement by any application which makes use of security services
   through GSS-API calls (for example, any application which already
   uses the Kerberos GSS-API for security).  The use of a public-key
   infrastructure allows, among other things, allows non-repudiable digital signatures to be
   employed for message exchanges.

   Note that this document defines two separate mechanisms, SPKM-1 exchanges, and
   SPKM-2, which provides other benefits such as
   scalability to large user populations.

   The tokens defined in SPKM are identical except that SPKM-2 requires the presence
   of secure timestamps for the purpose of replay detection during
   context establishment and SPKM-1 does not.  This allows greater
   flexibility for applications since secure timestamps can not always
   be guaranteed intended to be available in a given environment. used by application
   programs according to the GSS API "operational paradigm" (see
   [RFC-1508] for further details):

      The operational paradigm in which GSS-API operates is as follows.
      A typical GSS-API caller is itself a communications protocol [or
      is an application program which uses a communications protocol],
      calling on GSS-API in order to protect its communications with
      authentication, integrity, and/or confidentiality security
      services.  A GSS-API caller accepts tokens provided to it by its
      local GSS-API implementation [i.e., its GSS-API mechanism] and
      transfers the tokens to a peer on a remote system; that peer
      passes the received tokens to its local GSS-API implementation for
      processing.

   This document defines two separate GSS-API mechanisms, SPKM-1 and
   SPKM-2, which are identical except that SPKM-2 requires the presence
   of secure timestamps for the purpose of replay detection during
   context establishment and SPKM-1 does not.  This allows greater
   flexibility for applications since secure timestamps cannot always
   be guaranteed to be available in a given environment.

Adams                Document Expiration: 30 April 1995                3
2. ALGORITHMS

   A number of algorithm types are employed in SPKM.  Each type, along
   with its purpose and a set of specific examples, is described in this
   section.

2.1 Integrity Algorithm (INT_ALG): (I-ALG):

       Purpose:

         This algorithm is used to ensure that a message has not been
         altered in any way after being constructed by the legitimate
         sender.  Depending on the algorithm used, the application of
         this algorithm may also provide authenticity and non-
         repudiability for the message.

       Examples:

         md5WithRSA OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) oiw(14) secsig(3)
            algorithm(2) 3
         }

            This algorithm provides data integrity and non-repudiation
            by computing an RSA signature on the MD5 hash of that data.
            Note that this is equivalent to md5WithRSAEncryption {1 2
            840 113549 1 1 4}, which is defined in [PKCS].




Adams              Document Expiration: 31 December 1994              3 [PKCS1].



         DES-MAC OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) oiw(14) secsig(3)
            algorithm(2) 10
         }

            This algorithm provides data integrity by computing a DES
            MAC (as specified by [FIPS-113]) on that data.


            DES-CBC



         md5-DES-CBC OBJECT IDENTIFIER ::= { -- used only for gss_seal()
            iso(1) identified-organization(3) oiw(14) secsig(3)
               algorithm(2) 7               -- carries IV as a parameter xx
         }

            This algorithm provides data integrity by encrypting that
            data encrypting, using DES-CBC mode.  At
            DES CBC, the receiving end, MD5 hash of that data.  This will typically be
            faster in practice than computing a DES MAC if the
            decrypted input
            data is correctly padded AND not extremely short (e.g., a few bytes).  Note that
            the decrypted
            sequence number strength of this integrity mechanism is correct, then (at most) equal
            to the strength of DES under a known-plaintext attack.



         sum64-DES-CBC OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) xx
         }

Adams                Document Expiration: 30 April 1995                4

            This algorithm provides data integrity by encrypting, using
            DES CBC, the concatenation of the data was not altered. and the sum of all
            the input data blocks (the sum computed using addition
            modulo 2**64 - 1).  Thus, in this algorithm, encryption is a
            requirement for the integrity to be secure.

            For comments regarding the security of this mechanism, see
            [Juen84, Davi89].


2.2 Sequence Algorithm (SEQ_ALG): (S-ALG):

       Purpose:

         This symmetric algorithm is used to construct generate the encrypted
         sequence number for a token.  Because it makes use of both the (plaintext) sequence number and input to the
         integrity checksum, checksum (computed using an invalid message I-ALG) includes the
         encrypted sequence number, an invalid message with a valid
         sequence number, and a valid message with an invalid sequence
         number will both be detected.

       Examples:  (Note that here an invalid
         sequence number is one which decrypts to a value that the
         receiver was not expecting and an invalid message is one
         which causes the integrity check to fail.)

       Example:

         DES-CBC OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) oiw(14) secsig(3)
            algorithm(2) 7               -- carries IV as a parameter
         }


2.3 Confidentiality Algorithm (CONF_ALG): (C-ALG):

       Purpose:

         This symmetric algorithm is used to generate the encrypted
         data for gss_seal().

       Examples:

       Example:

         DES-CBC OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) oiw(14) secsig(3)
            algorithm(2) 7               -- carries IV as a parameter
         }











Adams                Document Expiration: 31 December 1994              4 30 April 1995                5

2.4 Key Establishment Algorithm (KEY_ESTB_ALG): (K-ALG):

       Purpose:

         This algorithm is used to establish a symmetric key for use
         by both the initiator and the target over the established
         context.  This  The keys used for S-ALG, C-ALG, and any keyed
         I-ALGs (for example, DES-MAC) are derived from this context key may
         key.  As will be used as the encryption /
            decryption seen in Section 3.1, key for either or both of SEQ_ALG establishment is
         done within the X.509 authentication exchange and CONF_ALG.

       Examples: so the
         resulting symmetric key is authenticated.

       Example:

         id-rsa-key-transport OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) oiw(14)
            secsig(3) algorithm(2) 22        -- imported from [X9.44]
         }

            In this algorithm, the context key is generated by the
            initiator, encrypted with the RSA public key of the target,
            and sent to the target.  The target need not respond to the
            initiator for the key to be established.


        dhKeyAgreement OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
           pkcs-3(3) 1
        }

            In this algorithm, the context key is generated jointly by
            the initiator and the target using the Diffie-Hellman key
            establishment algorithm.  The target must therefore respond
            to the initiator for the key to be established (so this
            K-ALG cannot be used with unilateral authentication in
            SPKM-2 (see Section 3.1)).



   During context establishment in SPKM, the initiator offers a set of
   possible symmetric encryption algorithms and a set of possible
   integrity algorithms to the target.  The symmetric algorithms
   selected by the target become ones that may be used for SEQ_ALG S-ALG and
   CONF_ALG
   C-ALG over the established context.  The integrity algorithms
   selected by the target become ones that may be used for INT_ALG I-ALG over
   the established context.  Note that the order of the selected
   integrity algorithms defines the values of the Quality of Protection
   (QOP) parameter used in the gss_sign() and gss_seal() calls -- see
   Section 5.2 for further details.

   In future versions of SPKM, other  Note also that if no response is
   expected from the target (unilateral authentication in SPKM-2) then
   the algorithms offered by the initiator are the ones that may be specified for any
   or all of INT_ALG, SEQ_ALG, CONF_ALG, and KEY_ESTB_ALG. used
   over the context (if this is unacceptable to the target then an error
   message must be sent to the initiator so that the context is never
   established).


Adams                Document Expiration: 31 December 1994              5
3. TOKEN FORMATS

   This section discusses protocol-visible characteristics 30 April 1995                6

   Furthermore, in the first context establishment token the initiator
   offers a set of possible K-ALGs, along with the GSS-
   API mechanism key (or key half)
   corresponding to be implemented atop the SPKM; first algorithm in the set (its preferred
   algorithm).  If this K-ALG is unacceptable to the target it defines elements must
   choose one of
   protocol for interoperability the other K-ALGs in the set and is independent of language bindings send this choice along
   with the key (or key half) corresponding to this choice in its
   response (otherwise an error token must be sent so that the context
   is never established).  If necessary (that is, if the target chooses
   a 2-pass K-ALG such as dhKeyAgreement), the initiator will send its
   key half in a response to the target.

   In future versions of SPKM, other algorithms may be specified for any
   or all of I-ALG, S-ALG, C-ALG, and K-ALG.


3. TOKEN FORMATS

   This section discusses protocol-visible characteristics of the GSS-
   API mechanism to be implemented atop the SPKM; it defines elements of
   protocol for interoperability and is independent of language bindings
   per [RFC-1509].

   The SPKM GSS-API mechanism will be identified by an Object Identifier
   representing "SPKM-1" or "SPKM-2", having the value:

   {iso(1), org(3), dod(5), internet(1), security(5), SPKM-1(xx)}
   or
   {iso(1), org(3), dod(5), internet(1), security(5), SPKM-2(xx)},

   where SPKM-1 uses 3-way mutual authentication random numbers for replay detection during context
   establishment and SPKM-2 uses 2-way mutual authentication for context
   establishment. timestamps.

   Tokens transferred between GSS-API peers (for security context
   management and per-message protection purposes) are defined.


3.1. Context Establishment Tokens

   Three classes of tokens are defined in this section:  "Initiator"
   tokens, emitted by calls to gss_init_sec_context() and consumed by
   calls to gss_accept_sec_context(); "Target" tokens, emitted by calls
   to gss_accept_sec_context() and consumed by calls to
   gss_init_sec_context(); and "Error" tokens, potentially emitted by
   calls to gss_init_sec_context(), gss_accept_sec_context(),
   gss_delete_sec_context(), gss_process_context_token(), gss_verify(),
   and gss_unseal() and consumed by calls to
   gss_process_context_token().


   Per RFC-1508, Appendix B, the initial context establishment token
   will be enclosed within framing as follows:





Adams                Document Expiration: 30 April 1995                7

   InitialContextToken ::=
   [APPLICATION 0] IMPLICIT SEQUENCE {
           thisMech        MechType
                   -- MechType is OBJECT IDENTIFIER
                   -- representing "SPKM-1" or "SPKM-2"
           innerContextToken ANY DEFINED BY thisMech
                   -- contents mechanism-specific
           }

   The innerContextToken of the initial context token will consist of an
   SPKM_REQ message, preceded by message containing a two-byte token-id (TOK_ID) field, field which shall
   contain the value 01 00. 0100 (hex).


   The above GSS-API framing shall be applied to all tokens emitted by
   the SPKM GSS-API mechanism, including SPKM_REP_TI, SPKM_REP_IT,
   SPKM_ERROR, context-deletion, and per-message tokens, not just to
   the initial token in a context establishment sequence.  While not
   required by RFC-1508, this enables implementations to perform
   enhanced error-checking. The innerContextToken field of context
   establishment tokens for the SPKM GSS-API mechanism will contain consist of a
   message (SPKM_REQ, SPKM_REP_TI, SPKM_REP_IT or SPKM_ERROR), preceded
   by SPKM_ERROR) containing
   a 2-byte TOK_ID field containing 01 00 having the value 0100 (hex) for SPKM_REQ messages, 02
   00
   0200 (hex) for SPKM_REP_TI messages, 03 00 0300 (hex) for SPKM_REP_IT
   messages, and 04
   00 0400 (hex) for SPKM_ERROR messages.  All
   innerContextTokens are encoded using Abstract Syntax Notation One
   Basic Encoding Rules (ASN.1 BER).

   The SPKM context establishment tokens are defined according to
   [X.509] Section 10.  SPKM-1 (random numbers) uses Section 10.3, "Two-
   way Authentication", when performing unilateral authentication of the
   target to the initiator and uses Section 10.4, "Three-way Authenti-
   cation", and Authentica-
   tion", when mutual authentication is requested by the initiator.
   SPKM-2 (timestamps) uses Section 10.2, "One-way Authentication", when
   performing unilateral authentication of the initiator to the target
   and uses Section 10.3, "Two-way Authentication" Authentication", when mutual authentication authen-
   tication is requested by the initiator.

Adams              Document Expiration: 31 December 1994              6

   Relevant SPKM_REQ syntax

   The implication of the above paragraph is as follows (note that imports from other
   documents are for SPKM-2 unilateral
   authentication no negotiation of K-ALG can be done (the target either
   accepts the K-ALG given in Appendix A):



   SPKM-REQ ::= [APPLICATION xx] SEQUENCE {
           certif_data [0]  CertificationData OPTIONAL
           requestToken [1] REQ_TOKEN
   }

   CertificationData by the initiator or disallows the context).
   For SPKM-2 mutual or SPKM-1 unilateral authentication some negotia-
   tion is possible, but the target can only choose among the one-pass
   K-ALGs offered by the initiator (or disallow the context).  For
   SPKM-1 mutual authentication the target can choose any one- or two-
   pass K-ALG offered by the initiator.

   It is envisioned that typical use of SPKM-1 or SPKM-2 will involve
   mutual authentication.  Although unilateral authentication is avail-
   able for both mechanisms, its use is not generally recommended.






Adams                Document Expiration: 30 April 1995                8

3.1.1. Context Establishment Tokens - Initiator (first token)

   In order to accomplish context establishment, it is necessary that
   both the initiator and the target have access to the other party?s
   encryption and verfication certificate(s).  In some environments the
   initiator may choose to acquire all certificates and send the
   relevant ones to the target in the first token.  In other environ-
   ments each side may individually obtain the certificate data it
   needs.  In either case, however, the SPKM implementation must have
   the ability to obtain certificates which correspond to a supplied
   Name.  The actual mechanism to be used to achieve this is a local
   implementation matter and is therefore outside the scope of this
   specification.



   Relevant SPKM_REQ syntax is as follows (note that imports from other
   documents are given in Appendix A):


   SPKM-REQ ::= SEQUENCE {
           requestToken [0] REQ_TOKEN
           certif_data [1]  CertificationData OPTIONAL
           auth_data [2]    AuthorizationData OPTIONAL
                         -- see [RFC-1510] for a discussion of auth-data
   }


   CertificationData ::= SEQUENCE {
           certificationPath [0]          CertificationPath
           certificateRevocationList [1]  CertificateList OPTIONAL
           }


   CertificationPath ::= SEQUENCE {
           userCertificate
           userEncCertif [0]     SingleCertificate
           theCACertificates
           userVerifCertif [1]   SingleCertificate OPTIONAL
                        -- may send separate verification certificate
                        -- to allow different algorithms to be used for
                        -- decryption and signing
           theCACertificates [2] SEQUENCE OF CertificatePair OPTIONAL
           }            -- certif. path from target to source


   SingleCertificate ::= CHOICE {               -- only one for now
           Certificate                          -- imported from [X.509]
           }                                    -- (1993)









Adams                Document Expiration: 30 April 1995                9

   REQ_TOKEN ::= SIGNED SEQUENCE {
           timestamp
           tok_id [0]       INTEGER  -- shall contain 0100 (hex)
           timestamp [1]    UTCTime  -- may be NULL for
                                               -- mechanism SPKM-1
           randSrc [1] [2]      Random_Integer,
           targ_name [2]    INTERNAL NAME,
           req_data [3]     Context_Data,
           key_estb_id    Name,
           src_name [4]  OBJECT IDENTIFIER     Name,
           req_data [5]     Context_Data,
           validity [6]     Validity  OPTIONAL
              -- specifies validity interval for key (may be used in the
              -- estb. mechanism computation of security context lifetime)
           key_estb_set [7] Key_Estb_Alg
              -- specifies set of key establishment algorithms
           key_estb_req [5] [8] BIT STRING
              -- key estb. request corresponding to first K-ALG in set
   }


   Random_Integer ::= BIT STRING

   Context_Data ::= SEQUENCE {
           channelId [0]   ChannelId,           -- channel bindings
           seq_number [1]  INTEGER OPTIONAL     -- sequence number
           options [2]     Options
           symm_alg [3]    Symm_Alg             -- symmetric enc. alg.
           intg_alg [4]    Intg_Alg             -- integrity algorithm
   }









Adams              Document Expiration: 31 December 1994              7

   ChannelId ::= OCTET STRING

   Options ::= BIT STRING {
           delegation_state (0),
           mutual_state (1),
           replay_det_state (2),
           sequence_state (3),
           conf_avail (4),
           integ_avail (5)
   }


   Symm_Alg ::= SEQUENCE OF OBJECT IDENTIFIER AlgorithmIdentifier -- for S-ALG, C-ALG
                                                -- (first id. in agreed
                                                -- set is default alg.
                                                -- for SEQ_ALG, CONF_ALG context)


   Intg_Alg ::= SEQUENCE OF OBJECT IDENTIFIER AlgorithmIdentifier -- order of agreed seq.
                                                -- sequence determines is constrained by
                                                -- meaning semantics of QOP
                                                -- parameter (see 5.2)

   Key_Estb_Alg ::= SEQUENCE OF AlgorithmIdentifier
                                                -- to allow negotiation
                                                -- of K-ALG



Adams                Document Expiration: 30 April 1995               10

   A context establishment sequence based on the SPKM will perform one-
   way uni-
   lateral authentication (without confirmation or any return token from
   target to initiator in response to the initiator's SPKM_REQ) if the mutual_req bit is not set in the
   application's call to gss_init_sec_context().  SPKM-2 accomplishes
   this using only SPKM_REQ (thereby authenticating the initiator to the
   target), while SPKM-1 accomplishes this using both SPKM_REQ and
   SPKM_REP_TI (thereby authenticating the target to the initiator).

   Applications requiring authentication of both peers (initiator as
   well as target) should request mutual authentication, resulting in
   "mutual_state" being set within SPKM_REQ Options.  In response to
   such a request, the context target will reply to the initiator with a
   token containing either an SPKM_REP_TI or SPKM_ERROR.  If mechanism
   SPKM-2 has been chosen, this completes the 2-way (timestamp-based) mutual
   authentication context establishment exchange.  If mechanism SPKM-1
   has been chosen and SPKM_REP_TI is sent, the initiator will then
   reply to the target with either an SPKM_REP_IT or SPKM_ERROR,
   completing the 3-way (random-number-based) mutual authentication context
   establishment exchange.


3.1.2. Context Establishment Tokens - Target

   Relevant SPKM_REP_TI syntax is as follows:

   SPKM_REP_TI ::= SIGNED SEQUENCE {
           timestamp
           tok_id [0]       INTEGER          -- shall contain 0200 (hex)
           timestamp [1]    UTCTime          -- may be NULL for
                                             -- mechanism SPKM-1
           randTarg [1] [2]     Random_Integer,
           src_name [2]     INTERNAL NAME,
           randSrc [3]     Name,
           randSrc [4]      Random_Integer,
           rep_data [4]     Context_Data,
           key_estb_rep [5] BIT STRING     Context_Data,
           key_estb_id [6]  AlgorithmIdentifier OPTIONAL
                 -- used if target is changing key estb. algorithm
                 -- (must be a member of initiator?s key_estb_set)
           key_estb_str [7] BIT STRING OPTIONAL
                 -- contains either the response to initiator?s
                 -- key_estb_req (if init. used a 2-pass K-ALG) or
                 -- the key_estb_req corresponding to K-ALG supplied
                 -- in above key_estb_id
   }








Adams              Document Expiration: 31 December 1994              8


3.1.3. Context Establishment Tokens - Initiator (second token)

   Relevant SPKM_REP_IT syntax is as follows:

   SPKM_REP_IT ::= SIGNED SEQUENCE {
           randTarg
           tok_id [0]       INTEGER  -- shall contain 0300 (hex)
           randTarg [1]     Random_Integer,
           targ_name [1]    INTERNAL NAME [2]    Name,
           key_estb_rep [3] BIT STRING OPTIONAL
                 -- contains the response to target?s key_estb_str
                 -- (if target selected a 2-pass K-ALG)
   }

Adams                Document Expiration: 30 April 1995               11

3.1.4. Error Token

   The syntax of SPKM_ERROR is as follows:

   SPKM_ERROR ::=   [APPLICATION xx]   SIGNED SEQUENCE {
           pvno[0]
           tok_id [0]       INTEGER,
           msg-type[1] -- shall contain 0400 (hex)
           pvno[1]          INTEGER, -- protocol version number
           error-code[2]    INTEGER,
           name[3]         INTERNAL NAME,
           guilty-seq[3]    OCTET STRING OPTIONAL,
                                     -- encrypted sequence number of the
                                     -- token which caused this error
                                     -- (empty if seq. nums not used)
           e-text[4]       GeneralString        PrintableString OPTIONAL,
           e-data[5]        OCTET STRING OPTIONAL
   }

   Values to be transferred in the error-code field of a SPKM_ERROR
   message are defined in Section 5 of this specification.

































Adams              Document Expiration: 31 December 1994              9



3.2. Per-Message and Context Deletion Tokens

   Three classes of tokens are defined in this section: "Sign" tokens,
   emitted by calls to gss_sign() and consumed by calls to gss_verify(), gss_verify();
   "Seal" tokens, emitted by calls to gss_seal() and consumed by calls
   to gss_unseal(), gss_unseal(); and context deletion tokens, emitted by calls to
   gss_delete_sec_context() and consumed by calls to
   gss_process_context_token().


3.2.1. Per-message Tokens - Sign

   Use of the gss_sign() call yields a token, separate from the user
   data being protected, which can be used to verify the integrity of
   that data as received.  The token has and the following format:

   # of Bytes       Name           Description
      2            TOK_ID          Identification field.
                                   Tokens emitted data are sent separately
   by gss_sign() contain the hex value 01 01 in this field.
   variable        INT_ALG         Integrity algorithm indicator (must
                                   be one of sending application and it is the agreed integrity
                                   algorithms for this context).
                                   OBJECT IDENTIFIER
   variable        SEQ_ALG         Encryption alg. receiving application's
   responsibility to compute sequence
                                   (must be associate the received data with the received
   token.

   The SPKM_SIGN token has the following format:


   SPKM_SIGN ::= SEQUENCE {
           sign_header [0]   Sign_Header,
           sign_body [1]     Sign_Body
   }









Adams                Document Expiration: 30 April 1995               12

   Sign_Header ::= SEQUENCE {
           tok_id [0]       INTEGER
                                -- shall contain 0101 (hex)
           int_alg [1]      AlgorithmIdentifier,
                                -- Integrity algorithm indicator (must
                                -- be one of the agreed symmetric integrity
                                -- algorithms for this context).
                                   OBJECT IDENTIFIER
      2            filler          Contains ff ff.
      2            INT_LEN         Contains bitlength
                                -- NULL = default id.
           seq_alg [2]      AlgorithmIdentifier,
                                -- Encryption alg. to compute sequence
                                -- (must be one of checksum.
      8            SND_SEQ         Sequence number field.
   variable        INT_CKSUM the agreed symmetric
                                -- algorithms for this context).
                                -- NULL = default id.
           snd_seq [3]      OCTET STRING,
                                -- Encrypted sequence number.
   }

   Sign_Body ::= SEQUENCE {
           int_cksum [0]    OCTET STRING
                                -- Checksum of "to-be-signed data", header and data,
                                -- calculated according to algorithm
                                -- specified in INT_ALG int_alg field.

   GSS-API tokens must be encapsulated within the higher-level protocol
   by the application; no embedded length field is necessary.
   }




3.2.1.1. Checksum

   Checksum calculation procedure (common to all algorithms): Checksums
   are calculated over the data field, logically prepended by the first
   8 bytes
   of the plaintext packet header. token header (sign_header).  The result binds the
   data to the packet type and integrity algorithm identifier fields. entire plaintext header, so as to minimize the possibil-
   ity of malicious splicing.

   For example, if the INT_ALG int_alg specifies the md5WithRSA algorithm, then
   the checksum is formed by computing an MD5 [RFC-1321] hash over the
   plaintext data, data (prepended by the header), and then computing an RSA
   signature [PKCS1] on the 16-byte MD5 result.  The signature is
   computed using the RSA private key retrieved from the credentials structure.  The
   structure and the result (of bitlength
   INT_LEN) (whose length is implied by the "modulus"
   parameter in the private key) is stored in the INT_CKSUM int_cksum field.  Note that for gss_sign(),
   INT_ALG cannot specify

   If the int_alg specifies a symmetric encryption algorithm. keyed hashing algorithm (for example,
   DES-MAC or md5-DES-CBC), then the key to be used is the established
   context key.  Again, the result (whose length is implied by int_alg)
   is stored in the int_cksum field.









Adams                Document Expiration: 31 December 1994              10 30 April 1995               13
3.2.1.2. Sequence Number

   Sequence number field: The 8 byte plaintext sequence number field

   It is
   formed from assumed that the sender's four-byte sequence number as follows.  If underlying transport layers (of whatever pro-
   tocol stack is being used by the four bytes application) will provide adequate
   communications reliability (that is, non-malicious loss, re-ordering,
   etc., of the sender's data packets will be handled correctly).  Therefore, enc-
   rypted sequence number numbers are named s0, s1, s2
   and s3 (from least used in SPKM purely for security, as
   opposed to most significant), the plaintext reliability, reasons (that is, to avoid malicious loss,
   replay, or re-ordering of SPKM tokens) -- note that sequence
   number field numbers
   are used so that there is no requirement for secure timestamps in the
   message tokens.  The initiator's initial sequence number for the
   current context may be explicitly given in the Context_Data field of
   SPKM_REQ and the target's initial sequence number may be explicitly
   given in the Context_Data field of SPKM_REP_TI; if either of these is
   not given then the default value of 00 is to be used.

   Sequence number field: The plaintext sequence number field is
   formed from the sender's four-byte sequence number as follows.  If
   the four bytes of the sender's sequence number are named s0, s1, s2
   and s3 (from least to most significant), the plaintext sequence
   number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di,
   di), where 'di' is the direction-indicator (Hex 0 00 - sender is the
   context initiator, Hex FF - sender is the context acceptor).

   The field is then CBC encrypted using the symmetric algorithm
   specified in SEQ_ALG, seq_alg, IV', and the context key, key.  (IV' is computed as
   the ECB decryption of the IV specified in seq_alg, using the context
   key and the symmetric algorithm specified in seq_alg.  The reason for
   having seq_alg convey an encrypted IV formed from the
   first 8 bytes of is to avoid revealing a known
   plaintext/ciphertext pair in the previously calculated INT_CKSUM field. token.)  The resulting encrypted
   sequence number is placed in snd_seq.  After sending a gss_sign() or
   gss_seal() token, the sender's sequence number is incremented by one.


3.2.1.3. Sequence Number Processing

   The receiver of the token will first verify the INT_CKSUM field.  If
   valid, decrypt the sequence number field may be decrypted
   using the context key and compared to compare it with the expected sequence
   number.  The repetition of the (effectively 1-bit) direction
   indicator within the sequence number field provides redundancy so
   that the receiver may verify that the decryption succeeded.

   Since the checksum computation encrypted sequence number is used as an IV part of the input to
   the sequence
   number decryption, integrity checksum, attempts to splice a checksum and sequence
   number from different messages will be detected.  The direction
   indicator will detect packets that have been maliciously reflected.


3.2.2. Per-message Tokens - Seal

   Use of the gss_seal() call yields a token which encapsulates the
   input in-
   put user data (optionally encrypted) along with associated integrity
   check quantities. The token emitted by gss_seal() consists of an
   integrity header whose format is identical to that emitted by
   gss_sign() (except that the TOK_ID field contains the value 02 01), followed by a body portion that contains either the
   plaintext data (if CONF_ALG conf_alg = ff ff) FFFF) or encrypted data for any other supported value (using the key
   specified in 3.2.2.4 with one of CONF_ALG. the agreed C-ALGs for this context).

Adams                Document Expiration: 31 December 1994              11 30 April 1995               14
   The gss_seal() SPKM_SEAL token has the following format:

   # of Bytes       Name           Description
      2            TOK_ID          Identification field.
                                   Tokens emitted by gss_seal()


   SPKM_SEAL ::= SEQUENCE {
           seal_header [0]   Seal_Header,
           seal_body [1]     Seal_Body
   }


   Seal_Header ::= SEQUENCE {
           tok_id [0]       INTEGER
                                -- shall contain
                                   the hex value 02 01 in this field.
   variable        INT_ALG 0201 (hex)
           int_alg [1]      AlgorithmIdentifier,
                                -- Integrity algorithm indicator (must
                                -- be one of the agreed integrity
                                -- algorithms for this context).
                                   OBJECT IDENTIFIER
   variable        SEQ_ALG         Encryption alg. to compute sequence
                                -- NULL = default id.
           seq_alg [2]      AlgorithmIdentifier,
                                -- Encryption alg. to compute sequence
                                -- (must be one of the agreed symmetric
                                -- algorithms for this context).
                                   OBJECT IDENTIFIER
   variable        CONF_ALG
                                -- NULL = default id.
           conf_alg [3]     AlgorithmIdentifier,
                                -- Confidentiality algorithm indicator
                                -- (must be 'ff ff' 'FFFF' or one of the agreed
                                -- symmetric algorithms for this
                                -- context).
                                   OBJECT IDENTIFIER
                                   ff ff - none
      2            INT_LEN         Contains bitlength of checksum.
      8            SND_SEQ
                                -- NULL = default id , 'FFFF' = none.
           snd_seq [4]      OCTET STRING,
                                -- Encrypted sequence number field.
   variable        INT_CKSUM number.
   }

   Seal_Body ::= SEQUENCE {
           int_cksum [0]    OCTET STRING
                                -- Checksum of plaintext padded header and data,
                                -- calculated according to algorithm
                                -- specified in INT_ALG int_alg field.
   variable        Data
           data [1]         OCTET STRING
                                -- encrypted or plaintext padded data


   GSS-API tokens must be encapsulated within data.
   }


3.2.2.1: Confounding

   As in [KRB5], an 8-byte random confounder is prepended to the higher-level protocol
   by data to
   compensate for the application; no embedded length field fact that an IV of zero is used for encryption.
   The result is necessary.


3.2.2.1. referred to as the "confounded" data field.


3.2.2.2. Checksum

   Checksum calculation procedure (common to all algorithms): Checksums
   are calculated over the plaintext padded data field, logically prepended by
   the first 8 bytes of the plaintext packet header.  The token header (seal_header).  As with
   gss_sign(), the result binds the data to the packet type, protocol version, and
   integrity algorithm identifier fields.

   For example, if the INT_ALG specifies entire plaintext header,
   so as to minimize the possibility of malicious splicing.

Adams                Document Expiration: 30 April 1995               15
   The examples for md5WithRSA algorithm, then
   the checksum is formed by computing an MD5 [RFC-1321] hash over the
   plaintext data, and DES-MAC are exactly as specified in
   3.2.1.1.

   If int_alg specifies md5-DES-CBC and conf_alg specifies anything
   other than DES-CBC, then computing an RSA signature on the 16-byte
   MD5 result.  The signature checksum is computed using the RSA private key
   retrieved from according to
   3.2.1.1 and the credentials structure. The result (of bitlength
   INT_LEN) is stored in the INT_CKSUM field.

   As another example, int_alg.  However, if the INT_ALG conf_alg
   specifies a symmetric encryption
   algorithm such as the DES-CBC algorithm -- note that this is
   allowable for gss_seal() but not for gss_sign() -- then the encrypted
   data itself acts as encryption and the checksum (therefore CONF_ALG must integrity can be the same done
   as INT_ALG).  In this case follows.  An MD5 [RFC-1321] hash is computed over the INT_CKSUM field contains plaintext
   data (prepended by the last
   eight bytes header).  This 16-byte value is appended to
   the concatenation of the encrypted "confounded" data and INT_LEN contains the value 64.

Adams              Document Expiration: 31 December 1994              12



3.2.2.2 Sequence Number

   Sequence number field: The 8 byte plaintext sequence number field is
   formed from the sender's four-byte sequence number as follows.  If
   the four 1-8 padding bytes of the sender's sequence number are named s0, s1, s2
   and s3 (from least to most significant), the plaintext sequence
   number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di,
   di), where 'di' is the direction-indicator (Hex 0 - sender is the
   context initiator, Hex FF - sender (the
   padding is the context acceptor). as specified in [KRB5] for DES-CBC).  The field result is
   then CBC encrypted using the symmetric algorithm
   specified in SEQ_ALG, the context key, key and an IV formed from placed in the
   first 8 bytes "data"
   field of Seal_Body.  The final two blocks of ciphertext (i.e., the INT_CKSUM field.

   After sending a gss_sign() or gss_seal() token, the sender's sequence
   numbers
   encrypted MD5 hash) are incremented also placed in the int_cksum field of
   Seal_Body as the integrity checksum.

   If int_alg specifies sum64-DES-CBC then conf_alg must specify DES-CBC
   (i.e., confidentiality must be requested by one.


3.2.2.3: Padding

   Data padding: Before encryption and/or the calling application
   or SPKM will return an error).  Encryption and integrity checksum
   calculation, are done in
   a single pass using the context key as follows.  The sum (modulo
   2**64 - 1) of all plaintext data blocks (prepended by the header) is padded
   computed.  This 8-byte value is appended to the next highest multiple concatenation of
   8 bytes, by appending between 1 the
   "confounded" data and 8 bytes, 1-8 padding bytes (the padding is as specified
   in [KRB5] for DES-CBC).  As above, the value of each such
   byte being result is then CBC encrypted
   and placed in the total number "data" field of pad bytes.  For example, given data Seal_Body.  The final block of
   length 20 bytes, four pad bytes will be appended, and each byte will
   contain
   ciphertext (i.e., the hex value 04.  An 8-byte random confounder encrypted sum) is prepended
   to also placed in the int_cksum
   field of Seal_Body as the data, and integrity checksums checksum.


3.2.2.3 Sequence Number

   Encrypted sequence numbers are calculated over the
   resulting padded plaintext.

   After padding, the computed and processed for gss_seal()
   exactly as specified in 3.2.1.2 and 3.2.1.3.


3.2.2.4: Data Encryption

   The following procedure is followed unless (a) conf_alg is Hex FFFF,
   or (b) conf_alg is DES-CBC and int_alg is md5-DES-CBC, or (c) int_alg
   is sum64-DES-CBC:

   The "confounded" data is padded and encrypted according to the
   algorithm specified in the CONF_ALG conf_alg field.  The data is encrypted
   using CBC with an IV of zero.  The key used is derived from the
   established context key by XOR-ing the context key with the  hexadecimal hexadeci-
   mal constant
   f0f0f0f0f0f0f0f0.




















Adams              Document Expiration: 31 December 1994              13 F0F0F0...F0 (this ensures that the key used for encryp-
   tion and the key used for a separate, keyed integrity algorithm --
   for example DES-MAC, but not sum64-DES-CBC -- are different).


3.2.3. Context deletion token

   The token emitted by gss_delete_sec_context() is based on the packet
   format for tokens emitted by gss_sign().



Adams                Document Expiration: 30 April 1995               16

   The context-deletion SPKM_DEL token has the following format:

   # of Bytes       Name           Description
      2            TOK_ID          Identification field.
                                   Tokens emitted by
                                   gss_delete_sec_context()

   SPKM_DEL ::= SEQUENCE {
           del_header [0]   Del_Header,
           del_body [1]     Del_Body
   }

   Del_Header ::= SEQUENCE {
           tok_id [0]       INTEGER
                                -- shall contain
                                   the hex value 01 02 in this field.
   variable        INT_ALG 0301 (hex)
           int_alg [1]      AlgorithmIdentifier,
                                -- Integrity algorithm indicator (must
                                -- be one of the agreed integrity
                                -- algorithms for this context).
                                   OBJECT IDENTIFIER
   variable        SEQ_ALG
                                -- NULL = default id.
           seq_alg [2]      AlgorithmIdentifier,
                                -- Encryption alg. to compute sequence
                                -- (must be one of the agreed symmetric
                                -- algorithms for this context).
                                   OBJECT IDENTIFIER
      2            filler          Contains ff ff.
      2            INT_LEN         Contains bitlength of checksum.
      8            SND_SEQ         Sequence number field.
   variable        INT_CKSUM
                                -- NULL = default id.
           snd_seq [3]      OCTET STRING,  -- Encrypted sequence number.
   }

   Del_Body ::= SEQUENCE {
           int_cksum [0]    OCTET STRING
                                -- Checksum of "to-be-signed data", header, calculated
                                -- according to algorithm specified
                                -- in INT_ALG int_alg field.



   SND_SEQ
   }

   snd_seq will be calculated as for tokens emitted by gss_sign().  The
   INT_CKSUM
   int_cksum will be calculated as for tokens emitted by gss_sign(),
   except that the user-data component of the "to-be-signed" checksum data will be a
   zero-length string.






















Adams              Document Expiration: 31 December 1994              14



4. NAME TYPES AND OBJECT IDENTIFIERS

   No name types have yet been defined for SPKM.  This section is for
   further study.



5. PARAMETER DEFINITIONS

   This section defines parameter values used by the SPKM GSS-API
   mechanism.  It defines interface elements in support of portability.








Adams                Document Expiration: 30 April 1995               17

5.1. Minor Status Codes

   This section recommends common symbolic names for minor_status values
   to be returned by the SPKM GSS-API mechanism.  Use of these
   definitions will enable independent implementors to enhance
   application portability across different implementations of the
   mechanism defined in this specification.  (In all cases,
   implementations of gss_display_status() will enable callers to
   convert minor_status indicators to text representations.) Each
   implementation should make available, through include files or other
   means, a facility to translate these symbolic names into the concrete
   values which a particular GSS-API implementation uses to represent
   the minor_status values specified in this section.  It is recognized
   that this list may grow over time, and that the need for additional
   minor_status codes specific to particular implementations may arise.

5.1.1. Non-SPKM-specific codes

   (Note that other codes may be added in the future.)

   GSS_S_G_NOUSER
       /* "UID does not resolve to username" */

   GSS_S_G_VALIDATE_FAILED
       /* "Validation error" */
   GSS_S_G_BUFFER_ALLOC
       /* "Couldn't allocate gss_buffer_t data" */
   GSS_S_G_BAD_MSG_CTX
       /* "Message context invalid" */
   GSS_S_G_WRONG_SIZE
       /* "Buffer is the wrong size" */
   GSS_S_G_BAD_USAGE
       /* "Credential usage type is unknown" */
   GSS_S_G_UNAVAIL_QOP
       /* "Unavailable quality of protection specified" */






Adams              Document Expiration: 31 December 1994              15

5.1.2. SPKM-specific-codes

   (Note that other codes may be added in the future.)

   GSS_SPKM_S_KG_CCACHE_NOMATCH
       /* "Principal in credential cache does not match desired name" */
   GSS_SPKM_S_KG_CONTEXT_ESTABLISHED

   GSS_SPKM_S_SG_CONTEXT_ESTABLISHED
       /* "Context is already fully established" */
   GSS_SPKM_S_KG_BAD_INT_ALG_TYPE
   GSS_SPKM_S_SG_BAD_INT_ALG_TYPE
       /* "Unknown integrity algorithm type in token" */
   GSS_SPKM_S_KG_BAD_LENGTH
   GSS_SPKM_S_SG_BAD_SYMM_ALG_TYPE
       /* "Invalid field length "Unknown symmetric algorithm type in token" */
   GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_TYPE
       /* "Unknown key establishment algorithm type in token" */
   GSS_SPKM_S_KG_CTX_INCOMPLETE
   GSS_SPKM_S_SG_CTX_INCOMPLETE
       /* "Attempt to use incomplete security context" */
   GSS_SPKM_S_SG_BAD_INT_ALG_SET
       /* "No integrity algorithm in common from offered set" */
   GSS_SPKM_S_SG_BAD_SYMM_ALG_SET
       /* "No symmetric algorithm in common from offered set" */
   GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_SET
       /* "No key establishment algorithm in common from offered set" */
   GSS_SPKM_S_SG_INVALID_TOKEN_DATA
       /* "Data is improperly formatted:  cannot encode into token" */
   GSS_SPKM_S_SG_INVALID_TOKEN_FORMAT
       /* "Received token is improperly formatted:  cannot decode" */



Adams                Document Expiration: 30 April 1995               18

5.2. Quality of Protection Values

   Quality of Protection (QOP) values are defined for the SPKM GSS-API
   mechanism, and are used as input to gss_sign() and gss_seal() to
   select among alternate integrity-checking algorithms.  Once a set of
   algorithms has been agreed upon by the context initiator and target,
   the QOP parameter simply selects from this ordered set.

   More specifically, the SPKM_REQ token may send a sequence of "n" OBJ. Alg.
   IDs specifying integrity-checking algorithms supported by the
   initiator.  The target may support only a subset m (m <= n) of these,
   and so will return the sequence of "m" OBJ. Alg. IDs which it supports in
   the SPKM_REP_TI token.  The first OBJ. Alg. ID is therefore the default
   algorithm (QOP = 0), and the next m-1 are used for QOP = 1 through
   QOP = m-1, respectively.  Any QOP value greater than or equal to m is
   equated to m-1 and is therefore mapped to the last OBJ. Alg. ID in the
   agreed set.

   To aid in implementation and interoperability, the following
   stipulations are made.  The set of n OBJ. Alg. IDs sent by the initiator
   must contain at least one specifying an algorithm which computes a true
   digital signature, signature in the first position, and must contain at least one
   specifying any other (non-signature) integrity algorithm, and may contain at least
   one specifying a symmetric algorithm. algorithm in the
   second position.  The set of m OBJ. Alg. IDs returned by the target must
   also contain one specifying an algorithm which computes a true
   digital signature in the first position, must contain and one specifying a (non-signature) (non-
   signature) integrity algorithm in the second
   position, position.

   Note that if the SPKM_REP_TI token is not used (unilateral authen-
   tication using SPKM-2), then m=n and must contain one specifying a symmetric encryption
   algorithm or NULL in the final position.







Adams              Document Expiration: 31 December 1994              16 "agreed" set of Alg. IDs is
   simply taken to be the initiator's set.

   The reason for these stipulations is to allow the QOP parameter to
   convey the semantics of the desired integrity service without forcing
   it to specify the actual algorithms to be used.  The result is that
   the application is always able to choose, in a completely general and
   portable way, an integrity service which provides non-repudiation
   semantics (by passing QOP = Hex 00), and one which does not provide non-
   repudiation
   non-repudiation semantics (by passing QOP = Hex 01), and one which uses
   encryption for both integrity and confidentiality -- if this is
   available over the established context -- (by passing QOP = Hex FF). 01).  Note that an
   application which is aware of its own underlying environment and/or
   is aware of the underlying environment of its peer is not unduly
   constrained by the above stipulations because any other number or
   kind of algorithms may be agreed upon during context establishment,
   making other QOP values perfectly valid and meaningful over that
   context and between those peers.



6. SECURITY CONSIDERATIONS

   Security issues are discussed throughout this memo.





Adams                Document Expiration: 30 April 1995               19
7. REFERENCES

   [Davi89]:    D. W. Davies and W. L. Price, "Security for Computer
   Networks", Second Edition, John Wiley and Sons, New York, 1989.

   [FIPS-113]:  National Bureau of Standards, Federal Information
   Processing Standard 113, "Computer Data Authentication", May 1985.

   [Juen84]:    R. R. Jueneman, C. H. Meyer and S. M. Matyas, ~Message
   Authentication with Manipulation Detection Codes?, in Proceedings of
   the 1983 IEEE Symposium on Security and Privacy, IEEE Computer
   Society Press, 1984, pp.33-54..

   [KRB5]:      J. Linn, "The Kerberos Version 5 GSS-API Mechanism",
   Internet Draft draft-ietf-cat-kerb5gss-01.

   [PKCS1]:     RSA Encryption Standard, Version 1.5, RSA Data Security,
   Inc., Nov. 1993.

   [PKCS3]:     Diffie-Hellman Key-Agreement Standard, Version 1.4, RSA
   Data Security, Inc., Nov. 1993.

   [RFC-1321]:  R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321.

   [RFC-1422]:  S. Kent, "Privacy Enhancement for Internet Electronic
   Mail:  Part II: Certificate-Based Key Management", RFC 1422.

   [RFC-1507]:  C. Kaufman, "DASS:  Distributed Authentication Security
   Service", RFC 1507.

   [RFC-1508]:  J. Linn, "Generic Security Service Application Program
   Interface", RFC 1508.

   [RFC-1509]:  J. Wray, "Generic Security Service Application Program
   Interface: C-bindings", RFC 1509.

   [RFC-1510]:  J. Kohl and C. Neuman, "The Kerberos Network
   Authentication Service (V5)", RFC 1510.

   [KRB5]:      J. Linn, "The Kerberos Version 5 GSS-API Mechanism",
   Internet Draft draft-ietf-cat-kerb5gss-00.

   [FIPS-113]:  National Bureau of Standards, Federal Information
   Processing Standard 113, "Computer Data Authentication", May 1985.

   [PKCS]:      RSA Encryption Standard, Version 1.4, RSA Data Security,
   Inc., June 3, 1991.

   [X.509]:     ISO/IEC 9594-8, "Information Technology - Open Systems
   Interconnection - The Directory:  Authentication Framework", CCITT
   Recommendation X.509. X.509, 1993.

   [X9.44]:     ANSI, "Public Key Cryptography Using Reversible
   Algorithms for the Financial Services Industry:  Transport of
   Symmetric Algorithm Keys Using RSA", X9.44-1993.

Adams              Document Expiration: 31 December 1994              17

8. AUTHOR'S ADDRESS

   Carlisle Adams
   Bell-Northern Research, Ltd.
   P.O.Box 3511, Station C
   Ottawa, Ontario, CANADA  K1Y 4H7

   Phone: +1 613.763.9008
   E-mail: cadams@bnr.ca

Adams                Document Expiration: 31 December 1994              18 30 April 1995               20


Appendix:  IMPORTS

A.1 ASN.1 encoding

   The following definitions are taken from X.501 and X.509.

   --CCITT Definitions:

   joint-iso-ccitt      OBJECT IDENTIFIER ::= {2}
   ds                   OBJECT IDENTIFIER ::= {joint-iso-ccitt 5}
   algorithm            OBJECT IDENTIFIER ::= {ds 8}
   encryptionAlgorithm  OBJECT IDENTIFIER ::= {algorithm 1}
   hashAlgorithm        OBJECT IDENTIFIER ::= {algorithm 2}
   signatureAlgorithm   OBJECT IDENTIFIER ::= {algorithm 3}
   rsa                  OBJECT IDENTIFIER ::= {encryptionAlgorithm 1}

   iso                  OBJECT IDENTIFIER ::= {1}
   identified-organization OBJECT IDENTIFIER ::= {iso 3}


   --1989 OSI Implementors Workshop "Stable" Agreements

   oiw                OBJECT IDENTIFIER ::= {identified-organization 14}
   dssig                  OBJECT IDENTIFIER ::= {oiw 7}
   oiwAlgorithm           OBJECT IDENTIFIER ::= {dssig 2}
   oiwEncryptionAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 1}
   oiwHashAlgorithm       OBJECT IDENTIFIER ::= {oiwAlgorithm 2}
   oiwSignatureAlgorithm  OBJECT IDENTIFIER ::= {oiwAlgorithm 3}


   --PKCS #1 definition [PKCS] [PKCS1]

   rsaEncryption OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
           pkcs-1(1) 1
   }


   --PKCS #3 definition [PKCS3]

   dhKeyAgreement OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
           pkcs-3(3) 1
   }

   -- the parameter to be used with this algorithm is

   DHParameter ::= SEQUENCE {
           prime              INTEGER,  -- p
           base               INTEGER,  -- g
           privateValueLength INTEGER OPTIONAL
   }



Adams                Document Expiration: 30 April 1995               21
   --X.501 definitions

   AttributeType ::= OBJECT IDENTIFIER
   AttributeValue ::= ANY
   AttributeValueAssertion ::= SEQUENCE {AttributeType,AttributeValue}

   Name ::= CHOICE {       --only one for now
                   RDNSequence
                   }
   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
   DistinguishedName ::= RDNSequence

   RelativeDistinguishedName ::= SET OF AttributeValueAssertion




Adams              Document Expiration: 31 December 1994              19


   --X.509 definitions (with proposed 1992 extensions presumed)

   ENCRYPTED MACRO ::=
   BEGIN
   TYPE NOTATION   ::= type(ToBeEnciphered)
   VALUE NOTATION  ::= value(VALUE BIT STRING)
   END     -- of ENCRYPTED


   SIGNED MACRO    ::=
   BEGIN
   TYPE NOTATION   ::= type (ToBeSigned)
   VALUE NOTATION  ::= value (VALUE
   SEQUENCE{
           ToBeSigned,
           AlgorithmIdentifier,    --of the algorithm used to
                                   --generate the signature
           ENCRYPTED OCTET STRING  --where the octet string is the
                                   --result of the hashing of the
                                   --value of "ToBeSigned"
           }
                           )
   END     -- of SIGNED


   SIGNATURE MACRO ::=
   BEGIN
   TYPE NOTATION   ::= type (OfSignature)
   VALUE NOTATION  ::= value (VALUE
   SEQUENCE {
           AlgorithmIdentifier,    --of the algorithm used to compute
           ENCRYPTED OCTET STRING  -- the signature where the octet
                                   -- string is a function (e.g., a
                                   -- compressed or hashed version)
                                   -- of the value 'OfSignature',
                                   -- which may include the
                                   -- identifier of the algorithm
                                   -- used to compute the signature
           }
                           )
   END     -- of SIGNATURE

Adams                Document Expiration: 30 April 1995               22


   Certificate ::= SIGNED SEQUENCE {
           version [0]        Version DEFAULT v1,
           serialNumber [1]   CertificateSerialNumber,
           signature [2]      AlgorithmIdentifier,
           issuer [3]         Name,
           validity [4]       Validity,
           subject [5]        Name,
           subjectPublicKeyInfo [6] SubjectPublicKeyInfo,
           issuerUID [1] [7]      IMPLICIT UID OPTIONAL,  -- used in v2 only
           subjectUID [2] [8]     IMPLICIT UID OPTIONAL   -- used in v2 only
           }

Adams              Document Expiration: 31 December 1994              20

   Version ::= INTEGER {v1(0), v2(1)}

   CertificateSerialNumber ::= INTEGER

   Validity ::= SEQUENCE {
           NotBefore         UTCTime,
           NotAfter          UTCTime
           }

   AlgorithmIdentifier ::= SEQUENCE {
           algorithm         OBJECT IDENTIFIER,
           parameter         ANY DEFINED BY algorithm OPTIONAL
           }

   SubjectPublicKeyInfo ::= SEQUENCE {
           algorithm         AlgorithmIdentifier,
           subjectPublicKey  BIT STRING
           }

   UID ::= BIT STRING



   CertificatePair ::= SEQUENCE {
           forward [0]      SingleCertificate OPTIONAL,
           reverse [1]      SingleCertificate OPTIONAL
           }            -- at least one of the pair shall be present

   CertificateList ::= SIGNED SEQUENCE {
           signature [0]           AlgorithmIdentifier,
           issuer [1]              Name,
           thisUpdate [2]          UTCTime,
           nextUpdate [3]          UTCTime OPTIONAL,
           revokedCertificates [4] SEQUENCE OF SEQUENCE {
                userCertificate       CertificateSerialNumber,
                revocationDate        UTCTime
                } OPTIONAL
           }





Adams                Document Expiration: 31 December 1994              21 30 April 1995               23

   AuthorizationData ::=   SEQUENCE OF SEQUENCE {
                           ad-type[0]               INTEGER,
                           ad-data[1]               OCTET STRING
   }

     -- ad-data   This field contains authorization data to be
     --           interpreted according to the value of the
     --           corresponding ad-type field.

     -- ad-type   This field specifies the format for the ad-data
     --           subfield.  All negative values are reserved for
     --           local use.  Non-negative values are reserved for
     --           registered use.







A.2 Encoding Rules

   Whenever a structure is to be signed it must always be constructed
   the same way. This is particularly important where a signed structure
   has to be reconstructed by the recipient before the signature is
   verified. The rules listed below are taken from X.509.

    - the definite form of length encoding shall be used, encoded in
      the minimum number of octets;

    - for string types, the constructed form of encoding shall not
      be used;

    - if the value of a type is its default value, it shall be
      absent;

    - the components of a Set type shall be encoded in ascending
      order of their tag value; values;

    - the components of a Set-of type shall be encoded in ascending
      order of their octet value; values;

    - if the value of a Boolean type is true, the encoding shall
      have its contents octet set to `FF'16; Hex 'FF';

    - each unused bits in the final octet of the encoding of a BitString
      value, if there are any, shall be set to zero;

    - the encoding of a Real type shall be such that bases 8, 10 and
      16 shall not  be used, and the binary scaling factor shall be
      zero.





Adams                Document Expiration: 31 December 1994              22 30 April 1995               24

----