Low Infrastructure Public Key Mechanisms: SPKM-3 and LIPKEY

The goal of the Generic Security Service Application Program Interface (GSS-API) is stated in the abstract of 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." SPKM-3 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 , SPKM-3 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 tokens defined in SPKM are intended to be used by application programs according to the GSS API "operational paradigm" (see 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. Many PKI-based protocols require a great deal of infrastructure, such as directory service that stores public-key certificates, protocols and applications that retrieve them for authentication procedures. To establish a mutually authenticated secure communication channel, SPKM-3 does not require directory services hence the term "low infrastructure". It is envisioned that typical use of SPKM-3 will involve mutual authentication, or (anonymous) unilateral authentication in conjunction with LIPKEY. Although unilateral authentication is available for use independent of LIPKEY, this is not generally recommended.

The SPKM-3 GSS-API mechanism will be identified by the following Object Identifier:

spkm-3 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) spkm(1) 3 }

SPKM-3 employs four types of algorithms: integrity algorithms (I-ALG), confidentiality algorithms (C-ALG), key establishment algorithms (K-ALG), and one-way functions (O-ALG) used to derive subkey for I-ALGs and C-ALGs. Each type, along with its purpose and a set of specific algorithms of a given type, is described in this section. In order to ensure at least a minimum level of interoperability among various implementations of SPKM-3, one of the integrity algorithms is specified as MANDATORY; all remaining examples (and any other algorithms) may optionally be supported by a given SPKM-3 implementation. During context establishment in SPKM-3, 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 for further details. As per [RFC2743], a context initiator can request that per-message integrity and confidentiality be available on context, by adding the GSS_C_INTEG_FLAG and GSS_C_CONF_FLAG to the flags passed to the GSS_Init_sec_context(). As per [RFC2743], confidentiality cannot be requested without integrity. Furthermore, if no integrity or confidentiality is requested, then no I-ALGs, C-ALGs, or OW-ALGs are negotiated, only (anonymous or mutual) authentication step happens.

An integrity 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 for the message. During the context establishment, initiator and target negotiate which integrity algorithms might be used on tokens after the security context is established. Additionally, the integrity of the context establishment tokens must be observed. Consequently, the integrity algorithms used during the context establishment might differ from the negotiated integrity algorithm. A consequence of unilateral authentication is that the initiator does not have a certificate of its own. Therefore, the initiator cannot use a digital signature algorithm during or after the context establishment. Instead, the initiator can only negotiate a message authentication code (MAC) algorithm that is based on a symmetric key, derived during the security context establishment. However, such algorithm cannot be used for integrity of the context establishment tokens because the symmetric key has not yet been established. Therefore, for integrity during the context establishment, a new NULL-MAC algorithm is defined and used by the initiator during anonymous authentication. During the context establishment, the target must use one of the digital signature algorithm in order to prevent a man-in-the-middle attack. Next, we list the I-AlGs for SPKM-3.

NULL-MAC NULL-MAC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) integrity(3) 3 } This algorithm (MANDATORY) is a null I-ALG that returns a zero length bit string regardless of the input passed to it. In unilateral authentication, the initiator MUST use the NULL-MAC in the first context establishment token. In general, NULL-MAC SHOULD NOT be included in a list of negotiated I-ALGs between the initiator and the target because it does not carry any security benefits (instead, the GSS_Init_sec_context() integ_avail flag SHOULD be set to false).

HMAC-MD5 HMAC-MD5 OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) internet(1) security(5) mechanisms(5) ipsec(8) isakmpOakley(1) 1 } This algorithm (MANDATORY) is described in . The HMAC-SHA1 algorithm is not a mandatory SPKM-3 I-ALG because SHA-1 is about half the speed of MD5 . A MAC based on an encryption algorithm like cast5CBC, DES EDE3, or RC4 is not mandatory because MD5 is 31 percent faster than the fastest of the three encryption algorithms .

md5WithRSAEncryption md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 } This algorithm (MANDATORY) provides data integrity and authenticity by computing an RSA signature on the MD5 hash of that data (details in ). For the integrity of the target to the initiator token, the target MUST use this algorithm for token integrity. In general, after the context is established a symmetric key is derived. For the performance reasons, md5WithRSAEncryption SHOULD NOT be include in a list of negotiated I-ALGs. For anonymous SPKM-3, md5WithRSAEncryption MUST NOT be included.

sha1WithRSAEncryption sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } This algorithm (OPTIONAL) is described in . It is listed in addition to md5WithRSAEncryption due to weaknesses in the MD5 hash algorithm . As with md5WithRSAEncryption, for performance reasons, sha1WithRSAEncryption SHOULD NOT be negotiated and for anonymous SPKM-3 MUST NOT be included.

