Internet Draft C. Adams, Bell-Northern Research draft-ietf-cat-spkmgss-01.txt October 30, 1994 The Simple Public-Key GSS-API Mechanism (SPKM) STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Comments on this document should be sent to "cat-ietf@mit.edu", the IETF Common Authentication Technology WG discussion list. ABSTRACT This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using the Simple Public-Key Mechanism. BACKGROUND Although the Kerberos Version 5 GSS-API mechanism [KRB5] is becoming well-established in many environments, it is important in some applications to have a GSS-API mechanism which is based on a public- key, rather than a symmetric-key, infrastructure. One such mechanism was described as part of the Distributed Authentication Security Service (DASS) in [RFC-1507]. However, the mechanism described in this document has been proposed as an alternative to the DASS mechanism for several reasons. 1) The SPKM is simpler than DASS, containing no non-essential functionality. Adams Document Expiration: 30 April 1995 1 2) The SPKM allows both unilateral and mutual authentication to be accomplished without the use of secure timestamps, whereas DASS requires timestamps for replay detection. This enables environments which do not have access to secure time to nevertheless have access to secure authentication. 3) The SPKM uses Algorithm Identifiers to specify various algorithms to be used by the communicating peers. This allows maximum flexibility for a variety of environments, for future enhancements, and for alternative algorithms. 4) The SPKM allows the option of a true, asymmetric algorithm- based, digital signature in the gss_sign() and gss_seal() operations, whereas DASS uses an integrity checksum based on a MAC computed with a symmetric algorithm (DES). For some environments, the availability of true, non-repudiable digital signatures is a necessity. 5) SPKM data formats and procedures are designed to be as similar to those for the Kerberos mechanism as is practical. This is done for ease of implementation in those environments where Kerberos has already been implemented. For the above reasons, it is felt that the SPKM will offer greater flexibility and functionality than DASS, without undue complexity or overhead. KEY MANAGEMENT The key management employed in SPKM is intended to be as compatible as possible with both X.509 [X.509] and PEM [RFC-1422], since these represent large communities of interest and show relative maturity in standards. ACKNOWLEDGMENTS Much of the material in this document is based on the Kerberos Version 5 GSS-API mechanism [KRB5], and is intended to be as compatible with it as possible. This document also owes a great debt to Warwick Ford and Paul Van Oorschot of Bell-Northern Research for many fruitful discussions, to Kelvin Desplanque of Domus Software for implementation-related clarifications, and to John Linn of OpenVision Technologies for helpful comments. Adams Document Expiration: 30 April 1995 2 1. OVERVIEW The goal of the Generic Security Service Application Program Interface (GSS-API) is stated in the abstract of [RFC-1508] as follows: "This Generic Security Service Application Program Interface (GSS- API) definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: - documents defining specific parameter bindings for particular language environments; - documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms." The SPKM is an instance of the latter type of document and is therefore termed a "GSS-API Mechanism". This mechanism provides authentication, key establishment, data integrity, and data confidentiality in an on-line distributed application environment using a public-key infrastructure. Because it conforms to the interface defined by [RFC-1508], SPKM can be used as a drop-in replacement by any application which makes use of security services through GSS-API calls (for example, any application which already uses the Kerberos GSS-API for security). The use of a public-key infrastructure allows non-repudiable digital signatures 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, which are identical except that SPKM-2 requires the presence of secure timestamps for the purpose of replay detection during context establishment and SPKM-1 does not. This allows greater flexibility for applications since secure timestamps cannot always be guaranteed to be available in a given environment. Adams Document Expiration: 30 April 1995 3 2. ALGORITHMS A number of algorithm types are employed in SPKM. Each type, along with its purpose and a set of specific examples, is described in this section. 2.1 Integrity Algorithm (I-ALG): Purpose: This algorithm is used to ensure that a message has not been altered in any way after being constructed by the legitimate sender. Depending on the algorithm used, the application of this algorithm may also provide authenticity and non- repudiability for the message. Examples: md5WithRSA OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 3 } This algorithm provides data integrity and non-repudiation by computing an RSA signature on the MD5 hash of that data. Note that this is equivalent to md5WithRSAEncryption {1 2 840 113549 1 1 4}, which is defined in [PKCS1]. DES-MAC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 10 } This algorithm provides data integrity by computing a DES MAC (as specified by [FIPS-113]) on that data. md5-DES-CBC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) xx } This algorithm provides data integrity by encrypting, using DES CBC, the MD5 hash of that data. This will typically be faster in practice than computing a DES MAC if the input data is not extremely short (e.g., a few bytes). Note that the strength of this integrity mechanism is (at most) equal to the strength of DES under a known-plaintext attack. sum64-DES-CBC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) xx } Adams Document Expiration: 30 April 1995 4 This algorithm provides data integrity by encrypting, using DES CBC, the concatenation of the data and the sum of all the input data blocks (the sum computed using addition modulo 2**64 - 1). Thus, in this algorithm, encryption is a requirement for the integrity to be secure. For comments regarding the security of this mechanism, see [Juen84, Davi89]. 2.2 Sequence Algorithm (S-ALG): Purpose: This symmetric algorithm is used to generate the encrypted sequence number for a token. Because the input to the integrity checksum (computed using an I-ALG) includes the encrypted sequence number, an invalid message with a valid sequence number, and a valid message with an invalid sequence number will both be detected. (Note that here an invalid sequence number is one which decrypts to a value that the receiver was not expecting and an invalid message is one which causes the integrity check to fail.) Example: DES-CBC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 7 -- carries IV as a parameter } 2.3 Confidentiality Algorithm (C-ALG): Purpose: This symmetric algorithm is used to generate the encrypted data for gss_seal(). Example: DES-CBC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 7 -- carries IV as a parameter } Adams Document Expiration: 30 April 1995 5 2.4 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 S-ALG, 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 symmetric key is authenticated. Example: id-rsa-key-transport OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 22 -- imported from [X9.44] } In this algorithm, the context key is generated by the initiator, encrypted with the RSA public key of the target, and sent to the target. The target need not respond to the initiator for the key to be established. dhKeyAgreement OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-3(3) 1 } In this algorithm, the context key is generated jointly by the initiator and the target using the Diffie-Hellman key establishment algorithm. The target must therefore respond to the initiator for the key to be established (so this K-ALG cannot be used with unilateral authentication in SPKM-2 (see Section 3.1)). During context establishment in SPKM, the initiator offers a set of possible symmetric encryption algorithms and a set of possible integrity algorithms to the target. The symmetric algorithms selected by the target become ones that may be used for S-ALG and C-ALG over the established context. The integrity algorithms selected by the target become ones that may be used for I-ALG over the established context. Note that the order of the selected integrity algorithms defines the values of the Quality of Protection (QOP) parameter used in the gss_sign() and gss_seal() calls -- see Section 5.2 for further details. Note also that if no response is expected from the target (unilateral authentication in SPKM-2) then the algorithms offered by the initiator are the ones that may be used over the context (if this is unacceptable to the target then an error message must be sent to the initiator so that the context is never established). Adams Document Expiration: 30 April 1995 6 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 it 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 an error token must be sent so that the context is never established). If necessary (that is, if the target chooses a 2-pass K-ALG such as dhKeyAgreement), the initiator will send its key half in a response to the target. In future versions of SPKM, other algorithms may be specified for any or all of I-ALG, S-ALG, C-ALG, and K-ALG. 3. TOKEN FORMATS This section discusses protocol-visible characteristics of the GSS- API mechanism to be implemented atop the SPKM; it defines elements of protocol for interoperability and is independent of language bindings per [RFC-1509]. The SPKM GSS-API mechanism will be identified by an Object Identifier representing "SPKM-1" or "SPKM-2", having the value: {iso(1), org(3), dod(5), internet(1), security(5), SPKM-1(xx)} or {iso(1), org(3), dod(5), internet(1), security(5), SPKM-2(xx)}, where SPKM-1 uses random numbers for replay detection during context establishment and SPKM-2 uses timestamps. Tokens transferred between GSS-API peers (for security context management and per-message protection purposes) are defined. 3.1. Context Establishment Tokens Three classes of tokens are defined in this section: "Initiator" tokens, emitted by calls to gss_init_sec_context() and consumed by calls to gss_accept_sec_context(); "Target" tokens, emitted by calls to gss_accept_sec_context() and consumed by calls to gss_init_sec_context(); and "Error" tokens, potentially emitted by calls to gss_init_sec_context(), gss_accept_sec_context(), gss_delete_sec_context(), gss_process_context_token(), gss_verify(), and gss_unseal() and consumed by calls to gss_process_context_token(). Per RFC-1508, Appendix B, the initial context establishment token will be enclosed within framing as follows: Adams Document Expiration: 30 April 1995 7 InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { thisMech MechType -- MechType is OBJECT IDENTIFIER -- representing "SPKM-1" or "SPKM-2" innerContextToken ANY DEFINED BY thisMech -- contents mechanism-specific } The innerContextToken of the initial context token will consist of an SPKM_REQ message containing a token-id (TOK_ID) field which shall contain the value 0100 (hex). The above GSS-API framing shall be applied to all tokens emitted by the SPKM GSS-API mechanism, including SPKM_REP_TI, SPKM_REP_IT, SPKM_ERROR, context-deletion, and per-message tokens, not just to the initial token in a context establishment sequence. While not required by RFC-1508, this enables implementations to perform enhanced error-checking. The innerContextToken field of context establishment tokens for the SPKM GSS-API mechanism will consist of a message (SPKM_REQ, SPKM_REP_TI, SPKM_REP_IT or SPKM_ERROR) containing a TOK_ID field having the value 0100 (hex) for SPKM_REQ messages, 0200 (hex) for SPKM_REP_TI messages, 0300 (hex) for SPKM_REP_IT messages, and 0400 (hex) for SPKM_ERROR messages. All innerContextTokens are encoded using Abstract Syntax Notation One Basic Encoding Rules (ASN.1 BER). The SPKM context establishment tokens are defined according to [X.509] Section 10. 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 Authentica- tion", when mutual authentication is requested by the initiator. SPKM-2 (timestamps) uses Section 10.2, "One-way Authentication", when performing unilateral authentication of the initiator to the target and uses Section 10.3, "Two-way Authentication", when mutual authen- tication is requested by the initiator. The implication of the above paragraph is that for SPKM-2 unilateral authentication no negotiation of K-ALG can be done (the target either accepts the K-ALG given by the initiator or disallows the context). For SPKM-2 mutual or SPKM-1 unilateral authentication some negotia- tion is possible, but the target can only choose among the one-pass K-ALGs offered by the initiator (or disallow the context). For SPKM-1 mutual authentication the target can choose any one- or two- pass K-ALG offered by the initiator. It is envisioned that typical use of SPKM-1 or SPKM-2 will involve mutual authentication. Although unilateral authentication is avail- able for both mechanisms, its use is not generally recommended. Adams Document Expiration: 30 April 1995 8 3.1.1. Context Establishment Tokens - Initiator (first token) In order to accomplish context establishment, it is necessary that both the initiator and the target have access to the other party?s encryption and verfication certificate(s). In some environments the initiator may choose to acquire all certificates and send the relevant ones to the target in the first token. In other environ- ments each side may individually obtain the certificate data it needs. In either case, however, the SPKM implementation must have the ability to obtain certificates which correspond to a supplied Name. The actual mechanism to be used to achieve this is a local implementation matter and is therefore outside the scope of this specification. Relevant SPKM_REQ syntax is as follows (note that imports from other documents are given in Appendix A): SPKM-REQ ::= SEQUENCE { requestToken [0] REQ_TOKEN certif_data [1] CertificationData OPTIONAL auth_data [2] AuthorizationData OPTIONAL -- see [RFC-1510] for a discussion of auth-data } CertificationData ::= SEQUENCE { certificationPath [0] CertificationPath certificateRevocationList [1] CertificateList OPTIONAL } CertificationPath ::= SEQUENCE { userEncCertif [0] SingleCertificate userVerifCertif [1] SingleCertificate OPTIONAL -- may send separate verification certificate -- to allow different algorithms to be used for -- decryption and signing theCACertificates [2] SEQUENCE OF CertificatePair OPTIONAL } -- certif. path from target to source SingleCertificate ::= CHOICE { -- only one for now Certificate -- imported from [X.509] } -- (1993) Adams Document Expiration: 30 April 1995 9 REQ_TOKEN ::= SIGNED SEQUENCE { tok_id [0] INTEGER -- shall contain 0100 (hex) timestamp [1] UTCTime -- may be NULL for mechanism SPKM-1 randSrc [2] Random_Integer, targ_name [3] Name, src_name [4] Name, req_data [5] Context_Data, validity [6] Validity OPTIONAL -- validity interval for key (may be used in the -- computation of security context lifetime) key_estb_set [7] Key_Estb_Alg -- specifies set of key establishment algorithms key_estb_req [8] BIT STRING -- key estb. request corresponding to first K-ALG in set } Random_Integer ::= BIT STRING Context_Data ::= SEQUENCE { channelId [0] ChannelId, -- channel bindings seq_number [1] INTEGER OPTIONAL -- sequence number options [2] Options symm_alg [3] Symm_Alg -- symmetric enc. alg. intg_alg [4] Intg_Alg -- integrity algorithm } ChannelId ::= OCTET STRING Options ::= BIT STRING { delegation_state (0), mutual_state (1), replay_det_state (2), sequence_state (3), conf_avail (4), integ_avail (5) } Symm_Alg ::= SEQUENCE OF AlgorithmIdentifier -- for S-ALG, C-ALG -- (first id. in agreed -- set is default alg. -- for context) Intg_Alg ::= SEQUENCE OF AlgorithmIdentifier -- order of agreed seq. -- is constrained by -- semantics of QOP -- parameter (see 5.2) Key_Estb_Alg ::= SEQUENCE OF AlgorithmIdentifier -- to allow negotiation -- of K-ALG Adams Document Expiration: 30 April 1995 10 A context establishment sequence based on the SPKM will perform uni- lateral 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) should request mutual authentication, resulting in "mutual_state" being set within SPKM_REQ Options. In response to such a request, the context target will reply to the initiator with a token containing either an SPKM_REP_TI or SPKM_ERROR. If mechanism SPKM-2 has been chosen, this completes the (timestamp-based) mutual authentication context establishment exchange. If mechanism SPKM-1 has been chosen and SPKM_REP_TI is sent, the initiator will then reply to the target with either an SPKM_REP_IT or SPKM_ERROR, completing the (random-number-based) mutual authentication context establishment exchange. 3.1.2. Context Establishment Tokens - Target Relevant SPKM_REP_TI syntax is as follows: SPKM_REP_TI ::= SIGNED SEQUENCE { tok_id [0] INTEGER -- shall contain 0200 (hex) timestamp [1] UTCTime -- may be NULL for -- mechanism SPKM-1 randTarg [2] Random_Integer, src_name [3] Name, randSrc [4] Random_Integer, rep_data [5] Context_Data, key_estb_id [6] AlgorithmIdentifier OPTIONAL -- used if target is changing key estb. algorithm -- (must be a member of initiator?s key_estb_set) key_estb_str [7] BIT STRING OPTIONAL -- contains either the response to initiator?s -- key_estb_req (if init. used a 2-pass K-ALG) or -- the key_estb_req corresponding to K-ALG supplied -- in above key_estb_id } 3.1.3. Context Establishment Tokens - Initiator (second token) Relevant SPKM_REP_IT syntax is as follows: SPKM_REP_IT ::= SIGNED SEQUENCE { tok_id [0] INTEGER -- shall contain 0300 (hex) randTarg [1] Random_Integer, targ_name [2] Name, key_estb_rep [3] BIT STRING OPTIONAL -- contains the response to target?s key_estb_str -- (if target selected a 2-pass K-ALG) } Adams Document Expiration: 30 April 1995 11 3.1.4. Error Token The syntax of SPKM_ERROR is as follows: SPKM_ERROR ::= SIGNED SEQUENCE { tok_id [0] INTEGER, -- shall contain 0400 (hex) pvno[1] INTEGER, -- protocol version number error-code[2] INTEGER, guilty-seq[3] OCTET STRING OPTIONAL, -- encrypted sequence number of the -- token which caused this error -- (empty if seq. nums not used) e-text[4] PrintableString OPTIONAL, e-data[5] OCTET STRING OPTIONAL } Values to be transferred in the error-code field of a SPKM_ERROR message are defined in Section 5 of this specification. 3.2. Per-Message and Context Deletion Tokens Three classes of tokens are defined in this section: "Sign" tokens, emitted by calls to gss_sign() and consumed by calls to gss_verify(); "Seal" tokens, emitted by calls to gss_seal() and consumed by calls to gss_unseal(); and context deletion tokens, emitted by calls to gss_delete_sec_context() and consumed by calls to gss_process_context_token(). 3.2.1. Per-message Tokens - Sign Use of the gss_sign() call yields a token, separate from the user data being protected, which can be used to verify the integrity of that data as received. The token and the data are 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_SIGN token has the following format: SPKM_SIGN ::= SEQUENCE { sign_header [0] Sign_Header, sign_body [1] Sign_Body } Adams Document Expiration: 30 April 1995 12 Sign_Header ::= SEQUENCE { tok_id [0] INTEGER -- shall contain 0101 (hex) int_alg [1] AlgorithmIdentifier, -- Integrity algorithm indicator (must -- be one of the agreed integrity -- algorithms for this context). -- NULL = default id. seq_alg [2] AlgorithmIdentifier, -- Encryption alg. to compute sequence -- (must be one of the agreed symmetric -- algorithms for this context). -- NULL = default id. snd_seq [3] OCTET STRING, -- Encrypted sequence number. } Sign_Body ::= SEQUENCE { int_cksum [0] OCTET STRING -- Checksum of header and data, -- calculated according to algorithm -- specified in int_alg field. } 3.2.1.1. Checksum Checksum calculation procedure (common to all algorithms): Checksums are calculated over the data field, logically prepended by the bytes of the plaintext token header (sign_header). The result binds the data to the entire plaintext header, so as to minimize the possibil- ity of malicious splicing. For example, if the int_alg specifies the md5WithRSA algorithm, then the checksum is formed by computing an MD5 [RFC-1321] hash over the plaintext data (prepended by the header), and then computing an RSA signature [PKCS1] on the 16-byte MD5 result. The signature is computed using the RSA private key retrieved from the credentials structure and the result (whose length is implied by the "modulus" parameter in the private key) is stored in the int_cksum field. If the int_alg specifies a keyed hashing algorithm (for example, DES-MAC or md5-DES-CBC), then the key to be used is the established context key. Again, the result (whose length is implied by int_alg) is stored in the int_cksum field. Adams Document Expiration: 30 April 1995 13 3.2.1.2. Sequence Number It is assumed that the underlying transport layers (of whatever pro- tocol stack is being used by the application) will provide adequate communications reliability (that is, non-malicious loss, re-ordering, etc., of data packets will be handled correctly). Therefore, enc- rypted sequence numbers are used in SPKM purely for security, as opposed to reliability, reasons (that is, to avoid malicious loss, replay, or re-ordering of SPKM tokens) -- 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 plaintext sequence number field is formed from the sender's four-byte sequence number as follows. If the four bytes of the sender's sequence number are named s0, s1, s2 and s3 (from least to most significant), the plaintext sequence number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di, di), where 'di' is the direction-indicator (Hex 00 - sender is the context initiator, Hex FF - sender is the context acceptor). The field is then CBC encrypted using the symmetric algorithm specified in seq_alg, IV', and the context key. (IV' is computed as the ECB decryption of the IV specified in seq_alg, using the context key and the symmetric algorithm specified in seq_alg. The reason for having seq_alg convey an encrypted IV is to avoid revealing a known plaintext/ciphertext pair in the token.) The resulting encrypted sequence number is placed in snd_seq. After sending a gss_sign() or gss_seal() token, the sender's sequence number is incremented by one. 3.2.1.3. Sequence Number Processing The receiver of the token will decrypt the sequence number field using the context key and compare it with the expected sequence number. The repetition of the (effectively 1-bit) direction indicator within the sequence number field provides redundancy so that the receiver may verify that the decryption succeeded. Since the encrypted sequence number is used as part of the input to the integrity checksum, attempts to splice a checksum and sequence number from different messages will be detected. The direction indicator will detect packets that have been maliciously reflected. 3.2.2. Per-message Tokens - Seal Use of the gss_seal() call yields a token which encapsulates the in- put user data (optionally encrypted) along with associated integrity check quantities. The token emitted by gss_seal() consists of an integrity header followed by a body portion that contains either the plaintext data (if conf_alg = FFFF) or encrypted data (using the key specified in 3.2.2.4 with one of the agreed C-ALGs for this context). Adams Document Expiration: 30 April 1995 14 The SPKM_SEAL token has the following format: SPKM_SEAL ::= SEQUENCE { seal_header [0] Seal_Header, seal_body [1] Seal_Body } Seal_Header ::= SEQUENCE { tok_id [0] INTEGER -- shall contain 0201 (hex) int_alg [1] AlgorithmIdentifier, -- Integrity algorithm indicator (must -- be one of the agreed integrity -- algorithms for this context). -- NULL = default id. seq_alg [2] AlgorithmIdentifier, -- Encryption alg. to compute sequence -- (must be one of the agreed symmetric -- algorithms for this context). -- NULL = default id. conf_alg [3] AlgorithmIdentifier, -- Confidentiality algorithm indicator -- (must be 'FFFF' or one of the agreed -- symmetric algorithms for this -- context). -- NULL = default id , 'FFFF' = none. snd_seq [4] OCTET STRING, -- Encrypted sequence number. } Seal_Body ::= SEQUENCE { int_cksum [0] OCTET STRING -- Checksum of header and data, -- calculated according to algorithm -- specified in int_alg field. data [1] OCTET STRING -- encrypted or plaintext data. } 3.2.2.1: Confounding As in [KRB5], an 8-byte random confounder is prepended to the data to compensate for the fact that an IV of zero is used for encryption. The result is referred to as the "confounded" data field. 3.2.2.2. Checksum Checksum calculation procedure (common to all algorithms): Checksums are calculated over the plaintext data field, logically prepended by the bytes of the plaintext token header (seal_header). As with gss_sign(), the result binds the data to the entire plaintext header, so as to minimize the possibility of malicious splicing. Adams Document Expiration: 30 April 1995 15 The examples for md5WithRSA and DES-MAC are exactly as specified in 3.2.1.1. If int_alg specifies md5-DES-CBC and conf_alg specifies anything other than DES-CBC, then the checksum is computed according to 3.2.1.1 and the result is stored in int_alg. However, if conf_alg specifies DES-CBC then the encryption and the integrity can be done as follows. An MD5 [RFC-1321] hash is computed over the plaintext data (prepended by the header). This 16-byte value is appended to the concatenation of the "confounded" data and 1-8 padding bytes (the padding is as specified in [KRB5] for DES-CBC). The result is then CBC encrypted using the context key and placed in the "data" field of Seal_Body. The final two blocks of ciphertext (i.e., the encrypted MD5 hash) are also placed in the int_cksum field of Seal_Body as the integrity checksum. If int_alg specifies sum64-DES-CBC then conf_alg must specify DES-CBC (i.e., confidentiality must be requested by the calling application or SPKM will return an error). Encryption and integrity are done in a single pass using the context key as follows. The sum (modulo 2**64 - 1) of all plaintext data blocks (prepended by the header) is computed. This 8-byte value is appended to the concatenation of the "confounded" data and 1-8 padding bytes (the padding is as specified in [KRB5] for DES-CBC). As above, the result is then CBC encrypted and placed in the "data" field of Seal_Body. The final block of ciphertext (i.e., the encrypted sum) is also placed in the int_cksum field of Seal_Body as the integrity checksum. 3.2.2.3 Sequence Number Encrypted sequence numbers are computed and processed for gss_seal() exactly as specified in 3.2.1.2 and 3.2.1.3. 3.2.2.4: Data Encryption The following procedure is followed unless (a) conf_alg is Hex FFFF, or (b) conf_alg is DES-CBC and int_alg is md5-DES-CBC, or (c) int_alg is sum64-DES-CBC: The "confounded" data is padded and encrypted according to the algorithm specified in the conf_alg field. The data is encrypted using CBC with an IV of zero. The key used is derived from the established context key by XOR-ing the context key with the hexadeci- mal constant F0F0F0...F0 (this ensures that the key used for encryp- tion and the key used for a separate, keyed integrity algorithm -- for example DES-MAC, but not sum64-DES-CBC -- are different). 3.2.3. Context deletion token The token emitted by gss_delete_sec_context() is based on the packet format for tokens emitted by gss_sign(). Adams Document Expiration: 30 April 1995 16 The SPKM_DEL token has the following format: SPKM_DEL ::= SEQUENCE { del_header [0] Del_Header, del_body [1] Del_Body } Del_Header ::= SEQUENCE { tok_id [0] INTEGER -- shall contain 0301 (hex) int_alg [1] AlgorithmIdentifier, -- Integrity algorithm indicator (must -- be one of the agreed integrity -- algorithms for this context). -- NULL = default id. seq_alg [2] AlgorithmIdentifier, -- Encryption alg. to compute sequence -- (must be one of the agreed symmetric -- algorithms for this context). -- NULL = default id. snd_seq [3] OCTET STRING, -- Encrypted sequence number. } Del_Body ::= SEQUENCE { int_cksum [0] OCTET STRING -- Checksum of header, calculated -- according to algorithm specified -- in int_alg field. } snd_seq will be calculated as for tokens emitted by gss_sign(). The int_cksum will be calculated as for tokens emitted by gss_sign(), except that the user-data component of the checksum data will be a zero-length string. 4. NAME TYPES AND OBJECT IDENTIFIERS No name types have yet been defined for SPKM. This section is for further study. 5. PARAMETER DEFINITIONS This section defines parameter values used by the SPKM GSS-API mechanism. It defines interface elements in support of portability. Adams Document Expiration: 30 April 1995 17 5.1. Minor Status Codes This section recommends common symbolic names for minor_status values to be returned by the SPKM GSS-API mechanism. Use of these definitions will enable independent implementors to enhance application portability across different implementations of the mechanism defined in this specification. (In all cases, implementations of gss_display_status() will enable callers to convert minor_status indicators to text representations.) Each implementation should make available, through include files or other means, a facility to translate these symbolic names into the concrete values which a particular GSS-API implementation uses to represent the minor_status values specified in this section. It is recognized that this list may grow over time, and that the need for additional minor_status codes specific to particular implementations may arise. 5.1.1. Non-SPKM-specific codes GSS_S_G_VALIDATE_FAILED /* "Validation error" */ GSS_S_G_BUFFER_ALLOC /* "Couldn't allocate gss_buffer_t data" */ GSS_S_G_BAD_MSG_CTX /* "Message context invalid" */ GSS_S_G_WRONG_SIZE /* "Buffer is the wrong size" */ GSS_S_G_BAD_USAGE /* "Credential usage type is unknown" */ GSS_S_G_UNAVAIL_QOP /* "Unavailable quality of protection specified" */ 5.1.2. SPKM-specific-codes 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_SYMM_ALG_TYPE /* "Unknown symmetric algorithm type in token" */ GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_TYPE /* "Unknown key establishment algorithm type in token" */ GSS_SPKM_S_SG_CTX_INCOMPLETE /* "Attempt to use incomplete security context" */ GSS_SPKM_S_SG_BAD_INT_ALG_SET /* "No integrity algorithm in common from offered set" */ GSS_SPKM_S_SG_BAD_SYMM_ALG_SET /* "No symmetric algorithm in common from offered set" */ GSS_SPKM_S_SG_BAD_KEY_ESTB_ALG_SET /* "No key establishment algorithm in common from offered set" */ GSS_SPKM_S_SG_INVALID_TOKEN_DATA /* "Data is improperly formatted: cannot encode into token" */ GSS_SPKM_S_SG_INVALID_TOKEN_FORMAT /* "Received token is improperly formatted: cannot decode" */ Adams Document Expiration: 30 April 1995 18 5.2. Quality of Protection Values Quality of Protection (QOP) values are defined for the SPKM GSS-API mechanism, and are used as input to gss_sign() and gss_seal() to select among alternate integrity-checking algorithms. Once a set of algorithms has been agreed upon by the context initiator and target, the QOP parameter simply selects from this ordered set. More specifically, the SPKM_REQ token may send a sequence of "n" Alg. IDs specifying integrity-checking algorithms supported by the initiator. The target may support only a subset m (m <= n) of these, and so will return the sequence of "m" Alg. IDs which it supports in the SPKM_REP_TI token. The first Alg. ID is therefore the default algorithm (QOP = 0), and the next m-1 are used for QOP = 1 through QOP = m-1, respectively. Any QOP value greater than or equal to m is equated to m-1 and is therefore mapped to the last Alg. ID in the agreed set. To aid in implementation and interoperability, the following stipulations are made. The set of n Alg. IDs sent by the initiator must contain one specifying an algorithm which computes a true digital signature in the first position, and must contain one specifying any other (non-signature) integrity algorithm in the second position. The set of m Alg. IDs returned by the target must also contain one specifying an algorithm which computes a true digital signature in the first position, and one specifying a (non- signature) integrity algorithm in the second position. Note that if the SPKM_REP_TI token is not used (unilateral authen- tication using SPKM-2), then m=n and the "agreed" set of Alg. IDs is simply taken to be the initiator's set. The reason for these stipulations is to allow the QOP parameter to convey the semantics of the desired integrity service without forcing it to specify the actual algorithms to be used. The result is that the application is always able to choose, in a completely general and portable way, an integrity service which provides non-repudiation semantics (by passing QOP = Hex 00), and one which does not provide non-repudiation semantics (by passing QOP = Hex 01). Note that an application which is aware of its own underlying environment and/or is aware of the underlying environment of its peer is not unduly constrained by the above stipulations because any other number or kind of algorithms may be agreed upon during context establishment, making other QOP values perfectly valid and meaningful over that context and between those peers. 6. SECURITY CONSIDERATIONS Security issues are discussed throughout this memo. Adams Document Expiration: 30 April 1995 19 7. REFERENCES [Davi89]: D. W. Davies and W. L. Price, "Security for Computer Networks", Second Edition, John Wiley and Sons, New York, 1989. [FIPS-113]: National Bureau of Standards, Federal Information Processing Standard 113, "Computer Data Authentication", May 1985. [Juen84]: R. R. Jueneman, C. H. Meyer and S. M. Matyas, ~Message Authentication with Manipulation Detection Codes?, in Proceedings of the 1983 IEEE Symposium on Security and Privacy, IEEE Computer Society Press, 1984, pp.33-54.. [KRB5]: J. Linn, "The Kerberos Version 5 GSS-API Mechanism", Internet Draft draft-ietf-cat-kerb5gss-01. [PKCS1]: RSA Encryption Standard, Version 1.5, RSA Data Security, Inc., Nov. 1993. [PKCS3]: Diffie-Hellman Key-Agreement Standard, Version 1.4, RSA Data Security, Inc., Nov. 1993. [RFC-1321]: R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321. [RFC-1422]: S. Kent, "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422. [RFC-1507]: C. Kaufman, "DASS: Distributed Authentication Security Service", RFC 1507. [RFC-1508]: J. Linn, "Generic Security Service Application Program Interface", RFC 1508. [RFC-1509]: J. Wray, "Generic Security Service Application Program Interface: C-bindings", RFC 1509. [RFC-1510]: J. Kohl and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510. [X.509]: ISO/IEC 9594-8, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT Recommendation X.509, 1993. [X9.44]: ANSI, "Public Key Cryptography Using Reversible Algorithms for the Financial Services Industry: Transport of Symmetric Algorithm Keys Using RSA", X9.44-1993. 8. AUTHOR'S ADDRESS Carlisle Adams Bell-Northern Research, Ltd. P.O.Box 3511, Station C Ottawa, Ontario, CANADA K1Y 4H7 Phone: +1 613.763.9008 E-mail: cadams@bnr.ca Adams Document Expiration: 30 April 1995 20 Appendix: IMPORTS A.1 ASN.1 encoding The following definitions are taken from X.501 and X.509. --CCITT Definitions: joint-iso-ccitt OBJECT IDENTIFIER ::= {2} ds OBJECT IDENTIFIER ::= {joint-iso-ccitt 5} algorithm OBJECT IDENTIFIER ::= {ds 8} encryptionAlgorithm OBJECT IDENTIFIER ::= {algorithm 1} hashAlgorithm OBJECT IDENTIFIER ::= {algorithm 2} signatureAlgorithm OBJECT IDENTIFIER ::= {algorithm 3} rsa OBJECT IDENTIFIER ::= {encryptionAlgorithm 1} iso OBJECT IDENTIFIER ::= {1} identified-organization OBJECT IDENTIFIER ::= {iso 3} --1989 OSI Implementors Workshop "Stable" Agreements oiw OBJECT IDENTIFIER ::= {identified-organization 14} dssig OBJECT IDENTIFIER ::= {oiw 7} oiwAlgorithm OBJECT IDENTIFIER ::= {dssig 2} oiwEncryptionAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 1} oiwHashAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 2} oiwSignatureAlgorithm OBJECT IDENTIFIER ::= {oiwAlgorithm 3} --PKCS #1 definition [PKCS1] rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } --PKCS #3 definition [PKCS3] dhKeyAgreement OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-3(3) 1 } -- the parameter to be used with this algorithm is DHParameter ::= SEQUENCE { prime INTEGER, -- p base INTEGER, -- g privateValueLength INTEGER OPTIONAL } Adams Document Expiration: 30 April 1995 21 --X.501 definitions AttributeType ::= OBJECT IDENTIFIER AttributeValue ::= ANY AttributeValueAssertion ::= SEQUENCE {AttributeType,AttributeValue} Name ::= CHOICE { --only one for now RDNSequence } RDNSequence ::= SEQUENCE OF RelativeDistinguishedName DistinguishedName ::= RDNSequence RelativeDistinguishedName ::= SET OF AttributeValueAssertion --X.509 definitions (with proposed 1992 extensions presumed) ENCRYPTED MACRO ::= BEGIN TYPE NOTATION ::= type(ToBeEnciphered) VALUE NOTATION ::= value(VALUE BIT STRING) END -- of ENCRYPTED SIGNED MACRO ::= BEGIN TYPE NOTATION ::= type (ToBeSigned) VALUE NOTATION ::= value (VALUE SEQUENCE{ ToBeSigned, AlgorithmIdentifier, --of the algorithm used to --generate the signature ENCRYPTED OCTET STRING --where the octet string is the --result of the hashing of the --value of "ToBeSigned" } ) END -- of SIGNED SIGNATURE MACRO ::= BEGIN TYPE NOTATION ::= type (OfSignature) VALUE NOTATION ::= value (VALUE SEQUENCE { AlgorithmIdentifier, --of the algorithm used to compute ENCRYPTED OCTET STRING -- the signature where the octet -- string is a function (e.g., a -- compressed or hashed version) -- of the value 'OfSignature', -- which may include the -- identifier of the algorithm -- used to compute the signature } ) END -- of SIGNATURE Adams Document Expiration: 30 April 1995 22 Certificate ::= SIGNED SEQUENCE { version [0] Version DEFAULT v1, serialNumber [1] CertificateSerialNumber, signature [2] AlgorithmIdentifier, issuer [3] Name, validity [4] Validity, subject [5] Name, subjectPublicKeyInfo [6] SubjectPublicKeyInfo, issuerUID [7] IMPLICIT UID OPTIONAL, -- used in v2 only subjectUID [8] IMPLICIT UID OPTIONAL -- used in v2 only } Version ::= INTEGER {v1(0), v2(1)} CertificateSerialNumber ::= INTEGER Validity ::= SEQUENCE { NotBefore UTCTime, NotAfter UTCTime } AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameter ANY DEFINED BY algorithm OPTIONAL } SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } UID ::= BIT STRING CertificatePair ::= SEQUENCE { forward [0] SingleCertificate OPTIONAL, reverse [1] SingleCertificate OPTIONAL } -- at least one of the pair shall be present CertificateList ::= SIGNED SEQUENCE { signature [0] AlgorithmIdentifier, issuer [1] Name, thisUpdate [2] UTCTime, nextUpdate [3] UTCTime OPTIONAL, revokedCertificates [4] SEQUENCE OF SEQUENCE { userCertificate CertificateSerialNumber, revocationDate UTCTime } OPTIONAL } Adams Document Expiration: 30 April 1995 23 AuthorizationData ::= SEQUENCE OF SEQUENCE { ad-type[0] INTEGER, ad-data[1] OCTET STRING } -- ad-data This field contains authorization data to be -- interpreted according to the value of the -- corresponding ad-type field. -- ad-type This field specifies the format for the ad-data -- subfield. All negative values are reserved for -- local use. Non-negative values are reserved for -- registered use. A.2 Encoding Rules Whenever a structure is to be signed it must always be constructed the same way. This is particularly important where a signed structure has to be reconstructed by the recipient before the signature is verified. The rules listed below are taken from X.509. - the definite form of length encoding shall be used, encoded in the minimum number of octets; - for string types, the constructed form of encoding shall not be used; - if the value of a type is its default value, it shall be absent; - the components of a Set type shall be encoded in ascending order of their tag values; - the components of a Set-of type shall be encoded in ascending order of their octet values; - if the value of a Boolean type is true, the encoding shall have its contents octet set to Hex 'FF'; - unused bits in the final octet of the encoding of a BitString value, if there are any, shall be set to zero; - the encoding of a Real type shall be such that bases 8, 10 and 16 shall not be used, and the binary scaling factor shall be zero. Adams Document Expiration: 30 April 1995 24