CAT Working Group K.R. Burdis Internet Draft Rhodes University Expires: April 2000 October 1999 The Secure Remote Password GSS-API Mechanism (SRPGM) draft-ietf-cat-srpgm-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a password-based low-infrastructure GSS-API mechanism based on the Secure Remote Password protocol and the existing Simple Public Key Mechanism. Acknowledgements This document is a synthesis of the work done by Thomas Wu in developing SRP and Carlisle Adams in developing SPKM. Much of the material in this document comes from RFC 2025, the SPKM GSS-API mechanism specification. Many sections have been copied almost word- for-word with only minor modifications and omissions where appropriate. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. 1 Overview The Secure Remote Password Authentication and Key Exchange System (SRP) is a security mechanism that provides mutual authentication and the establishment of a shared session key. Burdis [Page 1] draft-ietf-cat-srpgm-00.txt October 1999 According to RFC 2078 there are certain specifications related to the GSSAPI that are: "documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms" This is such a document. It defines token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop the SRP protocol, so that SRP can be used according to the GSS- API operational paradigm: "GSS-API operates in the following paradigm. A typical GSS-API caller is itself a communications protocol, calling on GSS-API in order to protect its communications with authentication, integrity, and/or confidentiality security services." Many of the protocols, procedures and conventions defined in SPKM are re-used in order to provide security services using the SRP protocol. The SPKM specification in RFC 2025 is described as follows: "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." The method of negotiating sets of integrity, confidentiality and one- way function algorithms to be used over the context is re-used. The use of sequence numbers for sequencing and fresh random numbers for replay detection is also re-used. Token formats have been reused as much as possible; SPKM specific data has been removed and replaced with SRP specific data. SPKM key derivation, quality of protection and support functions are also reused. 2 Motivation SRP is described in [SRP-DRAFT] as follows: "SRP is a strong network authentication mechanism, suitable for negotiating secure connections using a user-supplied password, while eliminating the security problems traditionally associated with reusable passwords." [SRP-DRAFT] describes the need for a secure password-based authentication mechanism: "The lack of a secure authentication mechanism that is also easy to use has been a long-standing problem with the vast majority of Internet protocols currently in use. The problem is two-fold: Users like to use passwords that they can remember, but most password-based authentication systems offer little protection against even passive attackers, especially if weak and easily-guessed passwords are used." Burdis [Page 2] draft-ietf-cat-srpgm-00.txt October 1999 It then goes on to describe SRP's security-relevant features: "SRP meets the strictest requirements laid down in [RFC 1704] for a non-disclosing authentication protocol. It offers complete protection against both passive and active attacks, and accomplishes this efficiently using a single Diffie-Hellman-style round of computation, making it feasible to use in both interactive and non-interactive authentication for a wide range of Internet protocols. Since it retains its security when used with low-entropy passwords, it can be seamlessly integrated into existing user applications." The two existing GSS-API mechanism specifications that have reached Internet RFC status are Kerberos and SPKM. Both of these mechanisms require additional infrastructure to be in place before they can be used. Kerberos needs a key server, and SPKM needs a certification authority and public-key infrastructure. There has been recent interest by the IETF CAT Working Group in the development of low infrastructure mechanisms: "The CAT Working Group also defines supporting mechanisms to provide security services; current activity includes specification of "low infrastructure" mechanisms to support ease of deployment and use." SRP can be classified as a low-infrastructure mechanism [SRP-DRAFT]: "Trusted key servers and certificate infrastructures are not required, and clients are not required to store and manage any long-term keys." In order for SRP to operate, the server needs to have a verifier database, and the client a memorized password. 3 Algorithms 3.1 SRP Algorithm Optimised SRP as described in [SRP] is used, since this reduces the total number of messages exchanged by grouping together pieces of information that do not depend on earlier messages. The SRP data and the tokens used to carry this data are illustrated below: Initiator Token Acceptor C,A -- SRPGM-REQ --> <-- SRPGM-REP -- s,B M1 -- SRPGM-EVIDENCE --> <-- SRPGM-EVIDENCE -- M2 where: Burdis [Page 3] draft-ietf-cat-srpgm-00.txt October 1999 C is the initiator's username A is the initiator's ephemeral public key B is the acceptor's ephemeral public key M1 is the initiator's evidence that the shared key is known M2 is the acceptor's evidence that the shared key is known If mutual authentication is not requested by the initiator then the second token from the acceptor to the initiator (M2) need not be sent. For a more formal description of the protocol's operation and how each of the above values are calculated, see [SRP-DRAFT]. The SRP-SHA1 algorithm described in [SRP-DRAFT] is the MANDATORY SRP algorithm. SRP algorithms using other hash functions MAY be used. 3.2 Integrity Algorithms Integrity algorithms are used to ensure that a message has not been altered in any way after being constructed by the legitimate sender. HMAC OBJECT IDENTIFIER :: { } This MANDATORY algorithm provides integrity protection using a message digest and a secret key. The HMAC-SHA1 algorithm MUST be used to calculate the message authentication code for the SRPGM-EVIDENCE token. 3.3 One-Way Functions Both the SRP protocol and the HMAC algorithm make use of an iterative hash function in their operation. In addition a hash function is used to derive the set of subkeys for the various confidentiality and integrity algorithms supported over the context. The SHA-1 hash function is specified as a MANDATORY one-way-function. SHA OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 18 } The actual one-way function used over the context is specified by the acceptor in the SRPGM-REP token. 3.4 Confidentiality Algorithms Confidentiality algorithms are used with the SRPGM-WRAP token to encrypt message data. Burdis [Page 4] draft-ietf-cat-srpgm-00.txt October 1999 DES-CBC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(4) secsig(3) algorithm(2) 7 } In the interests of interoperability support for this algorithm is RECOMMENDED. However users SHOULD negotiate the use of a stronger algorithm where possible. 3.5 Negotiation During context establishment, the initiator offers a set of possible integrity algorithms, a set of possible confidentiality algorithms, and a set of possible one-way function algorithms to the acceptor. The acceptor selects a single one-way function (O-ALG) out of the set of possible one-way functions offered by the initiator. This one-way function is used in the SRP protocol, the HMAC integrity algorithm, and in the derivation of context subkeys for the agreed upon integrity and confidentiality algorithms. The confidentiality algorithms selected by the acceptor become the set of confidentiality algorithms used over the established context (C-ALGs) and the integrity algorithms selected by the acceptor become the set of integrity algorithms used over the established context (I-ALGs). The acceptor selects algorithms by returning, in the same relative order, the subset of of each offered set 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 algorithm 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 the gss_wrap() calls - see Section 7 for details [SPKM]. 3.6 Subkey Derivation Having established a context key, both the initiator and acceptor must be able to derive a set of subkeys for the various confidentiality algorithms (C-ALGs) and integrity algorithms (I-ALGs) supported over the context. Let the (ordered) list of agreed C-ALGs be numbered consecutively, so that the first algorithm (the "default") is numbered "0", the next is numbered "1", and so on. Let the (ordered) list of agreed I-ALGs be numbered in the same way. Finally, let the context key be a binary string of arbitrary length "M", subject to the following constraint: L <= M (where the lower limit "L" is the bit length of the longest key needed by any agreed C-ALG or keyed I-ALG). For example, if DES and two-key-triple-DES are the negotiated confidentiality algorithms and DES-MAC is the negotiated keyed integrity algorithm, then the context key must be at least 112 bits long [SPKM]. Burdis [Page 5] draft-ietf-cat-srpgm-00.txt October 1999 Note that SRP produces context keys that are twice the length of the output of the one-way-function used. So, using SHA1 the context key would be 320 bits long and using MD5 the context key would be 256 bits long. If the length of the context key is too short then the size of the context key should be doubled using the Interleaved SHA function described in Section 3.1 of [SRP-DRAFT]. 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 the previous OWF outputs), until "k" bits have been generated; * "||" is the concatenation operation; and * "OWF" is any appropriate One-Way Function. [SPKM] 4 Context Establishment Tokens 4.1 SRPGM-REQ SRPGM-REQ ::= SEQUENCE { token_id INTEGER(256), context_id Random-INTEGER, public_key_A BIT STRING, username OCTET STRING, req_data Context-Data, validity Validity } token_id Used to identify the type of token. It must have the value 256 (decimal). context_id Used to identify to which context the token belongs. Here this is a fresh random number generated by the initiator. See section 8.3 for more information. Burdis [Page 6] draft-ietf-cat-srpgm-00.txt October 1999 public_key_A The ephemeral public key generated by the initiator. username The initiator's username. req_data Specifies the algorithms that the initiator supports and the settings that the initiator requests for the context. validity The span of time that the initiator requests that the context be valid for. Context-Data ::= SEQUENCE { channelId ChannelId OPTIONAL, seq-number INTEGER OPTIONAL, options Options, conf-algs Conf-Algs, intg-algs Intg-Algs, owf-algs OWF-Algs } channelId Used to provide channel binding as per section 1.1.6 of RFC 2078 [GSS-APIv2]. seq-number The initiator's initial sequence number, which is used for sequencing and replay detection. See sections 5.3 and 5.4 for details on sequence numbers and how they are processed. options The options requested by the initiator. conf-algs The set of confidentiality algorithms supported by the initiator, or null. intg-algs The set of integrity algorithms supported by the initiator.. owf-algs The set of one-way function algorithms supported by the initiator. Note that the sets of algorithms MUST include those specified as MANDATORY in section 3. See section 3.5 for details on how the algorithm negotiation process takes place. ChannelId ::= OCTET STRING Conf-Algs ::= CHOICE { algs [0] SEQUENCE OF AlgorithmIdentifier, null [1] NULL Burdis [Page 7] draft-ietf-cat-srpgm-00.txt October 1999 } Intg-Algs ::= SEQUENCE OF AlgorithmIdentifier OWF-Algs ::= SEQUENCE OF AlgorithmIdentifier Options ::= BIT STRING { delegation-state (0), mutual-state (1), replay-det-state (2), sequence-state (3), conf-state (4), integ-state (5) } delegation-state whether or not delegation should be allowed if available mutual-state whether or not mutual authentication is requested replay-det-state whether or not replay detection should be performed sequence-state whether or not sequencing should be performed conf-state whether or not confidentiality protection should be performed if available integ-state whether or not integrity protection should be performed 4.2 SRPGM-REP SRPGM-REP ::= SEQUENCE { token_id INTEGER(512), context_id INTEGER, rep_data Context-Data, validity Validity OPTIONAL, salt INTEGER, public_key_B BIT STRING, u Random-INTEGER, n INTEGER, g INTEGER } token_id Used to identify the type of token. It must have the value 512 (decimal). context_id Used to identify to which context the token belongs. See section Burdis [Page 8] draft-ietf-cat-srpgm-00.txt October 1999 8.3 for details on how it is calculated. rep_data Specifies the algorithms that the acceptor supports out of the lists that the initiator provided, and the options that the acceptor will provide for the context. validity The span of time that the acceptor will keep the context valid, if different from the initiator's requested context lifetime. salt The random salt associated with the username. public_key_B The ephemeral public key generated by the acceptor. u A random number. n A large prime number. All additions, multiplications, and exponentiations are performed modulo n. g A generator in the finite field GF(n). Note, that if the values for n and g in the SRPGM-REP token are different from the ones that the initiator used in its calculations for the SRPGM-REQ token, then the initiator MUST send a new SRPGM-REQ token with data computed using the new values for n and g. Context-Data ::= SEQUENCE { channelId ChannelId OPTIONAL, seq-number INTEGER OPTIONAL, options Options, conf-algs Conf-Algs, intg-algs Intg-Algs, owf-algs OWF-Algs } channelId Used to provide channel binding as per section 1.1.6 of RFC 2078 [GSS-APIv2]. seq-number The acceptor's initial sequence number, which is used for sequencing. See sections 5.2 and 5.3 for details on sequence numbers and how they are processed. options The options requested by the initiator that acceptor is prepared to honour. Burdis [Page 9] draft-ietf-cat-srpgm-00.txt October 1999 conf-algs The set of confidentiality algorithms selected by the acceptor, or null. intg-algs The set of integrity algorithms selected by the acceptor. owf-algs The set of one-way function algorithms selected by the initiator. Note that the sets of algorithms MUST include those specified as MANDATORY in section 3. See section 3.5 for details on how the algorithm negotiation process takes place. 4.3 SRPGM-EVIDENCE SRPGM-EVIDENCE ::= SEQUENCE { evidence EVIDENCE-TOKEN, evidenceIntg BIT STRING } evidence evidence that the sender knows the shared context key. evidenceIntg The integrity checksum. EVIDENCE-TOKEN ::= SEQUENCE { token_id INTEGER(768), context_id INTEGER, seqnumInitiator INTEGER, seqnumAcceptor INTEGER, context_data Context-Data, validity Validity, evidence BIT STRING } token_id Used to identify the type of token. It must have the value 768 (decimal). context_id Used to identify to which context the token belongs. See section 8.3. seqnumInitiator The initiator's initial sequence number. seqnumAcceptor The acceptor's initial sequence number. context_data The agreed upon context settings and algorithm lists. Burdis [Page 10] draft-ietf-cat-srpgm-00.txt October 1999 validity The agreed upon context lifetime. evidence Proof that the sender knows the shared context key. The contents of the EVIDENCE-TOKEN are integrity protected by computing a checksum of the encoded contents of this token using the HMAC-SHA1 algorithm and the shared context key. The checksum is stored in the evidenceIntg field of the SRPGM-EVIDENCE token. In SRPGM, the initial exchange of sequence numbers is not in integrity protected tokens. Nor is the negotiation of context settings and valid algorithms. For this reason, the sequence numbers, the agreed upon context settings, the agreed upon one-way function and the sets of agreed upon integrity and confidentiality algorithms are included as part of the EVIDENCE-TOKEN, which is integrity protected. The receiver of the token MUST check that these values in the token are consistent with what it believes the negotiated values are, and send an SRPGM-DEL token if they are not. The lack of integrity protection of the SRPGM-REQ and SRPGM-REP tokens is the reason why the HMAC-SHA1 algorithm (the mandatory integrity algorithm) must be used to compute the checksum on the SRPGM-EVIDENCE token. The set of negotiated integrity algorithms can not be trusted before the SRPGM-EVIDENCE token is generated, because this set of algorithms may have been modified by an attacker. 4.4 Error Token Error tokens are used to signal errors that occur during the context establishment process. SRPGM-ERROR ::= SEQUENCE { tok-id INTEGER (1024), context-id Random-Integer } token_id Used to identify the type of token. It must have the value 1024 (decimal). context_id Used to identify to which context the token belongs. See section 8.3. The SRPGM-ERROR token is only used during the context establishment process. If an SRPGM-REQ or SRPGM-REP token is received in error, the receiving function (either gss_init_sec_context() or gss_accept_sec_context()) will generate an SRPGM-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 Burdis [Page 11] draft-ietf-cat-srpgm-00.txt October 1999 the appropriate major status code (e.g., GSS_S_BAD_SIG) along with a minor status of GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT and all context-relevant information will be deleted. The output token will not be an SRPGM-ERROR token but will instead be an SRPGM-DEL token which will be processed by the peer's gss_process_context_token(). If gss_init_sec_context() receives an error token (whether valid or invalid), it will regenerate SRPGM-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 a SRPGM-REQ token when it is expecting an SRPGM-EVIDENCE token, it will discard the data from the previous SRPGM-REQ token and process the new one. This usually results when the initiator uses values for n and g that are different to those used by the acceptor.) Similarly, if gss_accept_sec_context() receives an error token (whether valid or invalid), it will regenerate SRPGM-REP as its output token and return a major status code of GSS_S_CONTINUE_NEEDED [SPKM]. Note that, unlike SPKM, error tokens are not integrity protected, so they could be used to perform a denial-of-service attack, preventing context establishment from taking place. 5 Per-Message and Context Deletion Tokens Three classes of tokens are defined in this section: "MIC" tokens, emitted by calls to gss_getMIC() and consumed by calls to gss_verifyMIC(); "Wrap" tokens, emitted by calls to gss_wrap() and consumed by calls to gss_unwrap(); and context deletion tokens, emitted by calls to gss_init_sec_context(), gss_accept_sec_context(), or gss_delete_sec_context() and consumed by calls to gss_process_context_token() [SPKM]. 5.1 Checksum 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. If the integrity algorithm specifies a keyed hashing algorithm (for example, DES-MAC or HMAC-SHA1), then the key to be used is the appropriate subkey derived from the context key (see Section 3.6) [SPKM]. 5.2 Data Encryption 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 Burdis [Page 12] draft-ietf-cat-srpgm-00.txt October 1999 from the established context key using the subkey derivation algorithm described in Section 3.6 (this ensures that the subkey used for encryption and the subkey used for a separate, keyed integrity algorithm are different) [SPKM]. 5.3 Sequence Number It is assumed that the underlying transport layers (of whatever protocol stack is being used by the application) will provide adequate communications reliability (that is, non-malicious loss, re-ordering, etc., of data packets will be handled correctly). Therefore, sequence numbers are used in SRPGM purely for security, as opposed to reliability, reasons (that is, to avoid malicious loss, replay, or re-ordering of SRPGM 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 SRPGM-REQ and the acceptor's initial sequence number may be explicitly given in the Context-Data field of SRPGM-REP; if either of these is not given then the default value of 00 is to be used. Sequence number field: The sequence number field is formed from the sender's four-byte sequence number and a Boolean direction-indicator (FALSE - sender is the context initiator, TRUE - sender is the context acceptor). After constructing a gss_sign/getMIC() or gss_seal/wrap() token, the sender's sequence number is incremented by 1 [SPKM]. 5.4 Sequence Number Processing The receiver of the token will verify the sequence number field by comparing the sequence number with the expected sequence number and the direction indicator with the expected direction indicator. If the sequence number in the token is higher than the expected number, then the expected sequence number is adjusted and GSS_S_GAP_TOKEN is returned. If the token sequence number is lower than the expected number, then the expected sequence number is not adjusted and GSS_S_DUPLICATE_TOKEN, GSS_S_UNSEQ_TOKEN, or GSS_S_OLD_TOKEN is returned, whichever is appropriate. If the direction indicator is wrong, then the expected sequence number is not adjusted and GSS_S_UNSEQ_TOKEN is returned. Since the sequence number is used as part of the input to the integrity checksum, sequence numbers need not be encrypted, and attempts to splice a checksum and sequence number from different messages will be detected. The direction indicator will detect tokens which have been maliciously reflected [SPKM]. 5.5 SRPGM-MIC Use of the gss_sign() / gss_getMIC() call yields a token, separate from the user data being protected, which can be used to verify the integrity of that data as received. The token and the data may be sent Burdis [Page 13] draft-ietf-cat-srpgm-00.txt October 1999 separately by the sending application and it is the receiving application's responsibility to associate the received data with the received token [SPKM]. The SRPGM-MIC token has the following format: SRPGM-MIC ::= SEQUENCE { mic-header MIC-Header, int-cksum BIT STRING } int-cksum Checksum over header and data calculated according to the algorithm specified in the int-alg field of mic-header. See section 5.1. Mic-Header ::= SEQUENCE { tok-id INTEGER (257), context-id Random-INTEGER, int-alg [0] AlgorithmIdentifier OPTIONAL, snd-seq [1] SeqNum OPTIONAL } tok-id Used to identify the type of token. It must have the value 257 (decimal). context-id Used to identify to which context the token belongs. See section 8.3. int-alg The integrity algorithm used to produce the checksum. snd-seq The sender's sequence number. SeqNum ::= SEQUENCE { num INTEGER, dir-ind BOOLEAN } num The actual sequence number dir-ind The boolean direction indicator. FALSE - sender is the context initiator, TRUE - sender is the context acceptor. See sections 5.3 and 5.4 for a description of sequence numbers and how they are processed. 5.6 SRPGM-WRAP SRPGM-WRAP ::= SEQUENCE { Burdis [Page 14] draft-ietf-cat-srpgm-00.txt October 1999 wrap-header Wrap-Header, wrap-body Wrap-Body } Wrap-Header ::= SEQUENCE { tok-id INTEGER(513), context-id Random-Integer, int-alg [0] AlgorithmIdentifier OPTIONAL, conf-alg [1] Conf-Alg OPTIONAL, snd-seq [2] SeqNum OPTIONAL } tok-id Used to identify the type of token. It must have the value 513 (decimal). context-id Used to identify to which context the token belongs. See section 8.3. int-alg The integrity algorithm used to construct the integrity checksum. conf-alg The confidentiality algorithm (if any) used encrypt the message data. snd-seq The sender's sequence number, used for sequencing and replay detection. See sections 5.3 and 5.4. Wrap-Body ::= SEQUENCE { int-cksum BIT STRING, data BIT STRING } int-chksum The checksum of the header and data, used for integrity protection. See section 5.1. data The encrypted or plaintext data. See section 5.2. Conf-Alg ::= CHOICE { algId [0] AlgorithmIdentifier, null [1] NULL } Due to restrictions on the use of encryption in some countries, the confidentiality algorithm may be null indicating that no encryption of the data is to take place [SPKM]. See section 5.1 for details on how the checksum is created, and section 5.2 for a description of how data encryption takes place. Burdis [Page 15] draft-ietf-cat-srpgm-00.txt October 1999 5.7 SRPGM-DEL This token is issued by the gss_delete_sec_context() GSS-API method call and is used to delete the context between the initiator and acceptor [GSS-APIv2]. SRPGM-DEL ::= SEQUENCE { del-header Del-Header, int-cksum BIT STRING } int-cksum The integrity checksum of the header. Del-Header ::= SEQUENCE { tok-id INTEGER (769), context-id Random-Integer, int-alg[0] AlgorithmIdentifier OPTIONAL, snd-seq [1] SeqNum OPTIONAL } tok-id Used to identify the type of token. It must have the value 769 (decimal). context-id Used to identify to which context the token belongs. See section 8.3. int-alg The integrity algorithm used to construct the integrity checksum. snd-seq The sender's sequence number, used for sequencing and replay detection. See sections 5.3 and 5.4. 6 Minor Status Codes This section recommends common symbolic names for minor_status values to be returned by the SRPGM 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 [SPKM]. 6.1 Non-SRPGM-specific codes (Minor Status Code MSB, bit 31, SET) Burdis [Page 16] draft-ietf-cat-srpgm-00.txt October 1999 6.1.1 GSS-Related codes (Minor Status Code bit 30 SET) GSS_S_G_VALIDATE_FAILED /* "Validation error" */ GSS_S_G_BUFFER_ALLOC /* "Couldn't allocate gss_buffer_t data" */ GSS_S_G_BAD_MSG_CTX /* "Message context invalid" */ GSS_S_G_WRONG_SIZE /* "Buffer is the wrong size" */ GSS_S_G_BAD_USAGE /* "Credential usage type is unknown" */ GSS_S_G_UNAVAIL_QOP /* "Unavailable quality of protection specified" */ 6.1.2 Implementation-Related codes (Minor Status Code bit 30 OFF) GSS_S_G_MEMORY_ALLOC /* "Couldn't perform requested memory allocation" */ 6.2 SRPGM-specific-codes (Minor Status Code MSB, bit 31, OFF) GSS_SRPGM_S_SG_CONTEXT_ESTABLISHED /* "Context is already fully established" */ GSS_SRPGM_S_SG_BAD_INT_ALG_TYPE /* "Unknown integrity algorithm type in token" */ GSS_SRPGM_S_SG_BAD_CONF_ALG_TYPE /* "Unknown confidentiality algorithm type in token" */ GSS_SRPGM_S_SG_CTX_INCOMPLETE /* "Attempt to use incomplete security context" */ GSS_SRPGM_S_SG_BAD_INT_ALG_SET /* "No integrity algorithm in common from offered set" */ GSS_SRPGM_S_SG_BAD_CONF_ALG_SET /* "No confidentiality algorithm in common from offered set" */ GSS_SRPGM_S_SG_BAD_OWF_ALG_SET /* "No one-way function algorithm in common from offered set" */ GSS_SRPGM_S_SG_INVALID_TOKEN_DATA /* "Data is improperly formatted: cannot encode into token" */ GSS_SRPGM_S_SG_INVALID_TOKEN_FORMAT /* "Received token is improperly formatted: cannot decode" */ Burdis [Page 17] draft-ietf-cat-srpgm-00.txt October 1999 GSS_SRPGM_S_SG_CONTEXT_DELETED /* "Context deleted at peer's request" */ GSS_SRPGM_S_SG_BAD_DELETE_TOKEN_RECD /* "Invalid delete token received -- context not deleted "*/ GSS_SRPGM_S_SG_CONTEXT_ESTB_ABORT /* "Unrecoverable context establishment error. Context deleted"*/ GSS_SRPGM_S_SG_INVALID_KEY /* "Invalid ephemeral public key"*/ GSS_SRPGM_S_SG_INVALID_EVIDENCE /* "Invalid evidence provided to prove knowledge of context key and settings." */ 7 Quality of Protection Values The Quality of Protection (QOP) parameter is used in the SRPGM GSS-API mechanism as input to gss_sign() and gss_seal() (gss_getMIC() and gss_wrap()) to select among alternate confidentiality and integrity-checking algorithms. Once these sets of algorithms have been agreed upon by the context initiator and target, the QOP parameter simply selects from these ordered sets. More specifically, the SRPGM-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 acceptor 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 SRPGM-REP token (in the same relative orders as those given by the initiator). Thus, the initiator and acceptor 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 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 Burdis [Page 18] draft-ietf-cat-srpgm-00.txt October 1999 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) = SRPGM_SYM_ALG_STRENGTH_STRONG 00010 (2) = SRPGM_SYM_ALG_STRENGTH_MEDIUM 00011 (3) = SRPGM_SYM_ALG_STRENGTH_WEAK 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 Burdis [Page 19] draft-ietf-cat-srpgm-00.txt October 1999 confidentiality and integrity (since "0" is reserved for "default"). This document specifies three for confidentiality and none for integrity, leaving a lot of room for future specification. Suggestions of qualifiers such as "fast", "medium-speed", and "slow" have been made, but such terms are difficult to quantify (and in any case are platform- and processor-dependent), and so have been left out of this initial specification. The intention is that the TS terms be quantitative, environment-independent qualifiers of algorithms, as much as this is possible. Use of the QOP structure as defined above is ultimately meant to be as follows. * TS values are specified at the GSS-API level and are therefore portable across mechanisms. Applications which know nothing about algorithms are still able to choose "quality" of protection for their message tokens. * MA values are specified at the mechanism level and are therefore portable across implementations of a mechanism. For example, all implementations of the Kerberos V5 GSS mechanism must support GSS_KRB5_INTEG_C_QOP_MD5 (value: 1) GSS_KRB5_INTEG_C_QOP_DES_MD5 (value: 2) GSS_KRB5_INTEG_C_QOP_DES_MAC (value: 3). (Note that these Kerberos-specified integrity QOP values do not conflict with the QOP structure defined above.) * IA values are specified at the implementation level (in user documentation, for example) and are therefore typically non-portable. An application which is aware of its own mechanism implementation and the mechanism implementation of its peer, however, is free to use these values since they will be perfectly valid and meaningful over that context and between those peers. The receiver of a token must pass back to its calling application a QOP parameter with all relevant fields set. For example, if triple-DES has been specified by a mechanism as algorithm 8, then a receiver of a triple-DES-protected token must pass to its application (QOP Confidentiality TS=1, IA=0, MA=8). In this way, the application is free to read whatever part of the QOP it understands (TS or IA/MA). In accordance with the MANDATORY and RECOMMENDED algorithms given in Section 3, the following QOP values are specified for SRPGM. For the Confidentiality MA field: 0001 (1) = DES-CBC For the Integrity MA field: 0001 (1) = HMAC-SHA1 Burdis [Page 20] draft-ietf-cat-srpgm-00.txt October 1999 [SPKM] 8 Support Functions This section describes a mandatory support function for SRPGM-conformant implementations which may, in fact, be of value in all GSS-API mechanisms. It makes use of the token-id and context-id information which is included in SRPGM context-establishment, error, context-deletion, and per-message tokens. The function is defined in the following section [SPKM]. 8.1 SPKM_Parse_token call Inputs: * input_token OCTET STRING Outputs: * major_status INTEGER, * minor_status INTEGER, * mech_type OBJECT IDENTIFIER, * token_type INTEGER, * context_handle CONTEXT HANDLE, Return major_status codes: * GSS_S_COMPLETE indicates that the input_token could be parsed for all relevant fields. The resulting values are stored in mech_type, token_type and context_handle, respectively (with NULLs in any parameters which are not relevant). * GSS_S_DEFECTIVE_TOKEN indicates that either the token-id or the context-id (if it was expected) information could not be parsed. A non-NULL return value in token_type indicates that the latter situation occurred. * GSS_S_NO_TYPE indicates that the token-id information could be parsed, but it did not correspond to any valid token_type. (Note that this major status code has not been defined for GSS in RFC-1508. Until such a definition is made (if ever), SRPGM implementations should instead return GSS_S_DEFECTIVE_TOKEN with both token_type and context_handle set to NULL. This essentially implies that unrecognized token-id information is considered to be equivalent to token-id information which could not be parsed.) * GSS_S_NO_CONTEXT indicates that the context-id could be parsed, but it did not correspond to any valid context_handle. * GSS_S_FAILURE indicates that the mechanism type could not be parsed (for example, the token may be corrupted). SRPGM_Parse_token() is used to return to an application the mechanism type, token type, and context handle which correspond to a given input Burdis [Page 21] draft-ietf-cat-srpgm-00.txt October 1999 token. Since GSS-API tokens are meant to be opaque to the calling application, this function allows the application to determine information about the token without having to violate the opaqueness intention of GSS. Of primary importance is the token type, which the application can then use to decide which GSS function to call in order to have the token processed. If all tokens are framed as suggested in RFC-1508, Appendix B (specified both in the Kerberos V5 GSS mechanism [KRB5] and in this document), then any mechanism implementation should be able to return at least the mech_type parameter (the other parameters being NULL) for any uncorrupted input token. If the mechanism implementation whose SRPGM_Parse_token() function is being called does recognize the token, it can return token_type so that the application can subsequently call the correct GSS function. Finally, if the mechanism provides a context-id field in its tokens (as SRPGM does), then an implementation can map the context-id to a context_handle and return this to the application. This is necessary for the situation where an application has multiple contexts open simultaneously, all using the same mechanism. When an incoming token arrives, the application can use this function to determine not only which GSS function to call, but also which context_handle to use for the call. Note that this function does no cryptographic processing to determine the validity of tokens; it simply attempts to parse the mech_type, token_type, and context-id fields of any token it is given. Thus, it is conceivable, for example, that an arbitrary buffer of data might start with random values which look like a valid mech_type and that SRPGM_Parse_token() would return incorrect information if given this buffer. While conceivable, however, such a situation is unlikely. The SRPGM_Parse_token() function is mandatory for SRPGM-conformant implementations, but it is optional for applications. That is, if an application has only one context open and can guess which GSS function to call (or is willing to put up with some error codes), then it need never call SRPGM_Parse_token(). Furthermore, if this function ever migrates up to the GSS-API level, then SRPGM_Parse_token() will be deprecated at that time in favour of GSS_Parse_token(), or whatever the new name and function specification might be. Note finally that no minor status return codes have been defined for this function at this time [SPKM]. 8.2 The token_type Output Parameter The following token types are defined: GSS_INIT_TOKEN = 1 GSS_ACCEPT_TOKEN = 2 GSS_ERROR_TOKEN = 3 GSS_SIGN_TOKEN = GSS_GETMIC_TOKEN = 4 GSS_SEAL_TOKEN = GSS_WRAP_TOKEN = 5 Burdis [Page 22] draft-ietf-cat-srpgm-00.txt October 1999 GSS_DELETE_TOKEN = 6 All SRPGM mechanisms shall be able to perform the mapping from the token-id information which is included in every token (through the tag values in SRPGMInnerContextToken or through the tok-id field) to one of the above token types. Applications should be able to decide, on the basis of token_type, which GSS function to call (for example, if the token is a GSS_INIT_TOKEN then the application will call gss_accept_sec_context(), and if the token is a GSS_WRAP_TOKEN then the application will call gss_unwrap()) [SPKM]. 8.3 The context_handle Output Parameter The SRPGM 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 SRPGM 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 SRPGM-REQ token. The acceptor then 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 SRPGM-REP 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) [SPKM]. 9 Security Considerations Security issues are discussed throughout this document. This mechanism relies on the security of SRP, which bases its security Burdis [Page 23] draft-ietf-cat-srpgm-00.txt October 1999 on the difficulty of solving the Diffie-Hellman problem in the multiplicative field modulo a large safe prime. See section 4 "Security Considerations" of [SRP-DRAFT] and section 4 "Security analysis" of [SRP]. This mechanism also relies on the security of the HMAC algorithm and the underlying hash function. Section 6 "Security" of [HMAC] discusses these security issues in detail. 10. References [ASN.1] Kaliski, Burton, "A Layman's Guide to a Subset of ASN.1, BER, and DER", RSA Laboratories Technical Note, RSA Data Security Inc. Public-Key Cryptography Standards (PKCS), November 1993 [CAT-WG] WWW, "Common Authentication Technology (cat) Charter", URL: http://www.ietf.org/html.charters/cat-charter.html [GSS-APIv1] Linn, John, "Generic Security Service Application Program Interface", Internet RFC 1508 [GSS-APIv2]: Linn, John, "Generic Security Service Application Program Interface, Version 2", Internet RFC 2078 [HMAC] Krawczyk, Hugo et.al. "HMAC: Keyed-Hashing for Message Authentication", Internet RFC 2104 [KEYWORDS] Bradner, Scott, "Key words for use in RFCs to Indicate Requirement Levels", Internet RFC 2119 [KRB5] Linn, John, "The Kerberos Version 5 GSS-API Mechanism", Internet RFC 1964 [SPKM]: Adams, Carlisle, "The Simple Public-Key GSSAPI Mechanism (SPKM)", Internet RFC 2025 [SRP] Wu, Thomas, "The Secure Remote Password Protocol", 1998 Internet Society Symposium on Network and Distributed Security [SRP-DRAFT] Wu, Thomas, "The SRP Authentication and Key Exchange System", Internet Draft, draft-wu-srp-auth-03.txt [SRP-ADV] WWW, "Advantages and Benefits of SRP", URL: http://srp.stanford.edu/srp/advantages.html 11. Author's Address Keith Burdis Computer Science Department Rhodes University 6139 Grahamstown Email: cskb@cs.ru.ac.za Burdis [Page 24] draft-ietf-cat-srpgm-00.txt October 1999 Appendix A: ASN.1 Definitions SRPGM-REQ ::= SEQUENCE { token_id INTEGER(256), context_id Random-INTEGER, public_key_A BIT STRING, username OCTET STRING, req_data Context-Data, validity Validity } Context-Data ::= SEQUENCE { channelId ChannelId OPTIONAL, seq-number INTEGER OPTIONAL, options Options, conf-algs Conf-Algs, intg-algs Intg-Algs, owf-algs OWF-Algs } ChannelId ::= OCTET STRING Conf-Algs ::= CHOICE { algs [0] SEQUENCE OF AlgorithmIdentifier, null [1] NULL } Intg-Algs ::= SEQUENCE OF AlgorithmIdentifier OWF-Algs ::= SEQUENCE OF AlgorithmIdentifier Options ::= BIT STRING { delegation-state (0), mutual-state (1), replay-det-state (2), sequence-state (3), conf-state (4), integ-state (5) } SRPGM-REP ::= SEQUENCE { token_id INTEGER(512), context_id INTEGER, rep_data Context-Data, validity Validity OPTIONAL, salt INTEGER, public_key_B BIT STRING, u Random-INTEGER, n INTEGER, g INTEGER } SRPGM-EVIDENCE ::= SEQUENCE { evidence EVIDENCE-TOKEN, Burdis [Page 25] draft-ietf-cat-srpgm-00.txt October 1999 evidenceIntg BIT STRING } EVIDENCE-TOKEN ::= SEQUENCE { token_id INTEGER(768), context_id INTEGER, seqnumInitiator INTEGER, seqnumAcceptor INTEGER, context_data Context-Data, validity Validity, evidence BIT STRING } SRPGM-ERROR ::= SEQUENCE { tok-id INTEGER (1024), context-id Random-Integer } SRPGM-MIC ::= SEQUENCE { mic-header MIC-Header, int-cksum BIT STRING } Mic-Header ::= SEQUENCE { tok-id INTEGER (257), context-id Random-INTEGER, int-alg [0] AlgorithmIdentifier OPTIONAL, snd-seq [1] SeqNum OPTIONAL } SeqNum ::= SEQUENCE { num INTEGER, dir-ind BOOLEAN } SRPGM-WRAP ::= SEQUENCE { wrap-header Wrap-Header, wrap-body Wrap-Body } Wrap-Header ::= SEQUENCE { tok-id INTEGER(513), context-id Random-Integer, int-alg [0] AlgorithmIdentifier OPTIONAL, conf-alg [1] Conf-Alg OPTIONAL, snd-seq [2] SeqNum OPTIONAL } Wrap-Body ::= SEQUENCE { int-cksum BIT STRING, data BIT STRING } Conf-Alg ::= CHOICE { Burdis [Page 26] draft-ietf-cat-srpgm-00.txt October 1999 algId [0] AlgorithmIdentifier, null [1] NULL } SRPGM-DEL ::= SEQUENCE { del-header Del-Header, int-cksum BIT STRING } Del-Header ::= SEQUENCE { tok-id INTEGER (769), context-id Random-Integer, int-alg[0] AlgorithmIdentifier OPTIONAL, snd-seq [1] SeqNum OPTIONAL } RandomInteger ::= BIT STRING Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime } AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, paramter ANY DEFINED BY algorithm OPTIONAL } Burdis [Page 27]