GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc2025

Network Working Group C. Adams Request for Comments: 2025 Bell-Northern Research Category: Standards Track October 1996

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

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

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.  The mechanism
 described in this document has been proposed to meet this need and to
 provide the following features.
   1)  The SPKM allows both unilateral and mutual authentication
       to be accomplished without the use of secure timestamps.  This
       enables environments which do not have access to secure time
       to nevertheless have access to secure authentication.
   2)  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.
   3)  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]), rather than an integrity checksum based on a MAC
       computed with a symmetric algorithm (e.g., DES).  For some
       environments, the availability of true digital signatures
       supporting non-repudiation is a necessity.

Adams Standards Track [Page 1] RFC 2025 SPKM October 1996

   4)  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
 flexibility and functionality, 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 for implementation-
 related clarifications, to John Linn of OpenVision Technologies for
 helpful comments, and to Bancroft Scott of OSS for ASN.1 assistance.

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:
  1. documents defining specific parameter bindings for particular

language environments;

  1. documents defining token formats, protocols, and procedures to

be implemented in order to realize GSS-API services atop

       particular security mechanisms."

Adams Standards Track [Page 2] RFC 2025 SPKM October 1996

 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 Standards Track [Page 3] RFC 2025 SPKM October 1996

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
 interoperability 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:
       md5WithRSAEncryption OBJECT IDENTIFIER ::= {
         iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
         pkcs-1(1) 4        -- imported from [PKCS1]
       }
          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
          essentially equivalent to md5WithRSA {1 3 14 3 2 3},
          which is defined by OIW (the Open Systems Environment
          Implementors' Workshop).
          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 which are signed rather than MACed --
          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

Adams Standards Track [Page 4] RFC 2025 SPKM October 1996

          context establishment tokens may be removed.
       DES-MAC OBJECT IDENTIFIER ::= {
          iso(1) identified-organization(3) oiw(14) secsig(3)
          algorithm(2) 10  -- carries length in bits of the MAC as
       }                   -- an INTEGER parameter, constrained to
                           -- multiples of eight from 16 to 64
          This algorithm (RECOMMENDED) provides integrity by computing
          a DES MAC (as specified by [FIPS-113]) on that data.
       md5-DES-CBC OBJECT IDENTIFIER ::= {
          iso(1) identified-organization(3) dod(6) internet(1)
          security(5) integrity(3) md5-DES-CBC(1)
       }
          This algorithm provides data integrity by encrypting, using
          DES CBC, the "confounded" MD5 hash of that data (see Section
          3.2.2.1 for the definition and purpose of confounding).
          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 without the confounder 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) dod(6) internet(1)
          security(5) integrity(3) sum64-DES-CBC(2)
       }
          This algorithm provides data integrity by encrypting, using
          DES CBC, the concatenation of the confounded 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].

Adams Standards Track [Page 5] RFC 2025 SPKM October 1996

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 (OCTET STRING) as a parameter;
       }                 -- this (optional) parameter is unused in
                         -- SPKM due to the use of confounding
          This algorithm is RECOMMENDED.

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.

Adams Standards Track [Page 6] RFC 2025 SPKM October 1996

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

2.4 One-Way Function (O-ALG) for Subkey Derivation Algorithm:

     Purpose:
       Having established a context key using the negotiated K-ALG,
       both initiator and target must be able to derive a set of
       subkeys for the various C-ALGs and keyed I-ALGs supported over
       the context.  Let the (ordered) list of agreed C-ALGs be
       numbered consecutively, so that the first algorithm (the
       "default") is numbered "0", the next is numbered "1", and so
       on.  Let the numbering for the (ordered) list of agreed I-ALGs
       be identical.  Finally, let the context key be a binary string
       of arbitrary length "M", subject to the following constraint:
       L <= M <= U  (where the lower limit "L" is the bit length of
       the longest key needed by any agreed C-ALG or keyed I-ALG, and
       the upper limit "U" is the largest bit size which will fit
       within the K-ALG parameters).
       For example, if DES and two-key-triple-DES are the negotiated
       confidentiality algorithms and DES-MAC is the negotiated keyed
       integrity algorithm (note that digital signatures do not use a
       context key), then the context key must be at least 112 bits
       long.  If 512-bit RSAEncryption is the K-ALG in use then the
       originator can randomly generate a context key of any greater
       length up to 424 bits (the longest allowable RSA input
       specified in [PKCS-1]) -- the target can determine the length
       which was chosen by removing the padding bytes during the RSA
       decryption operation.  On the other hand, if dhKeyAgreement is
       the K-ALG in use then the context key is the result of the
       Diffie-Hellman computation (with the exception of the high-
       order byte, which is discarded for security reasons), so that
       its length is that of the Diffie-Hellman modulus, p, minus 8
       bits.