dsaWithSHA1 dsaWithSHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 3 } This algorithm (RECOMMENDED) is described in . It is listed as an alternative to the RSA-based algorithms. If either initiator or target has DSA keys in their X509 certificate, this algorithm should be used for integrity of the context establishment tokens and/or an I-ALG. As with previous digital signature algorithms, dsaWithSHA1 SHOULD NOT be negotiated and for anonymous SPKM-3 MUST NOT be included.

DES-MAC DES-MAC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 10 } This algorithm (OPTIONAL) provides integrity by computing a DES MAC (as specified by ) on the data. It employs a derived symmetric key (see ) and a zero IV. Padding procedures to accommodate plaintext data lengths which may not be integral multiples of 8bytes are defined in .

MD5-DES-CBC md5-DES-CBC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) integrity(3) 1 } This algorithm (OPTIONAL) is included for backward compatibility with RFC2025. The algorithm provides integrity by, first, computing the "confounded" MD5 hash over the plaintext data (see for more details on computing a confounder) and, then, computing a DES-CBC MAC on the 16-byte MD5 result. DES-CBC employs a derived symmetric key (see ) and a zero IV. 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 sum64-DES-CBC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) integrity(3) 2 } This algorithm (OPTIONAL) is included for backward compatibility with RFC2025. The 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. Therefore, if this algorithm is specified, then DES-CBC confidentiality algorithm also MUST be specified. For comments regarding the security of this integrity algorithm, see .

A GSS 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-3 implementations for which exportability is not a concern). Confidentiality algorithms are used to generate the encrypted data for GSS_Wrap()/GSS_Unwrap.

AES256-CBC id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 42 } This algorithm (RECOMMENDED) is defined in .

AES128-CBC id-aes256-CBC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) 2 } This algorithm (RECOMMENDED) is defined in .

DES-EDE3-CBC des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } This algorithm (RECOMMENDED) is defined in .

cast5CBC cast5CBC OBJECT IDENTIFIER ::= { iso(1) memberBody(2) usa(840) nt(113533) nsn(7) algorithms(66) 10 } Parameters ::= SEQUENCE { iv OCTET STRING DEFAULT 0, - - Initialization vector keyLength INTEGER - - Key length, in bits } This algorithm is included for backward compatibility with RFC2025. The reference for the OID and description of the (OPTIONAL) cast5CBC algorithm is . The keyLength in the Parameters MUST be set to 128 bits. PKCS#5 padding (standard block padding) is recommended. All input data MUST be padded to the block length (64-bits).

This algorithm type 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. For SPKM-3, the key establishment algorithm must be dhKeyAgreement. This is because the initiator doesn't know the target's public key, and so cannot encrypt a session key with the target's public key.

dhKeyAgreement dhKeyAgreement OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-3(3) 1 } DHParameter ::= SEQUENCE { prime INTEGER, -- p base INTEGER, -- g privateValueLength INTEGER OPTIONAL } In this (MANDATORY) algorithm, the context key is generated jointly by the initiator and the target using the Diffie-Hellman key establishment algorithm . The DH public key is encoded as a BIT STRING according to . Implementations MUST support Oakley 1024-bit Modular Exponential (MODP) well-known group 2 and Oakley 2048-bit MODP well-known group 14 and SHOULD support Oakley 4096-bit MODP well-known group 16 .

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. 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 cast5CBC and HMAC-MD5 are the negotiated confidentiality and integrity algorithms, then the context key must be at least 256 bits. When the dhKeyAgreement is the K-ALG, then the length of the context key is the length of the Diffie-Hellman modulus, p, minus 8 bits. It is recommended that, at least, p = 1024. 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. It is recognized that existing hash functions may not satisfy required properties of OWFs. This is the reason for allowing negotiation of the O-ALG OWF during the context establishment process, 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. lists MD5 as a mandatory algorithm. Since MD5 has been found to have weaknesses when used as a hash , MD5 is excluded as an O-ALG for SPKM-3.

ID-SHA1 id-sha1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) 26 } The reference for the (MANDATORY) algorithm OID of id-sha1 is . The reference for SHA-1 algorithm corresponding to id-sha1 is .

This section discusses protocol-visible characteristics of SPKM-3; it defines elements of protocol for interoperability and is independent of language bindings per . Tokens transferred between GSS-API peers (for security context management and per-message protection purposes) are defined.

Two 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() and "Target" tokens, emitted by calls to GSS_Accept_sec_context() and consumed by calls to GSS_Init_sec_context(). Per , all the tokens emitted by the SPKM-3 GSS-API mechanism SHALL be enclosed within framing as follows:

InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { thisMech MechType, -- MechType is OBJECT IDENTIFIER representing "SPKM-3" innerContextToken ANY DEFINED BY thisMech } -- contents mechanism-specific The SPKM-3 innerContextToken is slightly different from the innerContextToken defined in . Previously proposed SPKM-ERROR token lacks certificate information and without a directory information makes it impossible to verify the token. Due to backward compatibility, we leave the old SPKM-ERROR token, but add a new token SPKM-GSS-ERROR which we describe in Section . The new 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, gss-err [7] SPKM-GSS-ERROR, ... } The tag values provided in SPKMInnerContextToken ("[0]" through "[7]") 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. 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 GGS_NEW_ERROR_TOKEN = 7 SPKM-3 implementation 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. All innerContextTokens are encoded using ASN.1 Distinguished Encoding Rules (DER) as described in . SPKM-3 proposes to use extensibility markers for most of the it's ASN1 structures. The SPKM-3 context establishment tokens are defined according to Section 10 and are compatible with . SPKM-3 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-3 uses random numbers for replay detection during context establishment. Sequence numbers are used to provide replay and out-of-sequence detection during the context initialization, if this has been requested by the application. SPKM-3 with mutual authentication sets up a context with an initiator first token (SPKM-REQ), a target reply token (SPKM-REP-TI), and finally an initiator second token (SPKM-REP-IT). For SPKM-3 with unilateral authentication used by LIPKEY, the SPKM-REP-IT token is not used. LIPKEY and SPKM-3 with mutual authentication place certain requirements on the contents of the SPKM-3 tokens, but the syntax of the SPKM-3 tokens are not different from SPKM-1 tokens. SPKM-3's use of dhKeyAgreement and token options allows for the initiator and target to exchange all public-key certificate(s) needed to accomplish context establishment. SPKM-3 MUST support X509 v3 certificates. The target always has an X.509 certificate and uses it to authenticate to the initiator. In unilateral authentication, the initiator is an anonymous principal. In SPKM-3, certificate validation follows the TLS model where the source provides its certificate and the certification chain up to the root certificate (mutual authentication). The target then provides its certificate and the certification chain up to the root certificate (unilateral and mutual authentication). Thus, the certification data consists of the root certificate followed by any certificates required to reach the user certificate.

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, -- for mutual authentication, certif-data MUST be present ... }

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

CertificatePair ::= SEQUENCE { issuedByThisCA [0] Certificate OPTIONAL, issuedToThisCA [1] Certificate OPTIONAL } -- SPKM-3 states that issuedByThisCA field is used. Having separate verification fields allows different key pairs (possibly corresponding to different algorithms) to be used for encryption/decryption and signing/verification. In CertificationPath, 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. When using unilateral anonymous authentication, the optional SPKM-REQ certif-data field is not used. When using mutual authentication, the CertificationPath userCertif field MUST contain the user (initiator) public-key certificate. It is needed in order for the target to authenticate the initiator in a later step.

REQ-TOKEN ::= SEQUENCE { req-contents Req-contents, algId AlgorithmIdentifier, -- in unilateral authentication, algId MUST be NULL-MAC -- in mutual authentication, algId MUST be one of -- the digital signature algorithms md5WithRSAEncryption, -- sha1WithRSAEncryptio, dsaWithSHA1 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 the 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 -- MAC-ing algorithm, "Integrity" holds the result of applying -- the MAC-ing 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 used as -- the key input) When using unilateral authentication, if the SPKM-3 initiator cannot calculate a req-integrity field due to the lack of a target certificate, it MUST use the NULL-MAC I-ALG described earlier in this memorandum. This will produce a zero length bit string in the Integrity field. When using mutual authentication, the algId needs to be one of md5WithRSAEncryption, or sha1WithRSAEncryption, or dsaWithSHA1. The signature will be based on the initiator's private key that corresponds to the certificate included in the certif-data field of the SPKM-REQ token.

Req-contents ::= SEQUENCE { tok-id INTEGER (256), -- shall contain 0100 (hex) context-id Random-Integer, -- see Section 2.9.2 pvno BIT STRING, -- protocol version number timestamp UTCTime OPTIONAL, randSrc Random-Integer, targ-name Name, -- see Section 2.5.1.2 for construction and verification -- of the target name. The target can use the "targ-name" -- to select among available certificates. src-name [0] Name OPTIONAL, 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 the MANDATORY and only K-ALG, dhKeyAgreement key-estb-req BIT STRING OPTIONAL, -- key estb. parameter corresponding to the initiator -- half of the dhKeyAgreement key. -- Established key MUST satisfy the key length constraints -- specified in Section 2.3.4. key-src-bind OCTET STRING OPTIONAL, -- will not be use in SPKM-3. auth-data AuthorizationData OPTIONAL, -- see RFC1964 for a discussion of auth-data. note, -- auth-data is integrity protected but not encrypted. ... }

