Internet Draft                          C. Adams, Bell-Northern Research
draft-ietf-cat-spkmgss-03.txt                                May 5, 1995


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



STATUS OF THIS MEMO

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

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

   To learn the current status of any Internet 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 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:  5 Nov. 1995                 1

      2)  The SPKM allows both unilateral and mutual authentication 
          to be accomplished without the use of secure timestamps, 
          whereas DASS requires timestamps for replay detection.  This 
          enables environments which do not have access to secure time 
          to nevertheless have access to secure authentication. 

      3)  The SPKM uses 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 (now called gss_getMIC() and gss_wrap() in [GSSv2], 
          whereas DASS uses an integrity checksum based on a MAC 
          computed with a symmetric algorithm (DES).  For some 
          environments, the availability of true digital signatures 
          supporting non-repudiation is a necessity.

      5)  SPKM data formats and procedures are designed to be as similar 
          to those of 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, to Kelvin Desplanque of Domus Software 
   for implementation-related clarifications, and to John Linn of 
   OpenVision Technologies for helpful comments.










Adams                Document Expiration:  5 Nov. 1995                 2
1. OVERVIEW

   The 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.  Because it conforms to the 
   interface defined by [RFC-1508], SPKM can 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 digital signatures supporting non-repudiation 
   to be employed for message exchanges, and provides other benefits 
   such as scalability to large user populations.

   The tokens defined in SPKM are intended to be 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, whose primary difference is 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:  5 Nov. 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.  In order to ensure at least a minimum level of interoper-
   ability among various implementations of SPKM, one of the integrity 
   algorithms is specified as MANDATORY; all remaining examples (and 
   any other algorithms) may optionally be supported by a given SPKM 
   implementation (note that a GSS-conformant mechanism need not support 
   confidentiality).  Making a confidentiality algorithm mandatory may 
   preclude exportability of the mechanism implementation; this document 
   therefore specifies certain algorithms as RECOMMENDED (that is, 
   interoperability will be enhanced if these algorithms are included in 
   all SPKM implementations for which exportability is not a concern).

2.1 Integrity Algorithm (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 support non-
         repudiation for the message.

       Examples:

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

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

            Note that since this is the only integrity/authenticity 
            algorithm specified to be mandatory at this time, for 
            interoperability reasons it is also stipulated that 
            md5WithRSA be the algorithm used to sign all context 
            establishment tokens (with the possible exception of the 
            initial token in SPKM-1 -- see Section 3.1.1 for details).  
            In future versions of this document, alternate or additional 
            algorithms may be specified to be mandatory and so this 
            stipulation on the context establishment tokens may be 
            removed.









Adams                Document Expiration:  5 Nov. 1995                 4

         DES-MAC OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) oiw(14) secsig(3) 
            algorithm(2) 10
         }

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



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

            This algorithm provides data integrity by encrypting, using
            DES CBC, the MD5 hash of that data.  This will typically be
            faster in practice than computing a DES MAC unless the input
            data is extremely short (e.g., a few bytes).  Note that the
            strength of this integrity mechanism is (at most) equal to
            the strength of DES under a known-plaintext attack.



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

            This algorithm provides data integrity by encrypting, using
            DES CBC, the concatenation of the data 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 integrity 
            algorithm, see [Juen84, Davi89].


2.2 Confidentiality Algorithm (C-ALG):

       Purpose:

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

       Example:

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

         This algorithm is RECOMMENDED.



Adams                Document Expiration:  5 Nov. 1995                 5
2.3 Key Establishment Algorithm (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.  The keys used for C-ALG and any keyed I-ALGs (for 
         example, DES-MAC) are derived from this context key.  As will 
         be seen in Section 3.1, key establishment is done within the 
         X.509 authentication exchange and so the resulting shared
         symmetric key is authenticated.

       Examples:

         RSAEncryption OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
           pkcs-1(1) 1        -- imported from [PKCS1] and [RFC-1423]
         }

            In this algorithm (MANDATORY), 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.

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

            Similar to RSAEncryption, but source authenticating info.
            is also encrypted with the target's RSA public key.

        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 confidentiality algorithms and a set of possible integrity 
   algorithms to the target (note that the term "integrity algorithms" 
   includes digital signature algorithms).  The confidentiality 
   algorithms selected by the target become ones that may be used for 
   C-ALG over the established context, and the integrity algorithms 
   selected by the target become ones that may be used for I-ALG over 
   the established context (the target "selects" algorithms by 
   returning, in the same relative order, the subset of each offered 
   list that it supports).  Note that any C-ALG and I-ALG may be used 
   for any message over the context and that the first confidentiality 
   algorithm and the first integrity algorithm in the agreed sets become 
   the default algorithms for that context.
Adams                Document Expiration:  5 Nov. 1995                 6
   The agreed confidentiality and integrity algorithms for a specific 
   context define the valid values of the Quality of Protection (QOP) 
   parameter used in the gss_getMIC() and gss_wrap() calls -- see 
   Section 5.2 for further details.  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 used over the 
   context (if this is unacceptable to the target then a delete token 
   must be sent to the initiator so that the context is never 
   established).

   Furthermore, in the first context establishment token the initiator 
   offers a set of possible K-ALGs, along with the key (or key half) 
   corresponding to the first algorithm in the set (its preferred 
   algorithm).  If this K-ALG is unacceptable to the target then the 
   target must choose one of the other K-ALGs in the set and send this 
   choice along with the key (or key half) corresponding to this choice 
   in its response (otherwise a delete 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, C-ALG, and K-ALG.


3. TOKEN FORMATS

   This section discusses protocol-visible characteristics of 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 random numbers for replay detection during context 
   establishment and SPKM-2 uses timestamps (note that for both 
   mechanisms, sequence numbers are used to provide replay and out-of-
   sequence detection during the context, if this has been requested by 
   the application).

   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() and gss_accept_sec_context(), 
   and potentially consumed by calls to gss_init_sec_context() and 
   gss_accept_sec_context().

Adams                Document Expiration:  5 Nov. 1995                 7

   Per RFC-1508, Appendix B, the initial context establishment token 
   will be enclosed within framing as follows:

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

   The above GSS-API framing shall be applied to all tokens emitted by 
   the SPKM GSS-API mechanism, including SPKM_REP_TI (the response from 
   the Target to the Initiator), SPKM_REP_IT (the response from the 
   Initiator to the Target), 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.  Furthermore, 
   every innerContextToken will contain a token-id followed by a 
   context-id.  See Section 6 for a discussion of these two fields and 
   their use in an SPKM support function.

   The innerContextToken field of context establishment tokens for the 
   SPKM GSS-API mechanism will consist of a message (SPKM_REQ, 
   SPKM_REP_TI, SPKM_REP_IT or SPKM_ERROR) containing a tok_id field 
   having the value 0100 (hex) for SPKM_REQ messages, 0200 (hex) for 
   SPKM_REP_TI messages, 0300 (hex) for SPKM_REP_IT messages, and 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 and are compatible with [9798].  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 Authentication", 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", when mutual authentication is 
   requested by the initiator.

   The implication of the above paragraph is that for SPKM-2 unilateral 
   authentication no negotiation of K-ALG can be done (the target either 
   accepts the K-ALG and key given by the initiator or disallows the 
   context).  For SPKM-2 mutual or SPKM-1 unilateral authentication some 
   negotiation is possible, but the target can only choose among the 
   one-pass K-ALGs offered by the initiator (or disallow the context).  
   Alternatively, the initiator can request that the target generate and 
   transmit the context key.  For SPKM-1 mutual authentication the 
   target can choose any one- or two-pass K-ALG offered by the initiator 
   and, again, can be requested to generate and transmit the key.

   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:  5 Nov. 1995                 8

3.1.1. Context Establishment Tokens - Initiator (first token)

   In order to accomplish context establishment, it may be necessary 
   that both the initiator and the target have access to the other 
   party?s public-key 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 the initiator may request that the target send certificate data 
   in its response token, or each side may individually obtain the 
   certificate data it needs.  In any 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      REQ_TOKEN,
           req_integrity     Req_Integrity,
           certif_data [2]   CertificationData OPTIONAL,
           auth_data [3]     AuthorizationData OPTIONAL
              -- see [RFC-1510] for a discussion of auth-data
   }


   Req_Integrity ::= CHOICE {
           sig_integ [0] SIGNATURE REQ_TOKEN,
           mac_integ [1] MAC REQ_TOKEN
   }  -- the MAC choice can be used only for SPKM-1 and only if 
      -- REQ_TOKEN contains (in key_estb_req) the symmetric key to be 
      -- used over the context.
      -- Note that the MAC choice reduces processing overhead for SPKM-1 
      -- and allows initiator anonymity in the case of unilateral 
      -- authentication.


   MAC MACRO ::=
   BEGIN
      TYPE  NOTATION ::= type  ( ToBeMACed )
      VALUE NOTATION ::= value ( VALUE SEQUENCE {
               algId     AlgorithmIdentifier,
               mac       BIT STRING             } )
      -- must be the result of applying the MACing procedure specified 
      -- by algId to the BER-encoded octets of a value of ToBeMACed (the 
      -- context key is to be used as an input to the MACing procedure)
   END

   CertificationData ::= SEQUENCE {
           certificationPath [0]          CertificationPath OPTIONAL,
           certificateRevocationList [1]  CertificateList OPTIONAL
   }  -- at least one of the above shall be present