Adams Standards Track [Page 7] RFC 2025 SPKM October 1996

       The derivation algorithm for a k-bit subkey is specified as
       follows:
    rightmost_k_bits (OWF(context_key || x || n || s || context_key))
       where
  1. "x" is the ASCII character "C" (0x43) if the subkey is

for a confidentiality algorithm or the ASCII character "I"

          (0x49) if the subkey is for a keyed integrity algorithm;
        - "n" is the number of the algorithm in the appropriate agreed
          list for the context (the ASCII character "0" (0x30), "1"
          (0x31), and so on);
        - "s" is the "stage" of processing -- always the ASCII
          character "0" (0x30), unless "k" is greater than the output
          size of OWF, in which case the OWF is computed repeatedly
          with increasing ASCII values of "stage" (each OWF output
          being concatenated to the end of previous OWF outputs),
          until "k" bits have been generated;
        - "||" is the concatenation operation; and
        - "OWF" is any appropriate One-Way Function.
     Examples:
       MD5 OBJECT IDENTIFIER ::= {
         iso(1) member-body(2) US(840) rsadsi(113549)
         digestAlgorithm(2) 5
       }
         This algorithm is MANDATORY.
       SHA OBJECT IDENTIFIER ::= {
          iso(1) identified-organization(3) oiw(14) secsig(3)
          algorithm(2) 18
       }
       It is recognized that existing hash functions may not satisfy
       all required properties of OWFs.  This is the reason for
       allowing negotiation of the O-ALG OWF during the context
       establishment process (see Section 2.5), since in this way
       future improvements in OWF design can easily be accommodated.
       For example, in some environments a preferred OWF technique
       might be an encryption algorithm which encrypts the input
       specified above using the context_key as the encryption key.

Adams Standards Track [Page 8] RFC 2025 SPKM October 1996

2.5 Negotiation:

 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.
 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.
 Finally, in the first context establishment token the initiator
 offers a set of possible O-ALGs (only a single O-ALG if no response
 is expected).  The (single) O-ALG chosen by the target becomes the
 subkey derivation algorithm OWF to be used over the context.
 In future versions of SPKM, other algorithms may be specified for any
 or all of I-ALG, C-ALG, K-ALG, and O-ALG.

Adams Standards Track [Page 9] RFC 2025 SPKM October 1996

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 {spkm spkm-1(1)}
 or {spkm spkm-2(2)}, where spkm has the value {iso(1) identified-
 organization(3) dod(6) internet(1) security(5) mechanisms(5)
 spkm(1)}.  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() or gss_accept_sec_context(), and
 potentially consumed by calls to gss_init_sec_context() or
 gss_accept_sec_context().
 Per RFC-1508, Appendix B, the initial context establishment token
 will be enclosed within framing as follows:
 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

Adams Standards Track [Page 10] RFC 2025 SPKM October 1996

 When thisMech is SPKM-1 or SPKM-2, innerContextToken is defined as
 follows:
    SPKMInnerContextToken ::= CHOICE {
       req    [0] SPKM-REQ,
       rep-ti [1] SPKM-REP-TI,
       rep-it [2] SPKM-REP-IT,
       error  [3] SPKM-ERROR,
       mic    [4] SPKM-MIC,
       wrap   [5] SPKM-WRAP,
       del    [6] SPKM-DEL
    }
 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 exchange.  While not required by RFC-1508, this enables
 implementations to perform enhanced error-checking.  The tag values
 provided in SPKMInnerContextToken ("[0]" through "[6]") specify a
 token-id for each token; similar information is contained in each
 token's tok-id field.  While seemingly redundant, the tag value and
 tok-id actually perform different tasks:  the tag ensures that
 InitialContextToken can be properly decoded; tok-id ensures, among
 other things, that data associated with the per-message tokens is
 cryptographically linked to the intended token type.  Every
 innerContextToken also includes a context-id field; see Section 6 for
 a discussion of both token-id and context-id information and their
 use in an SPKM support function).
 The innerContextToken field of context establishment tokens for the
 SPKM GSS-API mechanism will contain one of the following messages:
 SPKM-REQ; SPKM-REP-TI; SPKM-REP-IT; and SPKM-ERROR.  Furthermore, all
 innerContextTokens are encoded using ASN.1 BER (constrained, in the
 interests of parsing simplicity, to the DER subset defined in
 [X.509], clause 8.7).
 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.