Random-Integer ::= BIT STRING -- Each SPKM-3 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 -- SPKM-3 does not specify any channel bindings seq-number INTEGER OPTIONAL, -- sequence number options Options, -- GSS-API service options conf-alg Conf-Algs, -- a list of confidentiality algorithms intg-alg Intg-Algs, -- a list of integrity algorithms owf-alg OWF-Algs, -- a list of one-way functions for subkey derivation ... }

ChannelId ::= OCTET STRING Options ::= BIT STRING { delegation-state (0), -- not supported by SPKM-3 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 target's certificate data. -- it is always set to 1. ... } The SPKM-3 mechanism implementation is responsible for maintaining a mapping between the context-id value which is included in every token and a context_handle, thus associating an individual token with its proper context. Clearly the value of context_handle may be locally determined and may, in fact, be associated with memory containing sensitive data on the local system, and so having the context-id actually be set equal to a computed context_handle will not work in general. Conversely, having the context_handle actually be set equal to a computed context-id will not work in general either, because context_handle must be returned to the application by the first call to GSS_Init_sec_context() or GSS_Accept_sec_context(), whereas uniqueness of the context-id (over all contexts at both ends) may require that both initiator and target be involved in the computation. Consequently, context_handle and context-id must be computed separately and the mechanism implementation must be able to map from one to the other by the completion of context establishment at the latest. Computation of context-id during context establishment is accomplished as follows. Each SPKM-3 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-3), 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-3, 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 protocol version number (pvno) parameter is a BIT STRING which uses as many bits as necessary to specify all the SPKM-3 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. The version of REQ-TOKEN MUST correspond to the highest bit set in pvno. The "validity" parameter above is the only way within SPKM-3 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). SPKM-3 implementations MUST set the target-certif-data-required bit to 1 since (in most cases) the initiator does not have the target's certificate. A context establishment sequence based on SPKM-3 will perform unilateral authentication if the mutual-req bit is not set in the application's call to GSS_Init_sec_context(). SPKM-3 accomplishes this using both SPKM-REQ and SPKM-REP-TI (thereby authenticating the target to the initiator). Applications requiring authentication of both peers (initiator and 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 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 .

Conf-Algs ::= CHOICE { algs [0] SEQUENCE OF AlgorithmIdentifier, null [1] NULL, -- used when conf. is not available over context ... } -- for C-ALG (see for discussion of QOP) If the SPKM-3 implementation supports an algorithm weaker than cast5CBC, cast5CBC MUST be listed before the weaker algorithm to encourage the target to negotiate the stronger algorithm.

Intg-Algs ::= SEQUENCE OF AlgorithmIdentifier -- for I-ALG (see for discussion of QOP) In the case where the initiator is anonymous and will not have a certificate for itself, the initiator cannot use an integrity algorithm that uses a digital signature; it MUST use a MAC algorithm. If the SPKM-3 implementation supports an algorithm weaker than HMAC-MD5, HMAC-MD5 MUST be listed before the weaker algorithm to encourage the target to negotiate the stronger algorithm.

OWF-Algs ::= SEQUENCE OF AlgorithmIdentifier -- Contains exactly one algorithm in REQ-TOKEN for SPKM-3 -- 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

SPKM-REP-TI ::= SEQUENCE { responseToken REP-TI-TOKEN, certif-data CertificationData, -- to avoid "man-in-the-middle" attack, the target MUST -- sign responseToken using one of the digital signature -- algorithms and include its certificate so that the -- initiator can verify the signature ... } In both unilateral and mutual authentication in SPKM-3, the target always sends it's public-key certificate and certification chain, and the field target-certif-data-required is always set. The SPKM-REP-TI certif-data field is no longer OPTIONAL.

REP-TI-TOKEN ::= SEQUENCE { rep-ti-contents Rep-ti-contents, algId AlgorithmIdentifier, -- should be one of the digital signature algorithms 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 2.9.2 pvno [0] BIT STRING OPTIONAL, -- prot. version number timestamp UTCTime OPTIONAL, randTarg Random-Integer, src-name [1] Name OPTIONAL, targ-name Name, -- MUST contain whatever value was supplied in REQ-TOKEN -- See Section 2.5.1.2 for construction and verification of -- the targ-name. The initiator MUST verify that it is -- talking to the right target. randSrc Random-Integer, -- MUST contain whatever value was supplied in REQ-TOKEN 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.3.4. auth-data AuthorizationData OPTIONAL, ... } 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 error 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-TI-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-TI-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). The SPKM-3 target MUST NOT use a NULL-MAC I-ALG; it MUST use a signature algorithm like md5WithRSAEncryption, sha1WithRSAEncryption, or dsaWithSHA1. If the req-token has an algId of NULL-MAC, then the target MUST compute the rep-ti-integ on the concatenation of the req-contents and rep-ti-contents. When mutual authentication is used, the target verifies the initiator's SPKM-REQ token by verifying that the req-integrity field was computed by the owner of the userCertif field. This is phase 1 of authenticating the target. A note for implementors. Let's assume that the requestor calls the GSS_Init_sec_context() and does not request integrity or confidentiality services and, therefore, only authentication step is required. An artifact of [RFC-2025] mandates that Context-Data contains conf-alg, intg-alg, and owf-alg. Therefore to be backward compatible, we require that intg-alg and owf-alg are negotiated (since conf-alg is a CHOICE, it can be null). However, a better solution would be to make conf-alg, intg-alg, and owf-alg OPTIONAL.