Adams                Document Expiration:  5 Nov. 1995                 9

   CertificationPath ::= SEQUENCE {
           userKeyId [0]         OCTET STRING OPTIONAL,
              -- identifier for user's public key
           userCertif [1]        Certificate OPTIONAL,
              -- certificate containing user's public key
           verifKeyId [2]        OCTET STRING OPTIONAL,
              -- identifier for user's public verification key
           userVerifCertif [3]   Certificate OPTIONAL,
              -- certificate containing user's public verification key
           theCACertificates [4] SEQUENCE OF CertificatePair OPTIONAL
              -- certification path from target to source
   }

   -- Having separate verification fields allows different key pairs 
   -- (possibly corresponding to different algorithms) to be used for 
   -- encryption/decryption and signing/verification.
   -- Presence of [0] or [1] and absence of [2] and [3] implies that the 
   -- same key pair is to be used for enc/dec and verif/signing (note 
   -- that this practice is not typically recommended).
   -- Presence of [2] or [3] implies that a separate key pair is to be 
   -- used for verif/signing, and so [0] or [1] must also be present.
   -- Presence of [4] implies that at least one of [0], [1], [2], and 
   -- [3] must also be present.

   REQ_TOKEN ::= SEQUENCE {
           tok_id           INTEGER,       -- shall contain 0100 (hex)
           context_id       Random_Integer,   -- see Section 6.3
           pvno             BIT STRING,       -- protocol version number
           timestamp        UTCTime OPTIONAL, -- mandatory for SPKM-2
           randSrc          Random_Integer,
           targ_name        Name,
           src_name         Name, 
              -- may be a value indicating "anonymous"
           req_data         Context_Data,
           validity [0]     Validity OPTIONAL,
              -- validity interval for key (may be used in the
              -- computation of security context lifetime)
           key_estb_set [1] Key_Estb_Algs,
              -- specifies set of key establishment algorithms
           key_estb_req      BIT STRING OPTIONAL,
              -- key estb. parameter corresponding to first K-ALG in set
              -- (not used if initiator is unable or unwilling to 
              -- generate and securely transmit key material to target).
              -- Established key must be sufficiently long to be used
              -- with any of the offered confidentiality algorithms.
           key_src_bind      HASHED SEQUENCE {
                   src_name  Name,
                   symm_key  BIT STRING      } OPTIONAL
              -- used to bind the source name to the symmetric key 
              -- (i.e., the unprotected version of what is trans-
              -- mitted in key_estb_req).  This field must be present 
              -- for the case of SPKM-2 unilateral authentication if 
              -- the K-ALG in use does not provide such a binding (but 
              -- is optional for all other cases).
           }

Adams                Document Expiration:  5 Nov. 1995                10

   HASHED MACRO ::=
   BEGIN
      TYPE  NOTATION ::= type  ( ToBeHashed )
      VALUE NOTATION ::= value ( VALUE OCTET STRING )
   END -- hash used is the one specified for the MANDATORY I-ALG

   -- The protocol version number (pvno) parameter is a BIT STRING which 
   -- uses as many bits as necessary to specify all the SPKM protocol 
   -- versions supported by the initiator (one bit per protocol 
   -- version).  The protocol specified by this document is version 0.  
   -- Bit 0 of pvno is therefore set if this version is supported; 
   -- similarly, bit 1 is set if version 1 (if defined in the future) is 
   -- supported, and so on.  Note that for unilateral authentication 
   -- using SPKM-2, no response token is expected during context 
   -- establishment, so no protocol negotiation can take place.  In this 
   -- case, the initiator must set exactly one bit of pvno.

   -- The "validity" parameter above is the only way within SPKM for 
   -- the initiator to transmit desired context lifetime to the target.  
   -- Since it cannot be guaranteed that the initiator and target have 
   -- synchronized time, the span of time specified by "validity" is to 
   -- be taken as definitive (rather than the actual times given in this 
   -- parameter).

   Random_Integer ::= BIT STRING

   -- Each SPKM implementation is responsible for generating a "fresh" 
   -- random number for the purpose of context establishment; that is, 
   -- one which (with high probability) has not been used previously.  
   -- There are no cryptographic requirements on this random number 
   -- (i.e., it need not be unpredictable, it simply needs to be fresh).

   Context_Data ::= SEQUENCE {
           channelId       ChannelId,          -- channel bindings
           seq_number      INTEGER OPTIONAL,   -- sequence number
           options         Options,
           conf_alg        Conf_Algs,          -- confidentiality. algs.
           intg_alg        Intg_Algs           -- integrity algorithm
   }

   ChannelId ::= OCTET STRING

   Options ::= BIT STRING {
           delegation_state (0),
           mutual_state (1),
           replay_det_state (2), -- used for replay det. during context
           sequence_state (3),   -- used for sequencing during context
           conf_avail (4),
           integ_avail (5),
           target_certif_data_required (6)
                                 -- used to request targ's certif. data
   }