Adams Standards Track [Page 11] RFC 2025 SPKM October 1996

 The implication of the previous paragraph is that for SPKM-2
 unilateral authentication no negotiation of K-ALG can be done (the
 target either accepts the K-ALG and context 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 context key.
 It is envisioned that typical use of SPKM-1 or SPKM-2 will involve
 mutual authentication.  Although unilateral authentication is
 available for both mechanisms, its use is not generally recommended.

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
 partys 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 environments 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,
         certif-data [0]   CertificationData OPTIONAL,
         auth-data [1]     AuthorizationData OPTIONAL
            -- see [RFC-1510] for a discussion of auth-data
 }
 CertificationData ::= SEQUENCE {
         certificationPath [0]          CertificationPath OPTIONAL,
         certificateRevocationList [1]  CertificateList OPTIONAL
 }  -- at least one of the above shall be present

Adams Standards Track [Page 12] RFC 2025 SPKM October 1996

 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 {
            req-contents     Req-contents,
            algId            AlgorithmIdentifier,
            req-integrity    Integrity  -- "token" is Req-contents
    }
    Integrity ::= BIT STRING
      -- If corresponding algId specifies a signing algorithm,
      -- "Integrity" holds the result of applying the signing procedure
      -- specified in algId to the BER-encoded octet string which results
      -- from applying the hashing procedure (also specified in algId) to
      -- the DER-encoded octets of "token".
      -- Alternatively, if corresponding algId specifies a MACing
      -- algorithm, "Integrity" holds the result of applying the MACing
      -- procedure specified in algId to the DER-encoded octets of
      -- "token" (note that for MAC, algId must be one of the integrity
      -- algorithms offered by the initiator with the appropriate subkey
      -- derived from the context key (see Section 2.4) used as the key
      -- input)
 It is envisioned that typical use of the Integrity field for each of
 REQ-TOKEN, REP-TI-TOKEN, and REP-IT-TOKEN will be a true digital
 signature, providing unilateral or mutual authentication along with
 replay protection, as required.  However, there are situations in
 which the MAC choice will be appropriate.  One example is the case in
 which the initiator wishes to remain anonymous (so that the first, or

Adams Standards Track [Page 13] RFC 2025 SPKM October 1996

 first and third, token(s) will be MACed and the second token will be
 signed).  Another example is the case in which a previously
 authenticated, established, and cached context is being re-
 established at some later time (here all exchanged tokens will be
 MACed).
 The primary advantage of the MAC choice is that it reduces processing
 overhead for cases in which either authentication is not required
 (e.g., anonymity) or authentication is established by some other
 means (e.g., ability to form the correct MAC on a "fresh" token in
 context re-establishment).
 Req-contents ::= SEQUENCE {
         tok-id           INTEGER (256),    -- 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 [0]     Name OPTIONAL,
            -- must be supplied unless originator is "anonymous"
         req-data         Context-Data,
         validity [1]     Validity OPTIONAL,
            -- validity interval for key (may be used in the
            -- computation of security context lifetime)
         key-estb-set     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 satisfy the key length constraints
            -- specified in Section 2.4.
         key-src-bind      OCTET STRING OPTIONAL
            -- Used to bind the source name to the symmetric key.
            -- This field must be present for the case of SPKM-2
            -- unilateral authen. if the K-ALG in use does not provide
            -- such a binding (but is optional for all other cases).
            -- The octet string holds the result of applying the
            -- mandatory hashing procedure MD5 (in MANDATORY I-ALG;
            -- see Section 2.1) as follows:  MD5(src || context_key),
            -- where "src" is the DER-encoded octets of src-name,
            -- "context-key" is the symmetric key (i.e., the
            -- unprotected version of what is transmitted in
            -- key-estb-req), and "||" is the concatenation operation.
         }

