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: - documents defining specific parameter bindings for particular language environments; - documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms." 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 - "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 -- The protocol version number (pvno) parameter is a BIT STRING which -- uses as many bits as necessary to specify all the SPKM protocol -- versions supported by the initiator (one bit per protocol -- version). The protocol specified by this document is version 0. -- Bit 0 of pvno is therefore set if this version is supported; -- similarly, bit 1 is set if version 1 (if defined in the future) is -- supported, and so on. Note that for unilateral authentication -- using SPKM-2, no response token is expected during context -- establishment, so no protocol negotiation can take place; in this -- case, the initiator must set exactly one bit of pvno. The version -- of REQ-TOKEN must correspond to the highest bit set in pvno. -- The "validity" parameter above is the only way within SPKM for -- the initiator to transmit desired context lifetime to the target. -- Since it cannot be guaranteed that the initiator and target have -- synchronized time, the span of time specified by "validity" is to -- be taken as definitive (rather than the actual times given in this -- parameter). Random-Integer ::= BIT STRING -- Each SPKM implementation is responsible for generating a "fresh" -- random number for the purpose of context establishment; that is, -- one which (with high probability) has not been used previously. -- There are no cryptographic requirements on this random number -- (i.e., it need not be unpredictable, it simply needs to be fresh). Context-Data ::= SEQUENCE { channelId ChannelId 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), th