Adams                Document Expiration:  5 Nov. 1995                11

   Conf_Algs ::= CHOICE {
           SEQUENCE OF AlgorithmIdentifier,
           NULL  -- used when conf. is not requested over context
   } -- for C-ALG (see Section 5.2 for discussion of QOP)

   Intg_Algs ::= SEQUENCE OF AlgorithmIdentifier 
       -- for I-ALG (see Section 5.2 for discussion of QOP)

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

   A context establishment sequence based on the SPKM will perform 
   unilateral authentication 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) must 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 
   an SPKM_REP_TI token.  If mechanism SPKM-2 has been chosen, this 
   completes the (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 
   an SPKM_REP_IT token, completing the (random-number-based) mutual 
   authentication context establishment exchange.

   Other bits in the Options field of Context_Data are explained in 
   RFC-1508, with the exception of target_certif_data_required, which 
   the initiator sets to TRUE to request that the target return its 
   certification data in the SPKM_REP_TI token.  For unilateral authen-
   tication in SPKM-2 (in which no SPKM_REP_TI token is constructed),
   this option bit is ignored by both initiator and target.

3.1.2. Context Establishment Tokens - Target

   SPKM_REP_TI ::= SEQUENCE {
           responseToken    REP_TOKEN,
           certif_data      CertificationData OPTIONAL
             -- included if target_certif_data_required option was 
             -- set to TRUE in SPKM_REQ
   }












Adams                Document Expiration:  5 Nov. 1995                12




   REP_TOKEN ::= SIGNED SEQUENCE {
           tok_id           INTEGER,         -- shall contain 0200 (hex)
           context_id       Random_Integer,  -- see Section 6.3
           pvno [0]         BIT STRING OPTIONAL, -- prot. version number
           timestamp [1]    UTCTime OPTIONAL, -- mandatory for SPKM-2
           randTarg [2]     Random_Integer,
           src_name         Name,  -- the src_name specified in REQ
           targ_name        Name,
           randSrc          Random_Integer,
           rep_data         Context_Data,
           validity [3]     Validity  OPTIONAL,
             -- validity interval for key (used if the target can only 
             -- support a shorter context lifetime than was offered in 
             -- REQ_TOKEN)
           key_estb_id [4]  AlgorithmIdentifier OPTIONAL,
             -- used if target is changing key estb. algorithm (must be 
             -- a member of initiator?s key_estb_set)
           key_estb_str      BIT STRING OPTIONAL
             -- contains (1) the response to the initiator?s 
             -- key_estb_req (if init. used a 2-pass K-ALG), or (2) the 
             -- key_estb_req corresponding to the K-ALG supplied in 
             -- above key_estb_id, or (3) the key_estb_req corresponding 
             -- to the first K-ALG supplied in initiator's key_estb_id, 
             -- if initiator's (OPTIONAL) key_estb_req was not used 
             -- (target's key_estb_str must be present in this case).
             -- Established key must be sufficiently long to be 
             -- used with any of the offered conf. algorithms.
           }

   -- The protocol version number (pvno) parameter is a BIT STRING which 
   -- uses as many bits as necessary to specify a single SPKM protocol 
   -- version offered by the initiator which is supported by the target 
   -- (one bit per protocol version); that is, the target sets exactly 
   -- one bit of pvno.  If none of the versions offered by the initiator 
   -- are supported by the target, a delete token must be returned so 
   -- that the context is never established.  If the initiator's pvno 
   -- has only one bit set and the target happens to support this 
   -- protocol version, then this version is used over the context 
   -- and the pvno parameter of REP_TOKEN can be omitted.

3.1.3. Context Establishment Tokens - Initiator (second token)

   Relevant SPKM_REP_IT syntax is as follows:

   SPKM_REP_IT ::= SIGNED SEQUENCE {
           tok_id           INTEGER,  -- shall contain 0300 (hex)
           context_id       Random_Integer,
           randSrc          Random_Integer,
           randTarg         Random_Integer,
           targ_name        Name,  -- the targ_name specified in REP_TI
           src_name         Name,  -- the src_name specified in REQ
           key_estb_rep     BIT STRING OPTIONAL
                 -- contains the response to target?s key_estb_str
                 -- (if target selected a 2-pass K-ALG)
           }

Adams                Document Expiration:  5 Nov. 1995                13

3.1.4. Error Token

   The syntax of SPKM_ERROR is as follows:

   SPKM_ERROR ::=   SIGNED SEQUENCE {
           tok_id           INTEGER, -- shall contain 0400 (hex)
           context_id       Random_Integer
           }

   The SPKM_ERROR token is used only during the context establishment 
   process.  If an SPKM_REQ or SPKM_REP_TI token is received in error, 
   the receiving function (either gss_init_sec_context() or 
   gss_accept_sec_context()) will generate an SPKM_ERROR token to be 
   sent to the peer (if the peer is still in the context establishment 
   process) and will return GSS_S_CONTINUE_NEEDED.  If, on the other 
   hand, no context establishment response is expected from the peer 
   (i.e., the peer has completed context establishment), the function 
   will return the appropriate major status code (e.g., GSS_S_BAD_SIG)
   along with a minor status of GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT and all 
   context-relevant information will be deleted.  The output token will 
   not be an SPKM_ERROR token but will instead be an SPKM_DEL token 
   which will be processed by the peer's gss_process_context_token().

   If gss_init_sec_context() receives an error token (whether valid or 
   invalid), it will regenerate SPKM_REQ as its output token and return 
   a major status code of GSS_S_CONTINUE_NEEDED.  (Note that if the 
   peer's gss_accept_sec_context() receives SPKM_REQ token when it is 
   expecting a SPKM_REP_IT token, it will ignore SPKM_REQ and return a 
   zero-length output token with a major status of 
   GSS_S_CONTINUE_NEEDED.)

   Similarly, if gss_accept_sec_context() receives an error token 
   (whether valid or invalid), it will regenerate SPKM_REP_TI as its 
   output token and return a major status code of GSS_S_CONTINUE_NEEDED.

   md5WithRsa does not include modulus bitlength as a parameter, yet 
   this algorithm is currently stipulated for the signing of context 
   establishment tokens.  Discrepancies can be resolved through 
   judicious use of the SPKM_ERROR token.  The context initiator signs 
   REQ_TOKEN using the strongest RSA it supports (e.g., 1024 bits).  If 
   the target is unable to verify signatures of this length, it sends 
   SPKM_ERROR signed with the strongest RSA that it supports (e.g. 512).

   At the completion of this exchange, both sides know what RSA 
   bitlength the other supports, since the size of the signature is 
   equal to the size of the modulus.  Further exchanges can be made 
   (using successively smaller supported bitlengths) until either an 
   agreement is reached or context establishment is aborted because no 
   agreement is possible.







Adams                Document Expiration:  5 Nov. 1995                14

3.2. Per-Message and Context Deletion Tokens

   Three classes of tokens are defined in this section: "MIC" tokens, 
   emitted by calls to gss_getMIC() and consumed by calls to 
   gss_verifyMIC(); "Wrap" tokens, emitted by calls to gss_wrap() and 
   consumed by calls to gss_unwrap(); and context deletion tokens, 
   emitted by calls to gss_init_sec_context(), gss_accept_sec_context(), 
   or gss_delete_sec_context() and consumed by calls to 
   gss_process_context_token().


3.2.1. Per-message Tokens - Sign / MIC

   Use of the gss_sign() / gss_getMIC() 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 and the data may be 
   sent separately by the sending application and it is the receiving 
   application's responsibility to associate the received data with the 
   received token.

   The SPKM_MIC token has the following format:

   SPKM_MIC ::= SEQUENCE {
           mic_header       Mic_Header,
           int_cksum        BIT STRING
                                -- Checksum over header and data,
                                -- calculated according to algorithm
                                -- specified in int_alg field.
   }

   Mic_Header ::= SEQUENCE {
           tok_id           INTEGER,
                                -- shall contain 0101 (hex)
           context_id       Random_Integer,
           int_alg          AlgorithmIdentifier OPTIONAL,
                                -- Integrity algorithm indicator (must
                                -- be one of the agreed integrity
                                -- algorithms for this context).
                                -- field not present = default id.
           snd_seq          SeqNum OPTIONAL  -- sequence number field.
   }

   SeqNum ::= SEQUENCE {
           num      INTEGER, -- the sequence number itself
           dir_ind  BOOLEAN  -- a direction indicator
   }

3.2.1.1. Checksum

   Checksum calculation procedure (common to all algorithms -- note that 
   for SPKM the term "checksum" includes digital signatures as well as 
   hashes and MACs): Checksums are calculated over the data field, 
   logically prepended by the bytes of the plaintext token header 
   (mic_header).  The result binds the data to the entire plaintext 
   header, so as to minimize the possibility of malicious splicing.

Adams                Document Expiration:  5 Nov. 1995                15
   For example, if the int_alg specifies the md5WithRSA algorithm, then 
   the checksum is formed by computing an MD5 [RFC-1321] hash over the 
   plaintext 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 and the result (whose length is implied by the "modulus" 
   parameter in the private key) is stored in the int_cksum field.

   If the int_alg specifies a 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.

3.2.1.2. Sequence Number

   It is assumed that the underlying transport layers (of whatever pro-
   tocol stack is being used by the application) will provide adequate 
   communications reliability (that is, non-malicious loss, re-ordering,
   etc., of data packets will be handled correctly).  Therefore, 
   sequence numbers are used in SPKM purely for security, as opposed to 
   reliability, reasons (that is, to avoid malicious loss, replay, or 
   re-ordering of SPKM tokens) -- it is therefore recommended that
   applications request sequencing and replay detection over all 
   contexts.  Note that sequence 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 sequence number field is formed from the 
   sender's four-byte sequence number and a Boolean direction-
   indicator (FALSE - sender is the context initiator, TRUE - sender 
   is the context acceptor).  After constructing a gss_sign() or 
   gss_seal() (gss_getMIC() or gss_wrap()) token, the sender's sequence 
   number is incremented by one.

3.2.1.3. Sequence Number Processing

   The receiver of the token will verify the sequence number field by 
   comparing the sequence number with the expected sequence number and 
   the direction indicator with the expected direction indicator.  If 
   the sequence number in the token is higher than the expected number, 
   then the expected sequence number is adjusted and GSS_S_GAP_TOKEN is 
   returned.  If the token sequence number is lower than the expected 
   number, then the expected sequence number is not adjusted and 
   GSS_S_DUPLICATE_TOKEN or GSS_S_OLD_TOKEN is returned, whichever is 
   appropriate.  If the direction indicator is wrong, then the expected 
   sequence number is not adjusted and GSS_S_UNSEQ_TOKEN is returned

   Since the sequence number is used as part of the input to the 
   integrity checksum, sequence numbers need not be encrypted, and 
   attempts to splice a checksum and sequence number from different 
   messages will be detected.  The direction indicator will detect 
   tokens which have been maliciously reflected.

Adams                Document Expiration:  5 Nov. 1995                16

3.2.2. Per-message Tokens - Seal / Wrap

   Use of the gss_seal() / gss_wrap() call yields a token which 
   encapsulates the input user data (optionally encrypted) along with 
   associated integrity check quantities. The token emitted by 
   gss_seal() / gss_wrap() consists of an integrity header followed by a 
   body portion that contains either the plaintext data (if conf_alg = 
   NULL) or encrypted data (using the key specified in 3.2.2.4 with one 
   of the agreed C-ALGs for this context).

   The SPKM_WRAP token has the following format:

   SPKM_WRAP ::= SEQUENCE {
           wrap_header       Wrap_Header,
           wrap_body         Wrap_Body
   }

   Wrap_Header ::= SEQUENCE {
           tok_id           INTEGER,
                                -- shall contain 0201 (hex)
           context_id       Random_Integer,
           int_alg [0]      AlgorithmIdentifier OPTIONAL,
                                -- Integrity algorithm indicator (must
                                -- be one of the agreed integrity
                                -- algorithms for this context).
                                -- field not present = default id.
           conf_alg [1]     Conf_Alg OPTIONAL,
                                -- Confidentiality algorithm indicator
                                -- (must be NULL or one of the agreed
                                -- confidentiality algorithms for this
                                -- context).
                                -- field not present = default id.
                                -- NULL = none (no conf. applied).
           snd_seq          SeqNum OPTIONAL
                                -- sequence number field.
   }



   Wrap_Body ::= SEQUENCE {
           int_cksum        BIT STRING,
                                -- Checksum of header and data,
                                -- calculated according to algorithm
                                -- specified in int_alg field.
           data             BIT STRING
                                -- encrypted or plaintext data.
   }

   Conf_Alg ::= CHOICE {
           AlgorithmIdentifier,
           NULL
   }




Adams                Document Expiration:  5 Nov. 1995                17

3.2.2.1: Confounding

   As in [KRB5], an 8-byte random confounder is prepended to the data to 
   compensate for the fact that an IV of zero is used for encryption.  
   The result is 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 data field, logically prepended by 
   the bytes of the plaintext token header (wrap_header).  As with 
   gss_sign() / gss_getMIC(), the result binds the data to the entire 
   plaintext header, so as to minimize the possibility of malicious 
   splicing.

   The examples for md5WithRSA 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 the checksum is computed according to 
   3.2.1.1 and the result is stored in int_cksum.  However, if conf_alg 
   specifies DES-CBC then the encryption and the integrity is done 
   as follows.  An MD5 [RFC-1321] hash is computed over the plaintext 
   data (prepended by the header).  This 16-byte value is appended to 
   the concatenation of the "confounded" data and 1-8 padding bytes (the 
   padding is as specified in [KRB5] for DES-CBC).  The result is 
   then CBC encrypted using the context key and placed in the "data" 
   field of Wrap_Body.  The final two blocks of ciphertext (i.e., the 
   encrypted MD5 hash) are also placed in the int_cksum field of 
   Wrap_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 the calling application 
   or SPKM will return an error).  Encryption and integrity 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 
   computed.  This 8-byte value is appended to the concatenation of the 
   "confounded" data and 1-8 padding bytes (the padding is as specified 
   in [KRB5] for DES-CBC).  As above, the result is then CBC encrypted 
   and placed in the "data" field of Wrap_Body.  The final block of 
   ciphertext (i.e., the encrypted sum) is also placed in the int_cksum 
   field of Wrap_Body as the integrity checksum.


3.2.2.3 Sequence Number

   Sequence numbers are computed and processed for gss_wrap() exactly 
   as specified in 3.2.1.2 and 3.2.1.3.







Adams                Document Expiration:  5 Nov. 1995                18

3.2.2.4: Data Encryption

   The following procedure is followed unless (a) conf_alg is NULL (no 
   encryption), or (b) conf_alg is DES-CBC and int_alg is md5-DES-CBC 
   (encryption as specified in 3.2.2.2), or (c) int_alg is sum64-DES-CBC 
   (encryption as specified in 3.2.2.2):

   The "confounded" data is padded and encrypted according to the 
   algorithm specified in the 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 hexadeci- 
   mal constant 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 format 
   for tokens emitted by gss_sign() / gss_getMIC().

   The SPKM_DEL token has the following format:


   SPKM_DEL ::= SEQUENCE {
           del_header       Del_Header,
           int_cksum        BIT STRING
                                -- Checksum of header, calculated
                                -- according to algorithm specified
                                -- in int_alg field.
   }

   Del_Header ::= SEQUENCE {
           tok_id           INTEGER,
                                -- shall contain 0301 (hex)
           context_id       Random_Integer,
           int_alg          AlgorithmIdentifier OPTIONAL,
                                -- Integrity algorithm indicator (must
                                -- be one of the agreed integrity
                                -- algorithms for this context).
                                -- field not present = default id.
           snd_seq          SeqNum OPTIONAL
                                -- sequence number field.
   }


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




Adams                Document Expiration:  5 Nov. 1995                19

   If a valid delete token is received, then the SPKM implementation 
   will delete the context and gss_process_context_token() will return a 
   major status of GSS_S_COMPLETE and a minor status of 
   GSS_SPKM_S_SG_CONTEXT_DELETED.  If, on the other hand, the delete 
   token is invalid, the context will not be deleted and 
   gss_process_context_token() will return the appropriate major status 
   (GSS_S_BAD_SIG, for example) and a minor status of 
   GSS_SPKM_S_SG_BAD_DELETE_TOKEN_RECD.  The application may wish to 
   take some action at this point to check the context status (such as 
   sending a sealed/wrapped test message to its peer and waiting for a 
   sealed/wrapped response).


4. NAME TYPES AND OBJECT IDENTIFIERS

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

4.1. Optional Name Forms

   This section discusses name forms which may optionally be supported 
   by implementations of the SPKM GSS-API mechanism.  It is recognized 
   that OS-specific functions outside GSS-API are likely to exist in 
   order to perform translations among these forms, and that GSS-API 
   implementations supporting these forms may themselves be layered atop 
   such OS-specific functions.  Inclusion of this support within GSS-API 
   implementations is intended as a convenience to applications.

4.1.1. User Name Form

   This name form shall be represented by the Object Identifier {iso(1)
   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
   generic(1) user_name(1)}.  The recommended symbolic name for this
   type is "GSS_SPKM_NT_USER_NAME".

   This name type is used to indicate a named user on a local system.
   Its interpretation is OS-specific.  This name form is constructed as:

   username


4.1.2. Machine UID Form

   This name form shall be represented by the Object Identifier {iso(1)
   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
   generic(1) machine_uid_name(2)}.  The recommended symbolic name for
   this type is "GSS_SPKM_NT_MACHINE_UID_NAME".

   This name type is used to indicate a numeric user identifier
   corresponding to a user on a local system.  Its interpretation is
   OS-specific.  The gss_buffer_desc representing a name of this type
   should contain a locally-significant uid_t, represented in host byte
   order.  The gss_import_name() operation resolves this uid into a
   username, which is then treated as the User Name Form.


Adams                Document Expiration:  5 Nov. 1995                20
4.1.3. String UID Form

   This name form shall be represented by the Object Identifier {iso(1)
   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
   generic(1) string_uid_name(3)}.  The recommended symbolic name for
   this type is "GSS_SPKM_NT_STRING_UID_NAME".

   This name type is used to indicate a string of digits representing
   the numeric user identifier of a user on a local system.  Its
   interpretation is OS-specific. This name type is similar to the
   Machine UID Form, except that the buffer contains a string
   representing the uid_t.


5. PARAMETER DEFINITIONS

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

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 must 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 (Minor Status Code MSB, bit 31, SET)

5.1.1.1. GSS-Related codes (Minor Status Code bit 30 SET)

   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" */

5.1.1.2. Implementation-Related codes (Minor Status Code bit 30 OFF)

   GSS_S_G_MEMORY_ALLOC
       /* "Couldn't perform requested memory allocation" */

Adams                Document Expiration:  5 Nov. 1995                21
5.1.2. SPKM-specific-codes (Minor Status Code MSB, bit 31, OFF)

   GSS_SPKM_S_SG_CONTEXT_ESTABLISHED
       /* "Context is already fully established" */
   GSS_SPKM_S_SG_BAD_INT_ALG_TYPE
       /* "Unknown integrity algorithm type in token" */
   GSS_SPKM_S_SG_BAD_CONF_ALG_TYPE
       /* "Unknown confidentiality algorithm type in token" */
   GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_TYPE
       /* "Unknown key establishment algorithm type in token" */
   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_CONF_ALG_SET
       /* "No confidentiality 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_NO_PVNO_IN_COMMON
       /* "No protocol version number 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" */
   GSS_SPKM_S_SG_CONTEXT_DELETED
       /* "Context deleted at peer's request" */
   GSS_SPKM_S_SG_BAD_DELETE_TOKEN_RECD
       /* "Invalid delete token received -- context not deleted" */
   GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT
      /* "Unrecoverable context establishment error. Context deleted" */

5.2. Quality of Protection Values

   The Quality of Protection (QOP) parameter is used in the SPKM GSS-API 
   mechanism as input to gss_sign() and gss_seal() (gss_getMIC() and 
   gss_wrap()) to select among alternate confidentiality and 
   integrity-checking algorithms.  Once these sets of algorithms have 
   been agreed upon by the context initiator and target, the QOP 
   parameter simply selects from these ordered sets.

   More specifically, the SPKM_REQ token sends an ordered sequence of 
   Alg. IDs specifying integrity-checking algorithms supported by the 
   initiator and an ordered sequence of Alg. IDs specifying 
   confidentiality algorithms supported by the initiator.  The target 
   returns the subset of the offered integrity-checking Alg. IDs which 
   it supports and the subset of the offered confidentiality Alg. IDs 
   which it supports in the SPKM_REP_TI token (in the same relative 
   orders as those given by the initiator).  Thus, the initiator and 
   target each know the algorithms which they themselves support and the 
   algorithms which both sides support (the latter are defined to be 
   those supported over the established context).  The QOP parameter has 
   meaning and validity with reference to this knowledge.  For example, 
   an application may request integrity algorithm number 3 as defined by 
   the mechanism specification.  If this algorithm is supported over 
   this context then it is used; otherwise, GSS_S_FAILURE and an 
   appropriate minor status code are returned.

Adams                Document Expiration:  5 Nov. 1995                22
   If the SPKM_REP_TI token is not used (unilateral authentication using 
   SPKM-2), then the "agreed" sets of Alg. IDs are simply taken to be 
   the initiator's sets (if this is unacceptable to the target then it 
   must return an error token so that the context is never established).  
   Note that, in the interest of interoperability, the initiator is not 
   required to offer every algorithm it supports; rather, it may offer 
   only the mandated/recommended SPKM algorithms since these are likely 
   to be supported by the target.


   The QOP parameter for SPKM is defined to be a 32-bit unsigned integer 
   (an OM_uint32) with the following bit-field assignments:

 Confidentiality                     Integrity
 31 (MSB)                         16 15                         (LSB) 0