Adams Standards Track [Page 14] RFC 2025 SPKM October 1996

  1. - The protocol version number (pvno) parameter is a BIT STRING which
  2. - uses as many bits as necessary to specify all the SPKM protocol
  3. - versions supported by the initiator (one bit per protocol
  4. - version). The protocol specified by this document is version 0.
  5. - Bit 0 of pvno is therefore set if this version is supported;
  6. - similarly, bit 1 is set if version 1 (if defined in the future) is
  7. - supported, and so on. Note that for unilateral authentication
  8. - using SPKM-2, no response token is expected during context
  9. - establishment, so no protocol negotiation can take place; in this
  10. - case, the initiator must set exactly one bit of pvno. The version
  11. - of REQ-TOKEN must correspond to the highest bit set in pvno.
  12. - The "validity" parameter above is the only way within SPKM for
  13. - the initiator to transmit desired context lifetime to the target.
  14. - Since it cannot be guaranteed that the initiator and target have
  15. - synchronized time, the span of time specified by "validity" is to
  16. - be taken as definitive (rather than the actual times given in this
  17. - parameter).
 Random-Integer ::= BIT STRING
  1. - Each SPKM implementation is responsible for generating a "fresh"
  2. - random number for the purpose of context establishment; that is,
  3. - one which (with high probability) has not been used previously.
  4. - There are no cryptographic requirements on this random number
  5. - (i.e., it need not be unpredictable, it simply needs to be fresh).
 Context-Data ::= SEQUENCE {
         channelId       ChannelId OPTIONAL, -- channel bindings
         seq-number      INTEGER OPTIONAL,   -- sequence number
         options         Options,
         conf-alg        Conf-Algs,          -- confidentiality. algs.
         intg-alg        Intg-Algs,          -- integrity algorithm
         owf-alg         OWF-Algs            -- for subkey derivation
 }
 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 Standards Track [Page 15] RFC 2025 SPKM October 1996

 Conf-Algs ::= CHOICE {
         algs [0]        SEQUENCE OF AlgorithmIdentifier,
         null [1]        NULL
          -- used when conf. is not available 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)
 OWF-Algs ::= SEQUENCE OF AlgorithmIdentifier
     -- Contains exactly one algorithm in REQ-TOKEN for SPKM-2
     -- unilateral, and contains at least one algorithm otherwise.
     -- Always contains exactly one algorithm in REP-TOKEN.
 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
 authentication in SPKM-2 (in which no SPKM-REP-TI token is
 constructed), this option bit is ignored by both initiator and
 target.

Adams Standards Track [Page 16] RFC 2025 SPKM October 1996

3.1.2. Context Establishment Tokens - Target

 SPKM-REP-TI ::= SEQUENCE {
         responseToken    REP-TI-TOKEN,
         certif-data      CertificationData OPTIONAL
           -- included if target-certif-data-required option was
           -- set to TRUE in SPKM-REQ
 }
 REP-TI-TOKEN ::= SEQUENCE {
         rep-ti-contents Rep-ti-contents,
         algId           AlgorithmIdentifier,
         rep-ti-integ    Integrity  -- "token" is Rep-ti-contents
 }
 Rep-ti-contents ::= SEQUENCE {
         tok-id           INTEGER (512),   -- shall contain 0200 (hex)
         context-id       Random-Integer,  -- see Section 6.3
         pvno [0]         BIT STRING OPTIONAL, -- prot. version number
         timestamp        UTCTime OPTIONAL, -- mandatory for SPKM-2
         randTarg         Random-Integer,
         src-name [1]     Name OPTIONAL,
           -- must contain whatever value was supplied in REQ-TOKEN
         targ-name        Name,
         randSrc          Random-Integer,
         rep-data         Context-Data,
         validity [2]     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      AlgorithmIdentifier OPTIONAL,
           -- used if target is changing key estb. algorithm (must be
           -- a member of initiators key-estb-set)
         key-estb-str      BIT STRING OPTIONAL
           -- contains (1) the response to the initiators
           -- 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 satisfy the key length constraints
           -- specified in Section 2.4.
         }

Adams Standards Track [Page 17] RFC 2025 SPKM October 1996

 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.  Finally, if the initiator and target do have
 one or more versions in common but the version of the REQ-TOKEN
 received is not supported by the target, a REP-TOKEN must be sent
 with a desired version bit set in pvno (and dummy values used for all
 subsequent token fields).  The initiator can then respond with a new
 REQ-TOKEN of the proper version (essentially starting context
 establishment anew).