When mutual authentication is requested, the initiator must construct a SPKM-REP-IT token. This is because attackers could replay SPKM-REQ tokens, and since the target doesn't have an infinite cache, and since SPKM-3 does not require synchronized time, a 3-way handshake is needed. Relevant SPKM-REP-IT syntax is as follows:

SPKM-REP-IT ::= SEQUENCE { responseToken REP-IT-TOKEN, algId AlgorithmIdentifier, -- MUST contain whatever value was supplied in REQ-TOKEN 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, -- see Section 2.9.2 randSrc Random-Integer, -- MUST contain whatever value was supplied in REQ-TOKEN randTarg Random-Integer, -- MUST contain whatever value was supplied in REP-TI-TOKEN targ-name Name, -- MUST contain whatever value was supplied in REP-TI-TOKEN src-name Name OPTIONAL, key-estb-rep BIT STRING OPTIONAL, -- contains the response to targets key-estb-str -- (if target selected a 2-pass K-ALG) ... } The randTarg field in the SPKM-REP-IT responseToken is randomly generated by the initiator, and so should be the same value that was in the SPKM-REP-TI rep-ti-contents randTarg field. The SPKM-REP-IT token algId field used to create the rep-it-integ field should use md5WithRSAEncryption, sha1WithRSAEncryption, or dsaWithSHA2. The initiator verifies the SPKM-REP-IT token by verifying that the req-it-integ field was computed by the owner of the targets certificate, obtained in the SPKM-REP-TI certif-data certificationPath userCertif field.

"Error" tokens are 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(). The SPKM-ERROR token proposed in [RFC-2025] is left in SPKM-3 only for backward compatibility. The new error token is described in the next section. The syntax of the SPKM-ERROR is as follows:

SPKM-ERROR ::= SEQUENCE { error-token ERROR-TOKEN, algId AlgorithmIdentifier, -- MUST be one of the digital signature algorithms integrity Integrity -- "token" is ERROR-TOKEN } ERROR-TOKEN ::= SEQUENCE { tok-id INTEGER (1024), -- shall contain 0400 (hex) context-id Random-Integer }

SPKM-ERROR token lacks the certificate used to compute the integrity of the token. In the low infrastructure and the absence of directory services, the receiving side of the SPKM-ERROR token is therefore unable to verify the integrity of the SPKM-ERROR. Therefore, in the SPKM-GSS-ERROR token, we propose to add certificate information. Furthermore, the old token lacks any information regarding the error that had occurred. Therefore, in the SPKM-GSS-ERROR token, we propose to add the return major_status and minor_status values of GSS_init_sec_context() or GSS_accept_sec_context(). The syntax of SPKM-GSS-ERROR is as follows:

SPKM-GSS-ERROR ::= SEQUENCE { error-token GSS-ERROR-TOKEN, algId AlgorithmIdentifier, certif-data CertificationData, -- MUST be one of the digital signature algorithms integrity Integrity, -- "token" is ERROR-TOKEN ... } GSS-ERROR-TOKEN ::= SEQUENCE { tok-id INTEGER (1280), -- shall contain 0500 (hex) context-id Random-Integer, -- if sent by target, this field should contain the value -- of the context-id in Req-contents -- if sent by initiator, this field should contain the -- value of the context-id in Rep-ti-contents major-status [0] INTEGER, -- the GSS major status value minor-status [1] INTEGER, -- the GSS minor status value ... } As with the old token, the SPKM-GSS-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-GSS-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. If GSS_Init_sec_context() receives an error token (whether valid or invalid), the initiator decides if it can recover from the error sent by the target. If not, the initiator will create an error token with major status of GSS_S_FAILURE and the minor status GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT and will return GSS_S_CONTINUE_NEEDED along with the token. If the initiator can recover from the error, 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) when it was expecting an SPKM-REP-IT token, if the target decides to recover from the error sent by the initiator, the target will regenerate SPKM-REP-TI as its output token and return a major status code of GSS_S_CONTINUE_NEEDED. If the target can not cover, it should return an appropriate major status code (e.g., GSS_S_NO_CRED) along with a minor status of GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT and all context-relevant information will be deleted. If GSS_Accept_sec_context() receives an error token when it was expecting an SPKM-REQ token, it should return an 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. md5WithRsaEncryption is currently stipulated for the signing of context establishment tokens. Discrepancies involving modulus bitlength can be resolved through judicious use of the SPKM-GSS-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-GSS- ERROR signed with the strongest RSA that it supports (e.g. 512). Furthermore, the target can include an appropriate minor_status value (GSS_SPKM_S_SG_WEAK_KEY). 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.

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

Use of the GSS_wrap() / 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 ... }

Checksum calculation procedure (common to all algorithms -- note that for SPKM-3 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 md5WithRSAEncryption algorithm, then the checksum is formed by computing an MD5 hash over the plaintext data (prepended by the header), and then computing an RSA signature on the 16-byte MD5 result. The signature is computed using the RSA private key retrieved from the credential 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 ). Again, the result (whose length is implied by int-alg) is stored in the int-cksum field. For block cipher-based algorithms, before encryption plaintext data is padded to the next highest multiple of the block size (8bytes for DES-based algorithms), by appending between 1 and block size bytes, the value of each such byte being the total number of pad bytes.

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-3 purely for security, as opposed to reliability, reasons (that is, to avoid malicious loss, replay, or re-ordering of SPKM-3 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_GetMIC() or GSS_Wrap() token, the sender's seq. number is incremented by 1.

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.

Use of the 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_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 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. 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, ... }

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_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 If int-alg specifies md5-DES-CBC and conf-alg specifies anything other than DES-CBC, then the checksum is computed according to 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 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 ) 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-3 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.

Sequence numbers are computed and processed for GSS_Wrap() exactly as specified in and .

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 ), or (c) int-alg is sum64-DES-CBC (encryption as specified in ): 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. 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 (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). For block cipher-based algorithms, before encryption plaintext data is padded to the next highest multiple of the block size (8bytes for DES-based algorithms), by appending between 1 and block size bytes, the value of each such byte being the total number of pad bytes.

The token emitted by GSS_Delete_sec_context() is based on the format for tokens emitted by GSS_GetMIC(). [RFC2743] includes GSS_Delete_sec_context() only for backward compatibility with GSS-API Version 1. Therefore, in SPKM-3 we propose to follow the procedure recommended in [RFC2743]. Both peers should invoke GSS_Delete_sec_context() independently and pass a null output_context_token buffer to indicate that no context_token is required but should delete relevant locally-stored context information. Peers should signal the deletion of context via other channel (eg., closing a network connection, or a higher level error message such as an RPCSEC_GSS error message). 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_GetMIC(). The field int-cksum will be calculated as for tokens emitted by 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-3 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).

This section discusses the name types which may be passed as input to the SPKM3's GSS_Import_name() call, and their associated identifier values.

This section discusses name forms which are to be supported by all conformant implementations of the SPKM3 GSS-API mechanism.

This name form shall be represented by the Object Identifier (FIXME: need an OID). The recommended symbolic name for this type is GSS_SPKM3_NT_PRINCIPAL_NAME. This name type corresponds to the string representation of an X500 Distinguished Name. It is an RFC2253 [RFC2253] compliant string representation of the distinguished name.