------------------------------------|-----------------------------------
|  TS (5)  | U(3) | IA (4) | MA (4) |  TS (5)  | U(3) | IA (4) | MA(4) |
------------------------------------|-----------------------------------

   where 

      TS is a 5-bit Type Specifier (a semantic qualifier whose value 
      specifies the type of algorithm which may be used to protect the 
      corresponding token -- see below for details);

      U is a 3-bit Unspecified field (available for future 
      use/expansion);

      IA is a 4-bit field enumerating Implementation-specific 
      Algorithms; and

      MA is a 4-bit field enumerating Mechanism-defined Algorithms.

   The interpretation of the QOP parameter is as follows (note that the 
   same procedure is used for both the confidentiality and the integrity 
   halves of the parameter).  The MA field is examined first.  If it is 
   non-zero then the algorithm used to protect the token is the 
   mechanism-specified algorithm corresponding to that integer value.

   If MA is zero then IA is examined.  If this field value is non-zero 
   then the algorithm used to protect the token is the implementation-
   specified algorithm corresponding to that integer value (if this 
   algorithm is available over the established context).  Note that use 
   of this field may hinder portability since a particular value may 
   specify one algorithm in one implementation of the mechanism and may 
   not be supported or may specify a completely different algorithm in 
   another implementation of the mechanism.

   Finally, if both MA and IA are zero then TS is examined.  A value of 
   zero for TS specifies the default algorithm for the established 
   context, which is defined to be the first algorithm on the 
   initiator's list of offered algorithms (confidentiality or integrity, 
   depending on which half of QOP is being examined) which is supported 
   over the context.  A non-zero value for TS corresponds to a 
   particular algorithm qualifier and selects the first algorithm 
   supported over the context which satisfies that qualifier.