3.1.3. Context Establishment Tokens - Initiator (second token)

 Relevant SPKM-REP-IT syntax is as follows:
 SPKM-REP-IT ::= SEQUENCE {
         responseToken    REP-IT-TOKEN,
         algId            AlgorithmIdentifier,
         rep-it-integ     Integrity  -- "token" is REP-IT-TOKEN
 }
 REP-IT-TOKEN ::= SEQUENCE {
         tok-id           INTEGER (768), -- 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 OPTIONAL,
           -- must contain whatever value was supplied in REQ-TOKEN
         key-estb-rep     BIT STRING OPTIONAL
               -- contains the response to targets key-estb-str
               -- (if target selected a 2-pass K-ALG)
         }

3.1.4. Error Token

 The syntax of SPKM-ERROR is as follows:
 SPKM-ERROR ::= SEQUENCE {
         error-token      ERROR-TOKEN,
         algId            AlgorithmIdentifier,
         integrity        Integrity  -- "token" is ERROR-TOKEN

Adams Standards Track [Page 18] RFC 2025 SPKM October 1996

 }
 ERROR-TOKRN ::=   SEQUENCE {
         tok-id           INTEGER (1024), -- 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 is currently stipulated for the signing of context
 establishment tokens.  Discrepancies involving modulus bitlength 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 Standards Track [Page 19] RFC 2025 SPKM October 1996

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 (257),
                              -- shall contain 0101 (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.
         snd-seq [1]      SeqNum OPTIONAL  -- sequence number field.
 }
 SeqNum ::= SEQUENCE {
         num      INTEGER, -- the sequence number itself
         dir-ind  BOOLEAN  -- a direction indicator
 }

Adams Standards Track [Page 20] RFC 2025 SPKM October 1996

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.
 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 appropriate
 subkey derived from the context key (see Section 2.4).  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
 protocol 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/getMIC() or
 gss_seal/wrap() token, the sender's seq. number is incremented by 1.

Adams Standards Track [Page 21] RFC 2025 SPKM October 1996

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, GSS_S_UNSEQ_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.

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 appropriate subkey specified in
 Section 2.4 for 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 (513),
                              -- 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.

Adams Standards Track [Page 22] RFC 2025 SPKM October 1996

         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 [2]      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 {
         algId [0]        AlgorithmIdentifier,
         null [1]         NULL
 }

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

Adams Standards Track [Page 23] RFC 2025 SPKM October 1996

 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 are 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 DES-CBC subkey (see Section 2.4) 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 DES-CBC subkey 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.

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 the appropriate subkey
 derived from the established context key using the subkey derivation
 algorithm described in Section 2.4 (this ensures that the subkey used
 for encryption and the subkey 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().

Adams Standards Track [Page 24] RFC 2025 SPKM October 1996

 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 (769),
                              -- shall contain 0301 (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.
         snd-seq [1]      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.
 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.

Adams Standards Track [Page 25] RFC 2025 SPKM October 1996

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.

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.

Adams Standards Track [Page 26] RFC 2025 SPKM October 1996

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

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

Adams Standards Track [Page 27] RFC 2025 SPKM October 1996

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

Adams Standards Track [Page 28] RFC 2025 SPKM October 1996

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

Adams Standards Track [Page 29] RFC 2025 SPKM October 1996

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

Adams Standards Track [Page 30] RFC 2025 SPKM October 1996

 Use of the QOP structure as defined above is ultimately meant to be
 as follows.
  1. 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.
  1. 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.)
  1. 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

Adams Standards Track [Page 31] RFC 2025 SPKM October 1996

 Integrity TS=2, IA=MA=0).  Although an initiator who wishes to remain
 anonymous will never actually use the non-repudiable digital
 signature, this integrity service must be available over the context
 so that the target can use it if desired.
 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
 information which is included in SPKM context-establishment, error,
 context-deletion, and per-message tokens.  The function is defined in
 the following section.

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,

Adams Standards Track [Page 32] RFC 2025 SPKM October 1996

 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 it was expected) information 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 information 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 unrecognized token-id information is considered to be
    equivalent to token-id information 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.
 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

Adams Standards Track [Page 33] RFC 2025 SPKM October 1996

 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 some 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 information which is included in every token (through the
 tag values in SPKMInnerContextToken or through the tok-id field) 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()).

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

