CAT Working Group K.R. Burdis Internet Draft Rhodes University Expires: July 2000 January 2000 draft-ietf-cat-srpgm-02.txt The Secure Remote Password GSS-API Mechanism (SRPGM) 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 (SRP) and the existing Simple Public Key Mechanism (SPKM). This mechanism is suitable for establishing a secure context between two entities that have established a shared secret as per the SRP protocol. Acknowledgements This document is a synthesis of the work done by Thomas Wu in developing SRP and Carlisle Adams in developing SPKM. I am grateful for the excellent work done by these two authors. The idea of using SPKM as a basis for an SRP-based GSS-API mechanism comes from Mike Eisler's LIPKEY. Some parts of [SPKM] have been reused in this document. 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]. Burdis [Page 1] draft-ietf-cat-srpgm-02.txt January 2000 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Relationship to SPKM . . . . . . . . . . . . . . . . . . . . . 4 4. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. SRP Algorithm . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Integrity Algorithms . . . . . . . . . . . . . . . . . . . . 5 4.3. One-Way Functions . . . . . . . . . . . . . . . . . . . . . 6 4.4. Confidentiality Algorithms . . . . . . . . . . . . . . . . . 6 4.5. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . 6 4.6. Subkey Derivation . . . . . . . . . . . . . . . . . . . . . 7 5. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Context Establishment Tokens . . . . . . . . . . . . . . . . 8 5.1.1. SrpgmReq . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1.2. SrpgmParameters . . . . . . . . . . . . . . . . . . . . 11 5.1.3. SrpgmRep . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.4. SrpgmEvidence . . . . . . . . . . . . . . . . . . . . . 14 5.1.5. SrpgmError . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Per-Message and Context Deletion Tokens . . . . . . . . . 15 6. Miscellaneous Details . . . . . . . . . . . . . . . . . . . 15 6.1. Minor Status Codes . . . . . . . . . . . . . . . . . . . . 15 6.2. Quality of Protection . . . . . . . . . . . . . . . . . . 16 6.3. Support Functions . . . . . . . . . . . . . . . . . . . . 17 6.4. Context-ids . . . . . . . . . . . . . . . . . . . . . . . 17 6.5. Sequence numbers . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 A. Modulus and Generator values . . . . . . . . . . . . . . . . 19 B. ASN.1 Definitions . . . . . . . . . . . . . . . . . . . . . . 20 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. According to RFC 2078 there are certain specifications related to the GSS-API 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." Burdis [Page 2] draft-ietf-cat-srpgm-02.txt January 2000 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." 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 [CAT-WG] 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. Burdis [Page 3] draft-ietf-cat-srpgm-02.txt January 2000 3 Relationship to SPKM Many of the protocols, procedures and conventions defined in SPKM are re-used: * The method of negotiating algorithms to be used over the context * The use of sequence numbers to avoid malicious loss, replay or reordering of tokens after context establishment * The process of deriving subkeys from the context key * Quality of Protection values, and support functions * Token formats for per-message and context deletion tokens. The appropriate sections in the SPKM specification are referred to and any SRPGM-specific changes are noted. SRPGM context establishment tokens are derived from corresponding SPKM tokens. The table below shows these relationships: +--------------+-----------------+ | SPKM | SRPGM | +--------------+-----------------+ | SPKM-REQ | SRPGM-REQ | | SPKM-REP-TI | SRPGM-REP | | SPKM-REP-IT | SRPGM-EVIDENCE | | SPKM-ERROR | SRPGM-ERROR | +--------------+-----------------+ This should be kept in mind when reading the SPKM sections that are referred to in this document. 4 Algorithms 4.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 -- SrpgmReq --> <-- SrpgmRep -- s,B M1 -- SrpgmEvidence --> -- SrpgmEvidence --> M2 where: Burdis [Page 4] draft-ietf-cat-srpgm-02.txt January 2000 * C is the initiator's username * A is the initiator's ephemeral public key * s is the initiator's password salt * 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. It is RECOMMENDED that the acceptor use values for n and g chosen from those listed in Appendix A so that the initiator can avoid expensive constraint checks, since these predefined values already meet the constraints described in [SRP-DRAFT]: "For maximum security, N should be a safe prime (i.e. a number of the form N = 2q + 1, where q is also prime). Also, g should be a generator modulo N (see [SRP] for details), which means that for any X where 0 < X < N, there exists a value x for which g^x % N == X." 4.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. The following MANDATORY algorithm provides integrity protection using a message digest and a secret key: HMAC-MD5 OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) internet(1) security(5) mechanisms(5) ipsec(8) isakmpOakley(2) } Motivation for the use of the HMAC algorithm comes from [RFC 2316]: "One particular technique used by IPsec, HMAC [RFC 2104], is more generally useful. If cryptographic authentication but not secrecy is needed, and IPsec is not applicable, HMAC should be used." [LIPKEY] motivates for the use of HMAC-MD5 since it is faster than both HMAC-SHA and MAC algorithms based on secret key encryption algorithms. In addition, weaknesses found in MD5 do not impact Burdis [Page 5] draft-ietf-cat-srpgm-02.txt January 2000 HMAC-MD5 [DOBBERTIN]. See sections 2.3.1 and 5.3 of [LIPKEY]. The HMAC-MD5 algorithm MUST be used to calculate the message authentication codes for the SrprgmRep and SrpgmEvidence tokens. 4.3 One-Way Functions An iterative one-way hash function is used in the SRP protocol and 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. id-sha1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 } The actual one-way function used over the context is specified by the acceptor in the SrpgmRep token. 4.4 Confidentiality Algorithms Confidentiality algorithms are used with the SrpgmWrap token to encrypt message data. In the interests of interoperability support for this algorithm is RECOMMENDED: blowfishCBC OBJECT IDENTIFIER ::= { -- object identifier registration in progress } Blowfish was chosen because [BLOWFISH]: * It is free from intellectual property constraints * It is fast * It supports variable key lengths from 32 bits to 448 bits * It has withstood cryptanalysis since 1993 * A number of implementations in various programming languages are freely available When the chosen AES algorithm is announced it will also be recommended [AES]. 4.5 Negotiation Algorithm negotiation is the same as for SPKM (see section 2.5 of [SPKM]), except that the parties also negotiate the use of a one-way-function, and even with unilateral authentication both parties are involved in the negotiation. The slightly modified negotiation procedure is described below. 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. Burdis [Page 6] draft-ietf-cat-srpgm-02.txt January 2000 The confidentiality algorithms selected by the acceptor become the set of confidentiality algorithms used over the established context and the integrity algorithms selected by the acceptor become the set of integrity algorithms used over the established context. The acceptor selects algorithms by returning, in the same relative order, the subset of each offered set that it supports. The acceptor also selects a single one-way function out of the set of possible one-way functions offered by the initiator. Note that any confidentiality algorithm and integrity algorithm 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 selected one-way function is used in the SRP protocol and in the derivation of context subkeys for the agreed upon integrity and confidentiality algorithms. 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 6.2 for details. 4.6 Subkey Derivation Subkey derivation is the same as for SPKM (see section 2.4 of [SPKM]). 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]. 5 Tokens As with SPKM all tokens emitted by this mechanism will be contained in an InitialContextToken framing (see section 3.1 of [SPKM]). Per RFC-1508, Appendix B, the initial context establishment token will be enclosed within framing as follows: InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { thisMech OBJECT IDENTIFIER, innerContextToken ANY DEFINED BY thisMech } thisMech Object identifier for the mechanism type. In this case the object identifier representing "SRPGM". innerContextToken Mechanism-specific data. In this case it contains an SrpgmInnerContextToken Burdis [Page 7] draft-ietf-cat-srpgm-02.txt January 2000 When thisMech is SRPGM, innerContextToken is defined as follows: SrpgmInnerContextToken ::= CHOICE { request [0] SrpgmReq, reply [1] SrpgmRep, parameters [2] SrpgmParameters, evidence [3] SrpgmEvidence, error[4] SrpgmError, mic[5] SrpgmMic, wrap[6] SrpgmWrap, del[7] SrpgmDel } All tokens are encoded using ASN.1 DER. (The merits of using the XER encoding described in [XER] need to be discussed). The full ASN.1 specification is given in Appendix B. 5.1 Context Establishment Tokens Three classes of tokens are defined in this section: "Initiator" tokens, emitted by calls to gss_init_sec_context() and consumed by calls to gss_accept_sec_context(); "Target" tokens, emitted by calls to gss_accept_sec_context() and consumed by calls to gss_init_sec_context(); and "Error" tokens, potentially emitted by calls to gss_init_sec_context() or gss_accept_sec_context(), and potentially consumed by calls to gss_init_sec_context() or gss_accept_sec_context() [SPKM]. As mentioned above all tokens must be framed in an InitialContextToken. The innerContextToken field of context establishment tokens will contain one of the following tokens: SrpgmReq; SrpgmRep; SrpgmParameters; SrpgmEvidence; and SrpgmError. 5.1.1 SrpgmReq SrpgmReq ::= SEQUENCE { contents ReqContents, checksum BIT STRING } contents Contents of the token. checksum Integrity checksum. The integrity checksum is computed by using the value of the contents field in the SrpgmReq token as input to the SHA-1 one-way function. ReqContents ::= SEQUENCE { tokenId INTEGER(256), contextId RandomInteger, A BIT STRING, Burdis [Page 8] draft-ietf-cat-srpgm-02.txt January 2000 username OCTET STRING, n INTEGER, g INTEGER, reqData ContextData, validity Validity } tokenId Used to identify the type of token. It must have the value 256 (decimal). contextId Used to identify to which context the token belongs. Here this is a fresh random number generated by the initiator. See section 6.4 for more information. A The ephemeral public key generated by the initiator. username The initiator's username. n A large prime number. All additions, multiplications, and exponentiations are performed modulo n. g A generator in the finite field GF(n). reqData 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. ContextData ::= SEQUENCE { channelId ChannelId OPTIONAL, seqNumber INTEGER OPTIONAL, options Options, intgAlgs AlgList, owfAlgs AlgList, confAlgs AlgList OPTIONAL } channelId Used to provide channel binding as per section 1.1.6 of RFC 2078 [GSS-APIv2]. seqNumber The initiator's four-byte initial sequence number. See section 6.5. Burdis [Page 9] draft-ietf-cat-srpgm-02.txt January 2000 options The options requested by the initiator. intgAlgs The set of integrity algorithms supported by the initiator. owfAlgs The set of one-way function algorithms supported by the initiator. confAlgs The set of confidentiality algorithms supported by the initiator. This is optional because confidentiality may not be available over the context. Note that the sets of algorithms MUST include those specified as MANDATORY in section 4. (See section 4.5 for details on how the algorithm negotiation process takes place). If this is not so then the acceptor MUST generate an SrpgmError token. In addition, the sets of algorithms SHOULD, if possible, include those specified as RECOMMENDED in section 4. ChannelId ::= OCTET STRING AlgList ::= SEQUENCE OF AlgorithmIdentifier Options ::= BIT STRING { delegationState (0), mutualState (1), replayDetState (2), sequenceState (3), confState (4), integState (5) } delegationState whether or not delegation should be allowed if available mutualState whether or not mutual authentication is requested replayDetState whether or not replay detection should be performed sequenceState whether or not sequencing should be performed confState whether or not confidentiality protection should be provided, if available integState whether or not integrity protection should be provided We optimise for the case where the initiator and acceptor use Burdis [Page 10] draft-ietf-cat-srpgm-02.txt January 2000 prearranged values for n and g. If the values are prearranged then they MUST meet the constraints described in [SRP-DRAFT] (see section 4.1 above). If the initiator does not know what values for n and g the acceptor uses then it MAY set the values of the n and g fields in the ReqContents structure of the SrpgmReq token to zero. The values of the other fields MAY then be set to dummy values. The acceptor MUST first check that the the values for n and g in the received SrpgmReq token are correct, and if not MUST send an SrpgmParameters token to the initiator that contains the correct values. (It is RECOMMENDED that the initiator cache the values for n and g used by the acceptor to avoid this extra message exchange in future). If n and g are correct, the acceptor MUST also check that the value of A in the received SrpgmReq token is not zero, and generate an SrpgmError token if it is. 5.1.2 SrpgmParameters SrpgmParameters ::= SEQUENCE { tokenId INTEGER(257), contextId RandomInteger, n INTEGER, g INTEGER, } tokenId Used to identify the type of token. It must have the value 257 (decimal). contextId Used to identify to which context the token belongs. Here this is the value that was contained in the contextId field of the ReqContents structure in the received SrpgmReq token. n The large prime number used by the acceptor. All additions, multiplications, and exponentiations are performed modulo n. g A generator in the finite field GF(n). If the initiator receives an SrpgmParameters token it MUST ensure that the values for n and g meet the constraints described in [SRP-DRAFT] (see section 4.1 above), and abort the context if they do not. If the values are valid then the initiator MUST generate a new SrpgmReq token with data computed using the given values for n and g. 5.1.3 SrpgmRep SrpgmRep ::= SEQUENCE { contents RepContents, mac BIT STRING Burdis [Page 11] draft-ietf-cat-srpgm-02.txt January 2000 } contents Contents of the token. mac Keyed checksum of contents. The contents of the RepContents structure are integrity protected by computing a checksum of the encoded contents of this structure using the HMAC-MD5 algorithm and the shared context key. This keyed checksum is stored in the mac field of the SrpgmRep token. Note that the initiator needs to obtain data from the RepContents structure of the received SrpgmRep token before it has sufficient information to derive the session key and verify the integrity checksum. The lack of integrity protection of the SrpgmReq token is the reason why the HMAC-MD5 algorithm (the mandatory integrity algorithm) MUST be used to compute the integrity checksum for the SrpgmRep token. The set of integrity algorithms specified in the SrpgmReq token can not be trusted, because this set of algorithms may have been modified by an attacker. RepContents ::= SEQUENCE { tokenId INTEGER(512), contextId RandomInteger, reqChecksum BIT STRING, repData ContextData, validity Validity OPTIONAL, salt BIT STRING, B BIT STRING, n INTEGER, g INTEGER } tokenId Used to identify the type of token. It must have the value 512 (decimal). contextId Used to identify to which context the token belongs. See section 6.4 for details on how it is calculated. reqChecksum The checksum from the SrpgmReq token. repData 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 Burdis [Page 12] draft-ietf-cat-srpgm-02.txt January 2000 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. B The ephemeral public key generated by the acceptor. n A large prime number. All additions, multiplications, and exponentiations are performed modulo n. g A generator in the finite field GF(n). The reqChecksum field contains the value found in the checksum field of the received SrpgmReq token. The initiator MUST verify this checksum upon receipt of the SrpgmRep token, and abort the context if it does not match. This is necessary to avoid an attacker modifiying the contents of the SrpgmReq token, perhaps in order to have the weakest possible algorithms negotiated for the context. The initiator MUST also: * check that the values for n and g in the received SrpgmRep token are the same as those used in its calculations to produce the SrpgmReq token, and abort the context if they are not. * check that the value of B in the received SrpgmRep token is not zero, and generate an SrpgmError token if it is. ContextData ::= SEQUENCE { channelId ChannelId OPTIONAL, seqNumber INTEGER OPTIONAL, options Options, intgAlgs AlgList, owfAlgs AlgList, confAlgs AlgList OPTIONAL } channelId Used to provide channel binding as per section 1.1.6 of RFC 2078 [GSS-APIv2]. seqNumber The acceptor's four-byte initial sequence number. See section 6.5. options The options requested by the initiator that acceptor is prepared to honour. intgAlgs Burdis [Page 13] draft-ietf-cat-srpgm-02.txt January 2000 The set of integrity algorithms selected by the acceptor. owfAlgs The one-way function algorithm selected by the acceptor. confAlgs The set of confidentiality algorithms selected by the acceptor, if any. Note that the algorithms selected by the acceptor MUST be selected out of the sets of algorithms proposed by the initiator. (See section 4.5 for details on how the algorithm negotiation process takes place). If this is not so then the initiator MUST generate an SrpgmError token. 5.1.4 SrpgmEvidence SrpgmEvidence ::= SEQUENCE { contents EvidenceToken, mac BIT STRING } contents Contents of the token. mac Keyed checksum of contents. EvidenceToken ::= SEQUENCE { tokenId INTEGER(768), contextId RandomInteger, evidence BIT STRING } tokenId Used to identify the type of token. It must have the value 768 (decimal). contextId Used to identify to which context the token belongs. See section 6.4. evidence Proof that the sender knows the shared context key. The contents of the EvidenceToken are integrity protected by computing a checksum of the encoded contents of this structure using the HMAC-MD5 algorithm and the shared context key. This keyed checksum is stored in the mac field of the SrpgmEvidence token. The receiver of this token MUST verify that the evidence supplied is correct and abort the context if it is not. Burdis [Page 14] draft-ietf-cat-srpgm-02.txt January 2000 5.1.5 SrpgmError Error tokens are used to signal errors that occur during the context establishment process. SrpgmError ::= SEQUENCE { tokId INTEGER(1024), contextId RandomInteger } tokId Used to identify the type of token. It must have the value 1024 (decimal). contextId Used to identify to which context the token belongs. See section 6.4. The SrpgmError token is only used during the context establishment process. If either the initiator or the acceptor receives such a token after the context establishment process is complete it MUST be discarded and ignored. If the initiator receives an SrpgmError token during context establishment it MUST regenerate a SrpgmReq token, and if the acceptor receives an SrpgmError token during context establishment it MUST regenerate a SrpgmRep token. Occasions when an SrpgmError token may be generated are specified above. 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.2 Per-Message and Context Deletion Tokens SRPGM uses exactly the same per-message and context deletion tokens as SPKM. Refer to section 3.2 of [SPKM]. As mentioned above all tokens must be framed in an InitialContextToken. The innerContextToken field of per-message tokens will contain one of the following tokens: SrpgmMic; SrpgmWrap; and SrpgmDel. Note that in the ASN.1 specification for SRPGM (see appendix B) some of the definitions with SPKM-specific names have been renamed. 6 Miscellaneous Details 6.1 Minor Status Codes Minor status codes are used as per section 5.1 of [SPKM]. GSS-Related and Implementation-Related codes are the same. SPKM-specific codes should be replaced with: Burdis [Page 15] draft-ietf-cat-srpgm-02.txt January 2000 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_BAD_OWF_ALG_TYPE /* "Unknown one-way function 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" */ 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" */ 6.2 Quality of Protection Quality of Protection (QOP) values, which are used to select amongst negotiated algorithms, are constructed and used as per section 5.2 of [SPKM]. However, in accordance with the MANDATORY and RECOMMENDED algorithms Burdis [Page 16] draft-ietf-cat-srpgm-02.txt January 2000 given in Section 4, the following QOP values are specified for SRPGM: For the Confidentiality MA field: 0001 (1) = blowfishCBC For the Integrity MA field: 0001 (1) = HMAC-MD5 6.3 Support Functions SRPGM implementations MUST provide the SPKM_Parse_token function (appropriately renamed) described in sections 6.1 and 6.2 of [SPKM]. 6.4 Context-ids All tokens have a context-id which is used to map the token to an associated context handle. A description of their use and construction is given in section 6.3 of [SPKM]. 6.5 Sequence numbers Sequence numbers are used to avoid malicious loss, replay or reordering of tokens after context establishment. They are used and processed as discussed in sections 3.2.1.2 and 3.2.1.3 of [SPKM]. 7 Security Considerations Security issues are discussed throughout this document. This mechanism relies on the security of SRP, which bases its security 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. The recommended Blowfish cipher has undergone cryptanalysis for a long period of time and no weaknesses have been found [Blowfish]. References [AES] WWW, "Advanced Encryption Standard (AES) Development Effort", URL: http://www.nist.gov/aes [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 [BLOWFISH] Schneier, Bruce, "The Blowfish Encryption Algorithm", Burdis [Page 17] draft-ietf-cat-srpgm-02.txt January 2000 URL: http://www.counterpane.com/blowfish.html [CAT-WG] WWW, "Common Authentication Technology (cat) Charter", URL: http://www.ietf.org/html.charters/cat-charter.html [DOBBERTIN] Dobbertin, Hans, "The Status of MD5 After a Recent Attack", CryptoBytes, RSA Laboratories, URL: ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf [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 [LIPKEY] Eisler, Mike, "LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM", Internet Draft, draft-ietf-cat-lipkey-02.txt [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-WWW] WWW, "SRP: The Open Source Password Authentication Standard", http://srp.stanford.edu/srp/ [XER] Sue, Hoylen, "XER - A Bridge between ASN.1 and XML", URL: http://www.dstc.edu.au/Research/Projects/xer/xer-2.html Author's Address Keith Burdis Computer Science Department Rhodes University 6139 Grahamstown South Africa Address comments related to this submission to: cat-ietf@mit.edu Burdis [Page 18] draft-ietf-cat-srpgm-02.txt January 2000 Appendix A: Modulus and Generator values Modulus (n) and generator (g) values for various modulus lengths are given below. In each case the modulus is a large safe prime and the generator is a primitve root of GF(n) [SRP]. These values are taken from software developed by Tom Wu and Eugene Jhong for the Stanford SRP distribution [SRP-WWW]. The modulus values are base64 encoded. [264 bits] Modulus = HMujfBWu4LfBFA0j3PpN7UbgUYfv.rMoMNuVRMoekpZ Generator = 2 [384 bits] Modulus = W2KsCfRxb3/ELBvnVWufMA0gbdBlLXbJihgZkgp3xLTKwtPCUhSOHNZ5VLb9pBGR Generator = 2 [512 bits] Modulus = 3Kn/YYiomHkFkfM1x4kayR125MGkzpLUDy3y14FlTMwYnhZkjrMXnoC2TcFAecNl U5kFzgcpKYUbBOPZFRtyf3 Generator = 2 [640 bits] Modulus = CbDP.jR6YD6wAj2ByQWxQxQZ7.9J9xkn2.Uqb3zVm16vQyizprhBw9hi80psatZ8 k54vwZfiIeEHZVsDnyqeWSSIpWso.wh5GD4OFgdhVI3 Generator = 2 [768 bits] Modulus = iqJ7nFZ4bGCRjE1F.FXEwL085Zb0kLM2TdHDaVVCdq0cKxvnH/0FLskJTKlDtt6s Dl89dc//aEULTVFGtcbA/tDzc.bnFE.DWthQOu2n2JwKjgKfgCR2lZFWXdnWmoOh Generator = 2 [1024 bits] Modulus = Ewl2hcjiutMd3Fu2lgFnUXWSc67TVyy2vwYCKoS9MLsrdJVT9RgWTCuEqWJrfB6u E3LsE9GkOlaZabS7M29sj5TnzUqOLJMjiwEzArfiLr9WbMRANlF68N5AVLcPWvNx 6Zjl3m5Scp0BzJBz9TkgfhzKJZ.WtP3Mv/67I/0wmRZ Generator = 2 [1280 bits] Modulus = 3NUKQ2Re4P5BEK0TLg2dX3gETNNNECPoe92h4OVMaDn3Xo/0QdjgG/EvM.hiVV1B dIGklSI14HA38Mpe5k04juR5/EXMU0r1WtsLhNXwKBlf2zEfoOh0zVmDvqInpU69 5f29Iy7sNW3U5RIogcs740oUp2Kdv5wuITwnIx84cnO.e467/IV1lPnvMCr0pd1d gS0a.RV5eBJr03Q65Xy61R Generator = 2 [1536 bits] Modulus = dUyyhxav9tgnyIg65wHxkzkb7VIPh4o0lkwfOKiPp4rVJrzLRYVBtb76gKlaO7ef Burdis [Page 19] draft-ietf-cat-srpgm-02.txt January 2000 5LYGEw3G.4E0jbMxcYBetDy2YdpiP/3GWJInoBbvYHIRO9uBuxgsFKTKWu7RnR7y Tau/IrFTdQ4LY/q.AvoCzMxV0PKvD9Odso/LFIItn8PbTov3VMn/ZEH2SqhtpBUk WtmcIkEflhX/YY/fkBKfBbe27/zUaKUUZEUYZ2H2nlCL60.JIPeZJSzsu/xHDVcx Generator = 2 [2048 bits] Modulus = 2iQzj1CagQc/5ctbuJYLWlhtAsPHc7xWVyCPAKFRLWKADpASkqe9djWPFWTNTdeJ tL8nAhImCn3Sr/IAdQ1FrGw0WvQUstPx3FO9KNcXOwisOQ1VlL.gheAHYfbYyBax XL.NcJx9TUwgWDT0hRzFzqSrdGGTN3FgSTA1v4QnHtEygNj3eZ.u0MThqWUaDiP8 7nqha7XnT66bkTCkQ8.7T8L4KZjIImrNrUftedTTBi.WCi.zlrBxDuOM0da0JbUk QlXqvp0yvJAPpC11nxmmZOAbQOywZGmu9nhZNuwTlxjfIro0FOdthaDTuZRL9VL7 MRPUDo/DQEyW.d4H.UIlzp Generator = 2 Appendix B: ASN.1 Definitions DEFINITIONS EXPLICIT TAGS ::= BEGIN InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { thisMech OBJECT IDENTIFIER, innerContextToken ANY DEFINED BY thisMech } SrpgmInnerContextToken ::= CHOICE { request [0] SrpgmReq, reply [1] SrpgmRep, parameters [2] SrpgmParameters, evidence [3] SrpgmEvidence, error[4] SrpgmError, mic[5] SrpgmMic, wrap[6] SrpgmWrap, del[7] SrpgmDel } SrpgmReq ::= SEQUENCE { contents ReqContents, checksum BIT STRING } ReqContents ::= SEQUENCE { tokenId INTEGER(256), contextId RandomInteger, A BIT STRING, username OCTET STRING, n INTEGER, g INTEGER, reqData ContextData, validity Validity } ContextData ::= SEQUENCE { channelId ChannelId OPTIONAL, Burdis [Page 20] draft-ietf-cat-srpgm-02.txt January 2000 seqNumber INTEGER OPTIONAL, options Options, intgAlgs AlgList, owfAlgs AlgList, confAlgs AlgList OPTIONAL } ChannelId ::= OCTET STRING AlgList ::= SEQUENCE OF AlgorithmIdentifier Options ::= BIT STRING { delegationState (0), mutualState (1), replayDetState (2), sequenceState (3), confState (4), integState (5) } SrpgmParameters ::= SEQUENCE { tokenId INTEGER(257), contextId RandomInteger, n INTEGER, g INTEGER, } SrpgmRep ::= SEQUENCE { contents RepContents, mac BIT STRING } RepContents ::= SEQUENCE { tokenId INTEGER(512), contextId RandomInteger, reqChecksum BIT STRING, repData ContextData, validity Validity OPTIONAL, salt BIT STRING, B BIT STRING, n INTEGER, g INTEGER } SrpgmEvidence ::= SEQUENCE { evidence EvidenceToken, mac BIT STRING } EvidenceToken ::= SEQUENCE { tokenId INTEGER(768), contextId RandomInteger, evidence BIT STRING } Burdis [Page 21] draft-ietf-cat-srpgm-02.txt January 2000 SrpgmError ::= SEQUENCE { tokId INTEGER(1024), contextId RandomInteger } SrpgmMic ::= SEQUENCE { micHeader MicHeader, intCksum BIT STRING } MicHeader ::= SEQUENCE { tokId INTEGER(257), contextId RandomInteger, intAlg [0] AlgorithmIdentifier OPTIONAL, sndSeq [1] SeqNum OPTIONAL } SeqNum ::= SEQUENCE { num INTEGER, dirInd BOOLEAN } SrpgmWrap ::= SEQUENCE { wrapHeader WrapHeader, wrapBody WrapBody } WrapHeader ::= SEQUENCE { tokId INTEGER(513), contextId RandomInteger, intAlg [0] AlgorithmIdentifier OPTIONAL, confAlg [1] AlgorithmIdentifier OPTIONAL, sndSeq [2] SeqNum OPTIONAL } WrapBody ::= SEQUENCE { intCksum BIT STRING, data BIT STRING } SrpgmDel ::= SEQUENCE { delHeader DelHeader, intCksum BIT STRING } DelHeader ::= SEQUENCE { tokId INTEGER(769), contextId RandomInteger, intAlg[0] AlgorithmIdentifier OPTIONAL, sndSeq [1] SeqNum OPTIONAL } RandomInteger ::= BIT STRING Burdis [Page 22] draft-ietf-cat-srpgm-02.txt January 2000 Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime } AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, paramter ANY DEFINED BY algorithm OPTIONAL } END Burdis [Page 23]