Adams                Document Expiration:  5 Nov. 1995                23

   The following TS values (i.e., algorithm qualifiers) are specified; 
   other values may be added in the future.

   For the Confidentiality TS field:

      00001 (1) = SPKM_SYM_ALG_STRENGTH_STRONG
      00010 (2) = SPKM_SYM_ALG_STRENGTH_MEDIUM
      00011 (3) = SPKM_SYM_ALG_STRENGTH_WEAK

   For the Integrity TS field:

      00001 (1) = SPKM_INT_ALG_NON_REPUDIABLE
      00010 (2) = SPKM_INT_ALG_REPUDIABLE

   Clearly, qualifiers such as strong, medium, and weak are debatable 
   and likely to change with time, but for the purposes of this version 
   of the specification we define these terms as follows.  A 
   confidentiality algorithm is "weak" if the effective key length of 
   the cipher is 40 bits or less; it is "medium-strength" if the 
   effective key length is strictly between 40 and 80 bits; and it is 
   "strong" if the effective key length is 80 bits or greater.  (Note 
   that "effective key length" describes the computational effort 
   required to break a cipher using the best-known cryptanalytic attack 
   against that cipher.)

   A five-bit TS field allows up to 31 qualifiers for each of 
   confidentiality and integrity (since "0" is reserved for "default").  
   This document specifies three for confidentiality and two for 
   integrity, leaving a lot of room for future specification.  
   Suggestions of qualifiers such as "fast", "medium-speed", and "slow" 
   have been made, but such terms are difficult to quantify (and in any 
   case are platform- and processor-dependent), and so have been left 
   out of this initial specification.  The intention is that the TS 
   terms be quantitative, environment-independent qualifiers of 
   algorithms, as much as this is possible.


   Use of the QOP structure as defined above is ultimately meant to be 
   as follows.

    - TS values are specified at the GSS-API level and are therefore 
      portable across mechanisms.  Applications which know nothing about 
      algorithms are still able to choose "quality" of protection for 
      their message tokens.

    - MA values are specified at the mechanism level and are therefore 
      portable across implementations of a mechanism.  For example, all 
      implementations of the Kerberos V5 GSS mechanism must support 

         GSS_KRB5_INTEG_C_QOP_MD5     (value: 1) 
         GSS_KRB5_INTEG_C_QOP_DES_MD5 (value: 2) 
         GSS_KRB5_INTEG_C_QOP_DES_MAC (value: 3).

      (Note that these Kerberos-specified integrity QOP values do not 
      conflict with the QOP structure defined above.)