Adams Standards Track [Page 34] RFC 2025 SPKM October 1996

 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 Standards Track [Page 35] RFC 2025 SPKM October 1996

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]:     Linn, J., "Generic Security Service Application Program
 Interface Version 2", Work in Progress.
 [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]:      Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
 RFC 1964, June 1996.
 [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]:  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321.
 [RFC-1422]:  Kent, S., "Privacy Enhancement for Internet Electronic
 Mail:  Part II: Certificate-Based Key Management", RFC 1422.
 [RFC-1423]:  Balenson, D., "Privacy Enhancement for Internet
 Elecronic Mail: Part III: Algorithms, Modes, and Identifiers",
 RFC 1423.
 [RFC-1508]:  Linn, J., "Generic Security Service Application Program
 Interface", RFC 1508.
 [RFC-1509]:  Wray, J., "Generic Security Service Application Program
 Interface: C-bindings", RFC 1509.
 [RFC-1510]:  Kohl J., 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.

Adams Standards Track [Page 36] RFC 2025 SPKM October 1996

 [X.501]:     ISO/IEC 9594-2, "Information Technology - Open Systems
 Interconnection - The Directory:  Models", CCITT/ITU Recommendation
 X.501, 1993.
 [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
 EMail: cadams@bnr.ca

Adams Standards Track [Page 37] RFC 2025 SPKM October 1996

Appendix A: ASN.1 Module Definition

SpkmGssTokens {iso(1) identified-organization(3) dod(6) internet(1)

             security(5) mechanisms(5) spkm(1) spkmGssTokens(10)}

DEFINITIONS IMPLICIT TAGS ::= BEGIN

– EXPORTS ALL –

IMPORTS

 Name
    FROM InformationFramework {joint-iso-ccitt(2) ds(5) module(1)
                              informationFramework(1) 2}
 Certificate, CertificateList, CertificatePair, AlgorithmIdentifier,
 Validity
    FROM AuthenticationFramework {joint-iso-ccitt(2) ds(5) module(1)
                                 authenticationFramework(7) 2}  ;

– types –

 SPKM-REQ ::= SEQUENCE {
         requestToken      REQ-TOKEN,
         certif-data [0]   CertificationData OPTIONAL,
         auth-data [1]     AuthorizationData OPTIONAL
 }
 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

Adams Standards Track [Page 38] RFC 2025 SPKM October 1996

  1. - present. Presence of [4] implies that at least one of [0], [1],
  2. - [2], and [3] must also be present.
 REQ-TOKEN ::= SEQUENCE {
         req-contents     Req-contents,
         algId            AlgorithmIdentifier,
         req-integrity    Integrity  -- "token" is Req-contents
 }
Integrity ::= BIT STRING
   -- If corresponding algId specifies a signing algorithm,
   -- "Integrity" holds the result of applying the signing procedure
   -- specified in algId to the BER-encoded octet string which results
   -- from applying the hashing procedure (also specified in algId) to
   -- the DER-encoded octets of "token".
   -- Alternatively, if corresponding algId specifies a MACing
   -- algorithm, "Integrity" holds the result of applying the MACing
   -- procedure specified in algId to the DER-encoded octets of
   -- "token"
 Req-contents ::= SEQUENCE {
         tok-id           INTEGER (256),  -- 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 [0]     Name OPTIONAL,
         req-data         Context-Data,
         validity [1]     Validity OPTIONAL,
         key-estb-set     Key-Estb-Algs,
         key-estb-req     BIT STRING OPTIONAL,
         key-src-bind     OCTET STRING OPTIONAL
            -- This field must be present for the case of SPKM-2
            -- unilateral authen. if the K-ALG in use does not provide
            -- such a binding (but is optional for all other cases).
            -- The octet string holds the result of applying the
            -- mandatory hashing procedure (in MANDATORY I-ALG;
            -- see Section 2.1) as follows:  MD5(src || context_key),
            -- where "src" is the DER-encoded octets of src-name,
            -- "context-key" is the symmetric key (i.e., the
            -- unprotected version of what is transmitted in
            -- key-estb-req), and "||" is the concatenation operation.
 }
 Random-Integer ::= BIT STRING

Adams Standards Track [Page 39] RFC 2025 SPKM October 1996

 Context-Data ::= SEQUENCE {
         channelId       ChannelId OPTIONAL,
         seq-number      INTEGER OPTIONAL,
         options         Options,
         conf-alg        Conf-Algs,
         intg-alg        Intg-Algs,
         owf-alg         OWF-Algs
 }
 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 {
         algs [0]         SEQUENCE OF AlgorithmIdentifier,
         null [1]         NULL
 }
 Intg-Algs ::= SEQUENCE OF AlgorithmIdentifier
 OWF-Algs ::= SEQUENCE OF AlgorithmIdentifier
 Key-Estb-Algs ::= SEQUENCE OF AlgorithmIdentifier
 SPKM-REP-TI ::= SEQUENCE {
         responseToken    REP-TI-TOKEN,
         certif-data      CertificationData OPTIONAL
           -- present if target-certif-data-required option was
 }         -- set to TRUE in SPKM-REQ
 REP-TI-TOKEN ::= SEQUENCE {
         rep-ti-contents  Rep-ti-contents,
         algId            AlgorithmIdentifier,
         rep-ti-integ     Integrity  -- "token" is Rep-ti-contents
 }
 Rep-ti-contents ::= SEQUENCE {
         tok-id           INTEGER (512),   -- shall contain 0200 (hex)
         context-id       Random-Integer,

Adams Standards Track [Page 40] RFC 2025 SPKM October 1996

         pvno [0]         BIT STRING OPTIONAL,
         timestamp        UTCTime OPTIONAL, -- mandatory for SPKM-2
         randTarg         Random-Integer,
         src-name [1]     Name OPTIONAL,
         targ-name        Name,
         randSrc          Random-Integer,
         rep-data         Context-Data,
         validity [2]     Validity  OPTIONAL,
         key-estb-id      AlgorithmIdentifier OPTIONAL,
         key-estb-str     BIT STRING OPTIONAL
 }
 SPKM-REP-IT ::= SEQUENCE {
         responseToken    REP-IT-TOKEN,
         algId            AlgorithmIdentifier,
         rep-it-integ     Integrity  -- "token" is REP-IT-TOKEN
 }
 REP-IT-TOKEN ::= SEQUENCE {
         tok-id           INTEGER (768),  -- shall contain 0300 (hex)
         context-id       Random-Integer,
         randSrc          Random-Integer,
         randTarg         Random-Integer,
         targ-name        Name,
         src-name         Name OPTIONAL,
         key-estb-rep     BIT STRING OPTIONAL
 }
 SPKM-ERROR ::= SEQUENCE {
         errorToken       ERROR-TOKEN,
         algId            AlgorithmIdentifier,
         integrity        Integrity  -- "token" is ERROR-TOKEN
 }
 ERROR-TOKEN ::=   SEQUENCE {
         tok-id           INTEGER (1024), -- shall contain 0400 (hex)
         context-id       Random-Integer
 }
 SPKM-MIC ::= SEQUENCE {
         mic-header       Mic-Header,
         int-cksum        BIT STRING
 }
 Mic-Header ::= SEQUENCE {
         tok-id           INTEGER (257), -- shall contain 0101 (hex)
         context-id       Random-Integer,

Adams Standards Track [Page 41] RFC 2025 SPKM October 1996

         int-alg [0]      AlgorithmIdentifier OPTIONAL,
         snd-seq [1]      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 (513), -- shall contain 0201 (hex)
         context-id       Random-Integer,
         int-alg [0]      AlgorithmIdentifier OPTIONAL,
         conf-alg [1]     Conf-Alg OPTIONAL,
         snd-seq [2]      SeqNum OPTIONAL
 }
 Wrap-Body ::= SEQUENCE {
         int-cksum        BIT STRING,
         data             BIT STRING
 }
 Conf-Alg ::= CHOICE {
         algId [0]        AlgorithmIdentifier,
         null [1]         NULL
 }
 SPKM-DEL ::= SEQUENCE {
         del-header       Del-Header,
         int-cksum        BIT STRING
 }
 Del-Header ::= SEQUENCE {
         tok-id           INTEGER (769), -- shall contain 0301 (hex)
         context-id       Random-Integer,
         int-alg [0]      AlgorithmIdentifier OPTIONAL,
         snd-seq [1]      SeqNum OPTIONAL
 }

other types –

Adams Standards Track [Page 42] RFC 2025 SPKM October 1996

  1. - from [RFC-1508] –
 MechType ::= OBJECT IDENTIFIER
 InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
    thisMech              MechType,
    innerContextToken     SPKMInnerContextToken
 }     -- when thisMech is SPKM-1 or SPKM-2
 SPKMInnerContextToken ::= CHOICE {
    req    [0] SPKM-REQ,
    rep-ti [1] SPKM-REP-TI,
    rep-it [2] SPKM-REP-IT,
    error  [3] SPKM-ERROR,
    mic    [4] SPKM-MIC,
    wrap   [5] SPKM-WRAP,
    del    [6] SPKM-DEL
 }
  1. - 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) dod(6) internet(1) security(5)
     integrity(3) md5-DES-CBC(1)}
 sum64-DES-CBC OBJECT IDENTIFIER ::=
    {iso(1) identified-organization(3) dod(6) internet(1) security(5)
     integrity(3) sum64-DES-CBC(2)}
 spkm-1 OBJECT IDENTIFIER ::=
    {iso(1) identified-organization(3) dod(6) internet(1) security(5)
     mechanisms(5) spkm(1) spkm-1(1)}
 spkm-2 OBJECT IDENTIFIER ::=
    {iso(1) identified-organization(3) dod(6) internet(1) security(5)
     mechanisms(5) spkm(1) spkm-2(2)}