This name form is used to represent services associated with host computers and should use the symbolic name of GSS_C_NT_HOSTBASED_SERVICE. This name form is constructed using two elements, "service" and "hostname", as follows: "service@hostname". If only "service" is specified as an input, then the default of the localhost's "hostname" is used. The initiator always constructs a target name. We assume that during the construction of the REQ-TOKEN the initiator has no access to the target's certificate and therefore has to construct the target name with the information provided by the application which might be of the form "service@host" which is of GSS_C_NT_HOSTBASED_SERVICE name type. "host" is canonicalized by attempting a DNS lookup and using the fully-qualified domain name which is returned, or by using the "host" as provided if the DNS lookup fails. Then, the initiator should convert the GSS_C_NT_HOSTBASED_SERVICE name to GSS_SPKM3_NT_PRINCIPAL_NAME name by first writing it as a common name "CN=service/host", then, encoding it in a single RDN sequence. When the initiator processes REP-TI-TOKEN, it verifies that target name the initiator constructed matches the information in the target's certificate. A note to implementors, a target can also perform name matching of the supplied target name in REQ-TOKEN against the target's certificate, this would provide early error detection. The target can use the provided name to locate the appropriate credentials. During the validation of a name (either when the target validates the name of the initiator or vice versa), a match occurs: if the target name is the same as the target's subject name in the target's certificate or the "directoryName" extension of the target's subject alternate name (SAN) in the target's certificate. In this case, subject names are first represented in the RFC2253 format. A match is performed according to the rules listed in RFC2252 [RFC2252]. if the target name is just a common name ("CN=service/host") and the common name matches the CN portion of the target's subject name or the CN portion of a DN entry of the target's SAN in the target certificate. For instance, if target name is "CN=nfs/citi.umich.edu" and target's subject name is "C=US, ST=Michigan, L=Ann Arbor, O=University of Michigan, OU=CITI Production KCA, CN=nfs/citi.umich.edu" if the target name contains just a common name ("CN=service/host") and the "host" matches the CN portion of the target's subject name in the target's certificate or a "dsnName" entry of the target's SAN in the target's certificate. For instance, if target name is "CN=nfs/citi.umich.edu" and target's subject name is "C=US, ST=Michigan, L=Ann Arbor, O=University of Michigan, OU=CITI Production KCA, CN=citi.umich.edu" or if the certificate has "dNSName" SAN extension with a value of "citi.umich.edu". We RECOMMEND that target's certificate is restricted with an extended key usage (EKU). For instance, an NFSv4 server should have a certificate with an EKU of id-spkm3-nfsv4 (FIXME: need an OID for it!).

This name form is used to represent an anonymous initiator and should use the symbolic name of GSS_C_NT_ANONYMOUS and a printable string "CN=<anonymous>". For anonymous SPKM-3, in REQ-TOKEN, since the field is OPTIONAL, no src_name is filled in. When the target process such token, it knows that initiator is anonymous. If the initiator uses a digital signature algorithm for integrity of the REQ-TOKEN but does not include the source name, it is a protocol error.

This name type represents a self-describing object, whose framing structure is defined at the mechanism-independent level by GSS-API Version 2. When generated by the SPKM3 mechanism, the mechanism OID within the exportable name shall be that of the SPKM3 mechanism. The mechanism-specific name component within the exportable name should be created by taking the following steps: First, start with the GSS_SPKM3_NT_PRINCIPAL_NAME name form. This name type corresponds to the string representation of an X500 Distinguished Name. It is an RFC2253 [RFC2253] compliant string representation of the distinguished name with the following additional canonicalizations: Leading zeros are removed from attribute types that are encoded as dotted decimal OIDs. DirectoryString attribute values of type PrintableString and UTF8String are not in hexadecimal format DirectoryString attribute values of types other than PrintableString and UTF8String are output in hexadecimal format Leading and trailing white space characters are removed from non-hexadecimal attribute values (unless the value consists entirely of white space characters) Internal substrings of one or more white space characters are converted to a single space in non-hexadecimal attribute values Relative Distinguished Names containing more than one Attribute Value Assertion (AVA) are output in the following order: an alphabetical ordering of AVAs containing standard keywords, followed by a numeric ordering of AVAs containing OID keywords. The only characters in attribute values that are escaped are those which section 2.4 of RFC2253 states must be escaped (they are escaped using a preceding backslash character) Then, take the resulting string and create an ASN1 Name. Then DER encode the ASN1 name structure.

Since in SPKM-3 the target always authenticates to the initiator, it must possess an X.509 certificate and a corresponding private key. Typically, the certificate and private key are stored on the local file system (or also possibly on a secure hardware such as a smart card). The SPKM-3 implementation must have means of finding where the credentials are stored and be able to retrieve them. If the initiator engages in mutual authentication with the target, the initiator must have an X.509 certificate as well. Both the target and the initiator have to have access to and ability to retrieve certificates of the trusted Certification Authorities.

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

This section recommends common symbolic names for minor_status values to be returned by the SPKM-3 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.

Minor Status Code MSB, bit 31, SET.

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

Minor Status Code bit 30 OFF.

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

Minor Status Code MSB, bit 31, OFF.