Adams                Document Expiration:  5 Nov. 1995                24



    - IA values are specified at the implementation level (in user 
      documentation, for example) and are therefore typically non-
      portable.  An application which is aware of its own mechanism 
      implementation and the mechanism implementation of its peer, 
      however, is free to use these values since they will be perfectly 
      valid and meaningful over that context and between those peers.

   The receiver of a token must pass back to its calling application a 
   QOP parameter with all relevant fields set.  For example, if 
   triple-DES has been specified by a mechanism as algorithm 8, then 
   a receiver of a triple-DES-protected token must pass to its 
   application (QOP Confidentiality TS=1, IA=0, MA=8).  In this way, 
   the application is free to read whatever part of the QOP it 
   understands (TS or IA/MA).

   To aid in implementation and interoperability, the following 
   stipulation is made.  The set of integrity Alg. IDs sent by the 
   initiator must contain at least one specifying an algorithm which 
   computes a digital signature supporting non-repudiation, and must 
   contain at least one specifying any other (repudiable) integrity 
   algorithm.  The subset of integrity Alg. IDs returned by the target 
   must also contain at least one specifying an algorithm which computes 
   a digital signature supporting non-repudiation, and at least one 
   specifying a repudiable integrity algorithm.

   The reason for this stipulation is to ensure that every SPKM 
   implementation will provide an integrity service which supports non-
   repudiation and one which does not support non-repudiation.  An 
   application with no knowledge of underlying algorithms can choose one 
   or the other by passing (QOP Integrity TS=1, IA=MA=0) or (QOP 
   Integrity TS=2, IA=MA=0).

   Finally, in accordance with the MANDATORY and RECOMMENDED algorithms 
   given in Section 2, the following QOP values are specified for SPKM.

   For the Confidentiality MA field:

      0001 (1) = DES-CBC

   For the Integrity MA field:

      0001 (1) = md5WithRSA
      0010 (2) = DES-MAC



6. SUPPORT FUNCTIONS

   This section describes a mandatory support function for SPKM-
   conformant implementations which may, in fact, be of value in all 
   GSS-API mechanisms.  It makes use of the token_id and context_id 
   fields which are included in SPKM context-establishment, error, 
   context-deletion, and per-message tokens.  The function is defined 
   in the following section.


Adams                Document Expiration:  5 Nov. 1995                25

6.1. SPKM_Parse_token call

   Inputs:

   o  input_token OCTET STRING

   Outputs:

   o  major_status INTEGER,

   o  minor_status INTEGER,

   o  mech_type OBJECT IDENTIFIER,

   o  token_type INTEGER,

   o  context_handle CONTEXT HANDLE,


   Return major_status codes:

   o  GSS_S_COMPLETE indicates that the input_token could be parsed for 
      all relevant fields.  The resulting values are stored in 
      mech_type, token_type and context_handle, respectively (with NULLs 
      in any parameters which are not relevant).

   o  GSS_S_DEFECTIVE_TOKEN indicates that either the token_id or the 
      context_id (if one was expected) could not be parsed.  A non-NULL 
      return value in token_type indicates that the latter situation 
      occurred.

   o  GSS_S_NO_TYPE indicates that the token_id could be parsed, but it 
      did not correspond to any valid token_type.

      (Note that this major status code has not been defined for GSS in 
      RFC-1508.  Until such a definition is made (if ever), SPKM 
      implementations should instead return GSS_S_DEFECTIVE_TOKEN with 
      both token_type and context_handle set to NULL.  This essentially 
      implies that an unrecognized token_id is considered to be 
      equivalent to a field which could not be parsed.)

   o  GSS_S_NO_CONTEXT indicates that the context_id could be parsed, 
      but it did not correspond to any valid context_handle.

   o  GSS_S_FAILURE indicates that the mechanism type could not be 
      parsed (for example, the token may be corrupted).

   SPKM_Parse_token() is used to return to an application the mechanism 
   type, token type, and context handle which correspond to a given 
   input token.  Since GSS-API tokens are meant to be opaque to the 
   calling application, this function allows the application to 
   determine information about the token without having to violate the 
   opaqueness intention of GSS.  Of primary importance is the token 
   type, which the application can then use to decide which GSS function 
   to call in order to have the token processed.