END

Adams Standards Track [Page 43] RFC 2025 SPKM October 1996

Appendix B: Imported Types

 This appendix contains, for completeness, the relevant ASN.1 types
 imported from InformationFramework (1993), AuthenticationFramework
 (1993), and [PKCS3].
 AttributeType ::= OBJECT IDENTIFIER
 AttributeValue ::= ANY
 AttributeValueAssertion ::= SEQUENCE {AttributeType,AttributeValue}
 RelativeDistinguishedName ::= SET OF AttributeValueAssertion
    -- note that the 1993 InformationFramework module uses
    -- different syntax for the above constructs
 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
 DistinguishedName ::= RDNSequence
 Name ::= CHOICE {  -- only one for now
         rdnSequence       RDNSequence
 }
 Certificate ::= SEQUENCE {
         certContents      CertContents,
         algID             AlgorithmIdentifier,
         sig               BIT STRING
 }  -- sig holds the result of applying the signing procedure
    -- specified in algId to the BER-encoded octet string which
    -- results from applying the hashing procedure (also specified in
    -- algId) to the DER-encoded octets of CertContents
 CertContents ::= SEQUENCE {
         version [0]        Version DEFAULT v1,
         serialNumber       CertificateSerialNumber,
         signature          AlgorithmIdentifier,
         issuer             Name,
         validity           Validity,
         subject            Name,
         subjectPublicKeyInfo     SubjectPublicKeyInfo,
         issuerUID [1]      IMPLICIT UID OPTIONAL,  -- used in v2 only
         subjectUID [2]     IMPLICIT UID OPTIONAL   -- used in v2 only
 }
 Version ::= INTEGER {v1(0), v2(1)}
 CertificateSerialNumber ::= INTEGER
 UID ::= BIT STRING
 Validity ::= SEQUENCE {
         notBefore         UTCTime,
         notAfter          UTCTime
 }