GSS_SPKM_S_SG_CONTEXT_ESTABLISHED /* "Context is already fully established" */ GSS_SPKM_S_SG_BAD_INT_ALG_TYPE /* "Unknown integrity algorithm type in token" */ GSS_SPKM_S_SG_BAD_CONF_ALG_TYPE /* "Unknown confidentiality algorithm type in token" */ GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_TYPE /* "Unknown key establishment algorithm type in token" */ GSS_SPKM_S_SG_CTX_INCOMPLETE /* "Attempt to use incomplete security context" */ GSS_SPKM_S_SG_BAD_INT_ALG_SET /* "No integrity algorithm in common from offered set" */ GSS_SPKM_S_SG_BAD_CONF_ALG_SET /* "No confidentiality algorithm in common from offered set" */ GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_SET /* "No key establishment algorithm in common from offered set" */ GSS_SPKM_S_SG_BAD_OWF_ALG_SET /* "No owf 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" */ GSS_SPKM_S_SG_ASN1_ERROR /* "Problem with ASN1 encoding/decoding */ GSS_SPKM_S_SG_BAD_TOKEN GSS_SPKM_S_SG_X509_VERIFY_FAILED /* failed to verify a certificate */ GSS_SPKM_S_SG_X509_CRL_FAILED /* failed to verify a certificate because it was revoked */ GSS_SPKM_S_SG_X509_BAD_PRV_KEY /* failed to acquire credentials: unable to get the private key */ GSS_SPKM_S_SG_BAD_SIG_ALG_TYPE /* Unknown integrity algorithm in context establishment token */ GSS_SPKM_S_SG_SIG_FAILED /* failed to verify the integrity of the token */ GSS_SPKM_S_SG_BAD_CRED_USAGE /* requested credential for neither initiator or target */ GSS_SPKM_S_SG_BAD_CRED_FILENAME /* provided invalid (filename) location for the credentials */ GSS_SPKM_S_SG_BAD_DIRECTION /* bad direction in the checksum */ GSS_SPKM_S_SG_BAD_NAME /* provided name did not match the name in credentials */

The Quality of Protection (QOP) parameter is used in the SPKM-3 GSS-API mechanism as input to GSS_GetMIC() and GSS_Wrap()) to select among alternate confidentiality and integrity- checking algorithms. Once these sets of algorithms have been agreed upon by the context initiator and target, the QOP parameter simply selects from these ordered sets. More specifically, the SPKM-REQ token sends an ordered sequence of Alg. IDs specifying integrity-checking algorithms supported by the initiator and an ordered sequence of Alg. IDs specifying confidentiality algorithms supported by the initiator. The target returns the subset of the offered integrity-checking Alg. IDs which it supports and the subset of the offered confidentiality Alg. IDs which it supports in the SPKM-REP-TI token (in the same relative orders as those given by the initiator). Thus, the initiator and target each know the algorithms which they themselves support and the algorithms which both sides support (the latter are defined to be those supported over the established context). The QOP parameter has meaning and validity with reference to this knowledge. For example, an application may request integrity algorithm number 3 as defined by the mechanism specification. If this algorithm is supported over this context then it is used; otherwise, GSS_S_FAILURE and an appropriate minor status code are returned. The QOP parameter for SPKM-3 is defined to be a 32-bit unsigned integer (an OM_uint32) with the following bit-field assignments:

Confidentiality Integrity 31 (MSB) 16 15 (LSB) 0 ----------------------------------|---------------------------------- | TS (5) | U(3) | IA (4) | MA (4) | TS (5) | U(3) | IA (4) | MA(4) | ----------------------------------|---------------------------------- where TS is a 5-bit Type Specifier (a semantic qualifier whose value specifies the type of algorithm which may be used to protect the corresponding token -- see below for details); U is a 3-bit Unspecified field (available for future use/expansion); IA is a 4-bit field enumerating Implementation-specific Algorithms; and MA is a 4-bit field enumerating Mechanism-defined Algorithms. The interpretation of the QOP parameter is as follows (note that the same procedure is used for both the confidentiality and the integrity halves of the parameter). The MA field is examined first. If it is non-zero then the algorithm used to protect the token is the mechanism-specified algorithm corresponding to that integer value. If MA is zero then IA is examined. If this field value is non-zero then the algorithm used to protect the token is the implementation- specified algorithm corresponding to that integer value (if this algorithm is available over the established context). Note that use of this field may hinder portability since a particular value may specify one algorithm in one implementation of the mechanism and may not be supported or may specify a completely different algorithm in another implementation of the mechanism. Finally, if both MA and IA are zero then TS is examined. A value of zero for TS specifies the default algorithm for the established context, which is defined to be the first algorithm on the initiator's list of offered algorithms (confidentiality or integrity, depending on which half of QOP is being examined) which is supported over the context. A non-zero value for TS corresponds to a particular algorithm qualifier and selects the first algorithm supported over the context which satisfies that qualifier. 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 an