Adams                Document Expiration:  5 Nov. 1995                26

   If all tokens are framed as suggested in RFC-1508, Appendix B 
   (specified both in the Kerberos V5 GSS mechanism [KRB5] and in this 
   document), then any mechanism implementation should be able to return 
   at least the mech_type parameter (the other parameters being NULL) 
   for any uncorrupted input token.  If the mechanism implementation 
   whose SPKM_Parse_token() function is being called does recognize the 
   token, it can return token_type so that the application can 
   subsequently call the correct GSS function.  Finally, if the 
   mechanism provides a context_id field in its tokens (as SPKM does), 
   then an implementation can map the context_id to a context_handle and 
   return this to the application.  This is necessary for the situation 
   where an application has multiple contexts open simultaneously, all 
   using the same mechanism.  When an incoming token arrives, the 
   application can use this function to determine not only which GSS 
   function to call, but also which context_handle to use for the call.
   Note that this function does no cryptographic processing to determine 
   the validity of tokens; it simply attempts to parse the mech_type,
   token_type, and context_id fields of any token it is given.  Thus, it 
   is conceivable, for example, that an arbitrary buffer of data might 
   start with random values which look like a valid mech_type and that 
   SPKM_Parse_token() would return incorrect information if given this 
   buffer.  While conceivable, however, such a situation is unlikely.

   The SPKM_Parse_token() function is mandatory for SPKM-conformant 
   implementations, but it is optional for applications.  That is, if 
   an application has only one context open and can guess which GSS 
   function to call (or is willing to put up with a few error codes), 
   then it need never call SPKM_Parse_token().  Furthermore, if this 
   function ever migrates up to the GSS-API level, then 
   SPKM_Parse_token() will be deprecated at that time in favour of 
   GSS_Parse_token(), or whatever the new name and function 
   specification might be.  Note finally that no minor status return 
   codes have been defined for this function at this time.



6.2. The token_type Output Parameter

   The following token types are defined:

      GSS_INIT_TOKEN   = 1
      GSS_ACCEPT_TOKEN = 2
      GSS_ERROR_TOKEN  = 3
      GSS_SIGN_TOKEN   = GSS_GETMIC_TOKEN = 4
      GSS_SEAL_TOKEN   = GSS_WRAP_TOKEN   = 5
      GSS_DELETE_TOKEN = 6

   All SPKM mechanisms shall be able to perform the mapping from the 
   token_id which is included in every token to one of the above token 
   types.  Applications should be able to decide, on the basis of 
   token_type, which GSS function to call (for example, if the token is 
   a GSS_INIT_TOKEN then the application will call 
   gss_accept_sec_context(), and if the token is a GSS_WRAP_TOKEN then
   the application will call gss_unwrap()).


Adams                Document Expiration:  5 Nov. 1995                27

6.3. The context_handle Output Parameter

   The SPKM mechanism implementation is responsible for maintaining a 
   mapping between the context_id value which is included in every token 
   and a context_handle, thus associating an individual token with its 
   proper context.  Clearly the value of context_handle may be locally 
   determined and may, in fact, be associated with memory containing 
   sensitive data on the local system, and so having the context_id 
   actually be set equal to a computed context_handle will not work in 
   general.  Conversely, having the context_handle actually be set equal 
   to a computed context_id will not work in general either, because 
   context_handle must be returned to the application by the first call 
   to gss_init_sec_context() or gss_accept_sec_context(), whereas 
   uniqueness of the context_id (over all contexts at both ends) 
   may require that both initiator and target be involved in the 
   computation.  Consequently, context_handle and context_id must be 
   computed separately and the mechanism implementation must be able to 
   map from one to the other by the completion of context establishment 
   at the latest.

   Computation of context_id during context establishment is 
   accomplished as follows.  Each SPKM implementation is responsible for 
   generating a "fresh" random number; that is, one which (with high 
   probability) has not been used previously.  Note that there are no 
   cryptographic requirements on this random number (i.e., it need not 
   be unpredictable, it simply needs to be fresh).  The initiator passes 
   its random number to the target in the context_id field of the 
   SPKM_REQ token.  If no further context establishment tokens are 
   expected (as for unilateral authentication in SPKM-2), then this 
   value is taken to be the context_id (if this is unacceptable to the 
   target then an error token must be generated).  Otherwise, the target 
   generates its random number and concatenates it to the end of the 
   initiator's random number.  This concatenated value is then taken to 
   be the context_id and is used in SPKM_REP_TI and in all subsequent 
   tokens over that context.

   Having both peers contribute to the context_id assures each peer of 
   freshness and therefore precludes replay attacks between contexts 
   (where a token from an old context between two peers is maliciously 
   injected into a new context between the same or different peers).  
   Such assurance is not available to the target in the case of 
   unilateral authentication using SPKM-2, simply because it has not 
   contributed to the freshness of the computed context_id (instead, it 
   must trust the freshness of the initiator's random number, or reject 
   the context).  The key_src_bind field in SPKM_REQ is required to be 
   present for the case of SPKM-2 unilateral authentication precisely to 
   assist the target in trusting the freshness of this token (and its 
   proposed context key).



7. SECURITY CONSIDERATIONS

   Security issues are discussed throughout this memo.


Adams                Document Expiration:  5 Nov. 1995                28

