CAT Working Group K.R. Burdis Internet Draft Rhodes University Expires: June 2000 December 1999 draft-ietf-cat-srpgm-01.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 copied verbatim. 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-01.txt December 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." 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 Burdis [Page 2] draft-ietf-cat-srpgm-01.txt December 1999 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 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 mallicious loss, replay or reordering of tokens, as well as to remove the need for secure timestamps * 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 Burdis [Page 3] draft-ietf-cat-srpgm-01.txt December 1999 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: 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. 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 Burdis [Page 4] draft-ietf-cat-srpgm-01.txt December 1999 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 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 code for the SrpgmEvidence token. 4.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 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 Burdis [Page 5] draft-ietf-cat-srpgm-01.txt December 1999 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. 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 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 Burdis [Page 6] draft-ietf-cat-srpgm-01.txt December 1999 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 When thisMech is SRPGM, innerContextToken is defined as follows: SrpgmInnerContextToken ::= CHOICE { request [0] SrpgmReq, reply [1] SrpgmRep, evidence [2] SrpgmEvidence, error[3] SrpgmError, mic[4] SrpgmMic, wrap[5] SrpgmWrap, del[6] SrpgmDel } All tokens are encoded using ASN.1 DER. (The merits of using the XER encoding described in [XER] need to be discussed). 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; SrpgmEvidence; and SrpgmError. 5.1.1 SrpgmReq SrpgmReq ::= SEQUENCE { tokenId INTEGER(256), contextId RandomInteger, publicKeyA BIT STRING, username OCTET STRING, reqData ContextData, validity Validity } tokenId Used to identify the type of token. It must have the value 256 (decimal). contextId Burdis [Page 7] draft-ietf-cat-srpgm-01.txt December 1999 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. publicKeyA The ephemeral public key generated by the initiator. username The initiator's username. 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. 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. ChannelId ::= OCTET STRING Burdis [Page 8] draft-ietf-cat-srpgm-01.txt December 1999 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 5.1.2 SrpgmRep SrpgmRep ::= SEQUENCE { tokenId INTEGER(512), contextId RandomInteger, repData ContextData, validity Validity OPTIONAL, salt BIT STRING, publicKeyB 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. repData Specifies the algorithms that the acceptor supports out of the lists that the initiator provided, and the options that the acceptor Burdis [Page 9] draft-ietf-cat-srpgm-01.txt December 1999 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. publicKeyB 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). Note, that if the values for n and g in the SrpgmRep token are different from the ones that the initiator used in its calculations for the SrpgmReq token, then the initiator MUST send a new SrpgmReq token with data computed using the new values for n and g. 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 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. Burdis [Page 10] draft-ietf-cat-srpgm-01.txt December 1999 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. 5.1.3 SrpgmEvidence SrpgmEvidence ::= SEQUENCE { evidence EvidenceToken, evidenceIntg BIT STRING } evidence evidence that the sender knows the shared context key. evidenceIntg The integrity checksum. EvidenceToken ::= SEQUENCE { tokenId INTEGER(768), contextId RandomInteger, seqnumInitiator INTEGER, seqnumAcceptor INTEGER, contextData ContextData, validity Validity, 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. seqnumInitiator The initiator's four-byte initial sequence number. See section 6.5. seqnumAcceptor The acceptor's four-byte initial sequence number. See section 6.5. contextData The agreed upon context settings and algorithm lists. validity The agreed upon context lifetime. 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 token using the HMAC-MD5 algorithm and the shared context key. The checksum is stored in the evidenceIntg field of the SrpgmEvidence token. Burdis [Page 11] draft-ietf-cat-srpgm-01.txt December 1999 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 EvidenceToken, 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 SrpgmDel token if they are not. The lack of integrity protection of the SrpgmReq and SrpgmRep tokens is the reason why the HMAC-MD5 algorithm (the mandatory integrity algorithm) MUST be used to compute the checksum on the SrpgmEvidence token. The set of negotiated integrity algorithms can not be trusted before the SrpgmEvidence token is generated, because this set of algorithms may have been modified by an attacker. 5.1.4 Error Token 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 an SrpgmReq or SrpgmRep token is received in error, the receiving function (either gss_init_sec_context() or gss_accept_sec_context()) will generate an SrpgmError token to be sent to the peer (if the peer is still in the context establishment process) and will return GSS_S_CONTINUE_NEEDED. If, on the other hand, no context establishment response is expected from the peer (i.e., the peer has completed context establishment), the function will return the appropriate major status code (e.g., GSS_S_BAD_SIG) along with a minor status of GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT and all context-relevant information will be deleted. The output token will not be an SrpgmError token but will instead be an SrpgmDel 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 SrpgmReq 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 SrpgmReq token when it is expecting an SrpgmEvidence token, it will discard the data from the Burdis [Page 12] draft-ietf-cat-srpgm-01.txt December 1999 previous SrpgmReq 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 SrpgmRep 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.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 for SRPGM 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: 6.1.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" */ Burdis [Page 13] draft-ietf-cat-srpgm-01.txt December 1999 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 to prove knowledge of context key and settings." */ 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 given in Section 3, 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 mallicious loss, replay or reordering of tokens, as well as to remove the need for secure Burdis [Page 14] draft-ietf-cat-srpgm-01.txt December 1999 timestamps. 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. 8 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", 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 Burdis [Page 15] draft-ietf-cat-srpgm-01.txt December 1999 [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 [XER] Sue, Hoylen, "XER - A Bridge between ASN.1 and XML", URL: http://www.dstc.edu.au/Research/Projects/xer/xer-2.html 9 Author's Address Keith Burdis Computer Science Department Rhodes University 6139 Grahamstown South Africa Email: cskb@cs.ru.ac.za Appendix A: 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, evidence [2] SrpgmEvidence, error[3] SrpgmError, mic[4] SrpgmMic, wrap[5] SrpgmWrap, del[6] SrpgmDel } SrpgmReq ::= SEQUENCE { tokenId INTEGER(256), contextId RandomInteger, publicKeyA BIT STRING, username OCTET STRING, reqData ContextData, validity Validity } Burdis [Page 16] draft-ietf-cat-srpgm-01.txt December 1999 ContextData ::= SEQUENCE { channelId ChannelId OPTIONAL, 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) } SrpgmRep ::= SEQUENCE { tokenId INTEGER(512), contextId RandomInteger, repData ContextData, validity Validity OPTIONAL, salt BIT STRING, publicKeyB BIT STRING, n INTEGER, g INTEGER } SrpgmEvidence ::= SEQUENCE { evidence EvidenceToken, evidenceIntg BIT STRING } EvidenceToken ::= SEQUENCE { tokenId INTEGER(768), contextId RandomInteger, seqnumInitiator INTEGER, seqnumAcceptor INTEGER, contextData ContextData, validity Validity, evidence BIT STRING } SrpgmError ::= SEQUENCE { tokId INTEGER(1024), contextId RandomInteger } SrpgmMic ::= SEQUENCE { Burdis [Page 17] draft-ietf-cat-srpgm-01.txt December 1999 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 Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime } AlgorithmIdentifier ::= SEQUENCE { Burdis [Page 18] draft-ietf-cat-srpgm-01.txt December 1999 algorithm OBJECT IDENTIFIER, paramter ANY DEFINED BY algorithm OPTIONAL } END Burdis [Page 19]