Adams Standards Track [Page 44] RFC 2025 SPKM October 1996

 SubjectPublicKeyInfo ::= SEQUENCE {
         algorithm         AlgorithmIdentifier,
         subjectPublicKey  BIT STRING
 }
 CertificatePair ::= SEQUENCE {
         forward [0]      Certificate OPTIONAL,
         reverse [1]      Certificate OPTIONAL
 }         -- at least one of the pair shall be present
 CertificateList ::= SEQUENCE {
         certListContents        CertListContents,
         algId                   AlgorithmIdentifier,
         sig                     BIT STRING
 }  -- sig holds the result of applying the signing procedure
    -- specified in algId to the BER-encoded octet string which
    -- results from applying the hashing procedure (also specified in
    -- algId) to the DER-encoded octets of CertListContents
 CertListContents ::= SEQUENCE {
         signature               AlgorithmIdentifier,
         issuer                  Name,
         thisUpdate              UTCTime,
         nextUpdate              UTCTime OPTIONAL,
         revokedCertificates     SEQUENCE OF SEQUENCE {
              userCertificate       CertificateSerialNumber,
              revocationDate        UTCTime           } OPTIONAL
 }
 AlgorithmIdentifier ::= SEQUENCE {
         algorithm         OBJECT IDENTIFIER,
         parameter         ANY DEFINED BY algorithm OPTIONAL
 }  -- note that the 1993 AuthenticationFramework module uses
    -- different syntax for this construct
  1. -from [PKCS3] (the parameter to be used with dhKeyAgreement) –
 DHParameter ::= SEQUENCE {
   prime              INTEGER,  -- p
   base               INTEGER,  -- g
   privateValueLength INTEGER OPTIONAL
 }

Adams Standards Track [Page 45]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2025.txt · Last modified: 1996/10/23 15:53 (external edit)