8. 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.

   [GSSv2]:     J. Linn, "Generic Security Service Application Program 
   Interface Version 2", Internat Draft:  draft-ietf-cat-gssv2-01.txt.

   [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-02.txt.

   [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-1423]:  D. Balenson, "Privacy Enhancement for Internet Elec-
   tronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423.

   [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.

   [9798]:      ISO/IEC 9798-3, "Information technology - Security 
   Techniques - Entity authentication mechanisms - Part 3:  Entitiy 
   authentication using a public key algorithm", ISO/IEC, 1993.

   [X.501]:     ISO/IEC 9594-2, "Information Technology - Open Systems 
   Interconnection - The Directory:  Models", CCITT/ITU Recommendation 
   X.501, 1993.




Adams                Document Expiration:  5 Nov. 1995               29

   [X.509]:     ISO/IEC 9594-8, "Information Technology - Open Systems 
   Interconnection - The Directory:  Authentication Framework", 
   CCITT/ITU Recommendation 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.









9. AUTHOR'S ADDRESS

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

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































Adams                Document Expiration:  5 Nov. 1995                30
Appendix A:  ASN.1 Module Definition


SpkmGssTokens {iso(1) org(3) dod(5) internet(1) security(5) 
              spkmGssTokens(xx)}

DEFINITIONS ::=
BEGIN


-- EXPORTS ALL --


IMPORTS
   informationFramework, authenticationFramework
      FROM UsefulDefinitions {joint-iso-ccitt(2) ds(5) modules(1) 
                             usefulDefinitions(0)}

   Name
      FROM InformationFramework {joint-iso-ccitt(2) ds(5) modules(1) 
                                informationFramework(1)}

   ENCRYPTED, SIGNED, SIGNATURE, Certificate, CertificatePair, 
   CertificateList, AlgorithmIdentifier
      FROM AuthenticationFramework {joint-iso-ccitt(2) ds(5) modules(1) 
                                   authenticationFramework(7) 1}  ;


-- macros --

   MAC MACRO ::=
   BEGIN
      TYPE  NOTATION ::= type  ( ToBeMACed )
      VALUE NOTATION ::= value ( VALUE SEQUENCE {
               algId     AlgorithmIdentifier,
               mac       BIT STRING             } )
      -- must be the result of applying the MACing procedure specified 
      -- by algId to the BER-encoded octets of a value of ToBeMACed (the 
      -- context key is to be used as an input to the MACing procedure)
   END

   HASHED MACRO ::=
   BEGIN
      TYPE  NOTATION ::= type  ( ToBeHashed )
      VALUE NOTATION ::= value ( VALUE OCTET STRING )
   END


-- types --

   SPKM_REQ ::= SEQUENCE {
           requestToken      REQ_TOKEN,
           req_integrity     Req_Integrity,
           certif_data [2]   CertificationData OPTIONAL,
           auth_data [3]     AuthorizationData OPTIONAL
   }

Adams                Document Expiration:  5 Nov. 1995                31

   Req_Integrity ::= CHOICE {
           sig_integ [0] SIGNATURE REQ_TOKEN,
           mac_integ [1] MAC REQ_TOKEN
   }


   CertificationData ::= SEQUENCE {
           certificationPath [0]          CertificationPath OPTIONAL,
           certificateRevocationList [1]  CertificateList OPTIONAL
   } -- at least one of the above shall be present


   CertificationPath ::= SEQUENCE {
           userKeyId [0]         OCTET STRING OPTIONAL,
           userCertif [1]        Certificate OPTIONAL,
           verifKeyId [2]        OCTET STRING OPTIONAL,
           userVerifCertif [3]   Certificate OPTIONAL,
           theCACertificates [4] SEQUENCE OF CertificatePair OPTIONAL
   } -- Presence of [2] or [3] implies that [0] or [1] must also be 
     -- present.  Presence of [4] implies that at least one of [0], [1], 
     -- [2], and [3] must also be present.


   REQ_TOKEN ::= SEQUENCE {
           tok_id           INTEGER,  -- shall contain 0100 (hex)
           context_id       Random_Integer,
           pvno             BIT STRING,
           timestamp        UTCTime OPTIONAL, -- mandatory for SPKM-2
           randSrc          Random_Integer,
           targ_name        Name,
           src_name         Name, 
           req_data         Context_Data,
           validity [0]     Validity OPTIONAL,
           key_estb_set [1] Key_Estb_Algs,
           key_estb_req     BIT STRING OPTIONAL,
           key_src_bind     HASHED SEQUENCE {
                  src_name  Name,
                  symm_key  BIT STRING      } OPTIONAL
              -- this field must be present for the case of SPKM-2 
              -- unilateral authentication if the K-ALG in use does 
              -- not provide such a binding (but is optional for all 
              -- other cases)
           }


   Random_Integer ::= BIT STRING


   Context_Data ::= SEQUENCE {
           channelId       ChannelId,
           seq_number      INTEGER OPTIONAL,
           options         Options,
           conf_alg        Conf_Algs,
           intg_alg        Intg_Algs
   }

Adams                Document Expiration:  5 Nov. 1995                32
   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),
           target_certif_data_required (6)
   }

   Conf_Algs ::= CHOICE {
           SEQUENCE OF AlgorithmIdentifier,
           NULL
   }

   Intg_Algs ::= SEQUENCE OF AlgorithmIdentifier 

   Key_Estb_Algs ::= SEQUENCE OF AlgorithmIdentifier

   SPKM_REP_TI ::= SEQUENCE {
           responseToken    REP_TOKEN,
           certif_data      CertificationData OPTIONAL
             -- present if target_certif_data_required option was 
   }         -- set to TRUE in SPKM_REQ

   REP_TOKEN ::= SIGNED SEQUENCE {
           tok_id           INTEGER,         -- shall contain 0200 (hex)
           context_id       Random_Integer,
           pvno [0]         BIT STRING OPTIONAL,
           timestamp [1]    UTCTime OPTIONAL, -- mandatory for SPKM-2
           randTarg [2]     Random_Integer,
           src_name         Name,
           targ_name        Name,
           randSrc          Random_Integer,
           rep_data         Context_Data,
           validity [3]     Validity  OPTIONAL,
           key_estb_id [4]  AlgorithmIdentifier OPTIONAL,
           key_estb_str     BIT STRING OPTIONAL
           }

   SPKM_REP_IT ::= SIGNED SEQUENCE {
           tok_id           INTEGER,  -- shall contain 0300 (hex)
           context_id       Random_Integer,
           randSrc          Random_Integer,
           randTarg         Random_Integer,
           targ_name        Name,
           src_name         Name,
           key_estb_rep     BIT STRING OPTIONAL
           }

   SPKM_ERROR ::=   SIGNED SEQUENCE {
           tok_id           INTEGER, -- shall contain 0400 (hex)
           context_id       Random_Integer
           }

Adams                Document Expiration:  5 Nov. 1995                33

   SPKM_MIC ::= SEQUENCE {
           mic_header       Mic_Header,
           int_cksum        BIT STRING
   }

   Mic_Header ::= SEQUENCE {
           tok_id           INTEGER, -- shall contain 0101 (hex)
           context_id       Random_Integer,
           int_alg          AlgorithmIdentifier OPTIONAL,
           snd_seq          SeqNum OPTIONAL
   }

   SeqNum ::= SEQUENCE {
           num      INTEGER,
           dir_ind  BOOLEAN
   }


   SPKM_WRAP ::= SEQUENCE {
           wrap_header       Wrap_Header,
           wrap_body         Wrap_Body
   }

   Wrap_Header ::= SEQUENCE {
           tok_id           INTEGER, -- shall contain 0201 (hex)
           context_id       Random_Integer,
           int_alg [0]      AlgorithmIdentifier OPTIONAL,
           conf_alg [1]     Conf_Alg OPTIONAL,
           snd_seq          SeqNum OPTIONAL
   }

   Wrap_Body ::= SEQUENCE {
           int_cksum        BIT STRING,
           data             BIT STRING
   }

   Conf_Alg ::= CHOICE {
           AlgorithmIdentifier,
           NULL
   }


   SPKM_DEL ::= SEQUENCE {
           del_header       Del_Header,
           int_cksum        BIT STRING
   }

   Del_Header ::= SEQUENCE {
           tok_id           INTEGER, -- shall contain 0301 (hex)
           context_id       Random_Integer,
           int_alg          AlgorithmIdentifier OPTIONAL,
           snd_seq          SeqNum OPTIONAL
   }



Adams                Document Expiration:  5 Nov. 1995                34

-- other types --

   -- from [RFC-1508] -- 

   MechType ::= OBJECT IDENTIFIER

   InitialContextToken ::= SEQUENCE {
      thisMech MechType,
      innerContextToken ANY DEFINED BY thisMech
         -- contents mechanism-specific
   }

   --from [PKCS3] (the parameter to be used with dhKeyAgreement) --

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

   -- from [RFC-1510] --

   AuthorizationData ::= SEQUENCE OF SEQUENCE {
     ad-type  INTEGER,
     ad-data  OCTET STRING
   }



-- object identifier assignments --

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

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

   SPKM-1 OBJECT IDENTIFIER ::= 
      {iso(1) org(3) dod(5) internet(1) security(5) SPKM-1(xx)}

   SPKM-2 OBJECT IDENTIFIER ::= 
      {iso(1) org(3) dod(5) internet(1) security(5) SPKM-2(xx)}



END










Adams                Document Expiration:  5 Nov. 1995                35
Appendix B:  Imported Types


This appendix contains, for completeness, the relevant ASN.1 types 
imported from InformationFramework and AuthenticationFramework.

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

   RelativeDistinguishedName ::= SET OF AttributeValueAssertion
   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
   DistinguishedName ::= RDNSequence

   Name ::= CHOICE {       --only one for now
                   DistinguishedName
                   }

   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:  5 Nov. 1995                36
   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 [7]      IMPLICIT UID OPTIONAL,  -- used in v2 only
           subjectUID [8]     IMPLICIT UID OPTIONAL   -- used in v2 only
           }

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

   CertificateSerialNumber ::= INTEGER

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

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

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

   UID ::= BIT STRING

   CertificatePair ::= SEQUENCE {
           forward [0]      Certificate OPTIONAL,
           reverse [1]      Certificate 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:  5 Nov. 1995                37