Network Working Group D. Taylor Internet-Draft R. Naffah Expires: August 28, 2001 Forge Research February 27, 2001 SM2 -- A Session Management Capable SASL Mechanism draft-naffah-cat-sasl-sm2-00 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. This Internet-Draft will expire on August 28, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document describes a family of SASL mechanisms capable of re-using cryptographic parameters (SASL Security Context) negotiated in a prior exchange. Taylor & Naffah Expires August 28, 2001 [Page 1] Internet-Draft The SM2 SASL Mechanism February 2001 Table of Contents 1. Mechanism Names . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions Used in this Document . . . . . . . . . . . . . 5 4. Data Element Formats . . . . . . . . . . . . . . . . . . . . 6 4.1 Scalar numbers . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 Octet Sequences . . . . . . . . . . . . . . . . . . . . . . 6 4.3 Extended Octet Sequences . . . . . . . . . . . . . . . . . . 6 4.4 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.5 Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.6 Data Element Size Limits . . . . . . . . . . . . . . . . . . 7 4.7 Special Octets . . . . . . . . . . . . . . . . . . . . . . . 7 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 9 5.1 Establishment of a new session . . . . . . . . . . . . . . . 9 5.2 Re-use of an existing session . . . . . . . . . . . . . . . 10 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1 Example of establishing a new SM2 session . . . . . . . . . 12 6.2 Example of an SM2 session re-use . . . . . . . . . . . . . . 14 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1 Modifications to the Java SASL API . . . . . . . . . . . . . 15 7.2 Beyond Java . . . . . . . . . . . . . . . . . . . . . . . . 15 7.3 Cache management . . . . . . . . . . . . . . . . . . . . . . 15 7.4 DIGEST-MD5 as an underlying mechanism for SM2 . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . 17 8.1 Caching cryptographic parameters . . . . . . . . . . . . . . 17 8.2 Flexibility to use new authentication mechanisms . . . . . . 17 8.3 When to invalidate a session . . . . . . . . . . . . . . . . 17 8.4 Updating the SASL Security Context from the Evidence . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 References . . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 A. Proposed Additions to the Java SASL API . . . . . . . . . . 22 A.1 public interface SaslClientExt . . . . . . . . . . . . . . . 22 A.1.1 getSaslSecurityContext . . . . . . . . . . . . . . . . . . . 22 A.1.2 setSaslSecurityContext . . . . . . . . . . . . . . . . . . . 22 A.1.3 evaluateEvidence . . . . . . . . . . . . . . . . . . . . . . 23 A.2 public interface SaslServerExt . . . . . . . . . . . . . . . 23 A.2.1 getSaslSecurityContext . . . . . . . . . . . . . . . . . . . 23 A.2.2 setSaslSecurityContext . . . . . . . . . . . . . . . . . . . 24 A.2.3 evaluateEvidence . . . . . . . . . . . . . . . . . . . . . . 24 Full Copyright Statement . . . . . . . . . . . . . . . . . . 25 Taylor & Naffah Expires August 28, 2001 [Page 2] Internet-Draft The SM2 SASL Mechanism February 2001 1. Mechanism Names The family of SASL [RFC-2222] mechanisms associated with the protocol described in this document are named "SM2-" where is the canonical name of a SASL Mechanism other than SM2. For example, "SM2-SRP-RIPEMD-160" shall denote the SASL mechanism using the protocol described in this document with SRP-RIPEMD-160 as its underlying SASL mechanism. Note that a server advertising one or more SM2 mechanisms, does not preclude it from also advertising its support for the underlying mechanisms used in conjunction with SM2. This ensures interoperability with clients that only support the underlying mechanisms but do not yet support that mechanism under SM2. In other words, an SM2 mechanism constructed over an existing mechanism, say SM2-SRP-SHA-160, is not a replacement for SRP-SHA-160. As such a server wanting, or able, to provide both mecahnisms SHOULD advertise them both. Taylor & Naffah Expires August 28, 2001 [Page 3] Internet-Draft The SM2 SASL Mechanism February 2001 2. Introduction SM2 is a caching mechanism. It relies on another SASL mechanism, referred to as the underlying mechanism, to perform authentication, and provide security services. The underlying mechanism MUST NOT be SM2. Some SASL mechanisms, such as those based on the SRP protocol [SASL-SRP] and the Digest authentication [RFC-2831], provide authentication and the negotiation of a shared session key. The operations involved in the establishement of connections relying on such mechanisms is time-consuming, especially when involving computations of cryptographic primitives and/or shared cryptographic keys. It is desireable to allow both the client and the server, to be able to re-use those cryptographic elements, once negotiated in an initial exchange, without compromising the security of the communication. If two entities are using SM2 with the same underlying mechanism, they can bypass the authentication phase, on their second and subsequent connections, by re-using the security layer parameters negotiated during their initial exchange. A SASL mechanism is described in terms of its (a) authentication layer, and optionally its (b) security layer [RFC-2222]. It is worth noting straight away, that SM2 implies, but does not mandate, that the underlying SASL mechanism provides meaningful security services. In other words, the authors do not see any justification for a session-management based protocol constructed over an underlying mechanism that does not provide a non-trivial security layer. Taylor & Naffah Expires August 28, 2001 [Page 4] Internet-Draft The SM2 SASL Mechanism February 2001 3. Conventions Used in this Document 1. A hex digit is an element of the set: {0, 1, 2, 3, 4, 5, 6, 7, 8 , 9, A, B, C, D, E, F} A hex digit is the representation of a 4-bit string. Examples: 7 = 0111 A = 1010 2. An octet is an 8-bit string. In this document an octet may be written as a pair of hex digits. Examples: 7A = 01111010 02 = 00000010 Depending on the context, one octet may be represented as described above preceded by "0x", for example 0x15 shall represent the 8-bit sequence 00010101. 3. All data is encoded and sent in network byte order (big-endian). 4. 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 [RFC-2119]. Taylor & Naffah Expires August 28, 2001 [Page 5] Internet-Draft The SM2 SASL Mechanism February 2001 4. Data Element Formats This section describes the encoding of the data elements used by the SASL mechanisms described in this document. 4.1 Scalar numbers Scalar numbers are unsigned quantities. Using b[i] to refer to the i-th octet being processed, the value of a two-octet scalar is: ((b[0] << 8) + b[1]), where << is the bit left-shift operator. The value of a four-octet scalar is: ((b[0] << 24) + (b[1] << 16) + (b[2] << 8) + b[3]). 4.2 Octet Sequences These mechanisms generate, use and exchange sequences of octets. When such entities travel on the wire, they shall be preceded by a one-octet scalar quantity representing the count of following octets. We shall use the syntax os(s) to denote the encoded form of the octet sequence. 4.3 Extended Octet Sequences Extended sequences of octets are exchanged when using the security layer. When these sequences travel on the wire, they shall be preceded by a four-octet scalar quantity representing the count of following octets. We shall use the syntax eos(s) to denote the encoded form of the extended octet sequence. 4.4 Text The only character set for text is the UTF-8 [RFC-2279] encoding of Unicode characters [ISO-10646-1]. We shall use the syntax utf8(L) to denote the string L in UTF-8 encoding, preceded by a two-octet scalar quantity representing the count of following octets. 4.5 Buffers In these SASL mechanisms data is exchanged between the client and server using buffers. A buffer acts as an envelope for the sequence Taylor & Naffah Expires August 28, 2001 [Page 6] Internet-Draft The SM2 SASL Mechanism February 2001 of data elements sent by one end-point of the exchange, and expected by the other. A buffer MAY NOT contain other buffers. It may only contain zero, one or more data elements. A buffer shall be encoded as two fields: a four-octet scalar quantity representing the count of following octets, and the concatenation of the octets of the data element(s) contained in the buffer. We shall use the syntax {A|B|C} to denote a buffer containing A, B and C in that order. For example: { 0x00 | utf8(umn) | eos(umir) } is a buffer containing, in the designated order, a 1-octet scalar quantity, and the encoded forms of a Text (umn) and an Extended Octet Sequence (umir). 4.6 Data Element Size Limits The following table details the size limit, in number of octets, for each of the SASL data element encodings described earlier. Data element type Header Size limit in octets (octets) (excluding header) ------------------------------------------------------------ Octet Sequence 1 255 Text 2 65,535 Extended Octet Sequence 4 2,147,483,383 Buffer 4 2,147,483,643 An implementation SHOULD signal an exception if any size constraint is violated. 4.7 Special Octets In this mechanism certain octet values have special significance. These Octets, and the name that they will be referred to as, are listed below: [NUL] The ASCII code point 0x00. It signals the start of an "establishment of a new session" exchange. [SOH] The ASCII code point 0x01. It signals the start of a "re-use session" exchange. [ACK] The ASCII code point 0x06. It signals the server's acceptance Taylor & Naffah Expires August 28, 2001 [Page 7] Internet-Draft The SM2 SASL Mechanism February 2001 of a client's request to re-use an existing session; and finally [NAK] The ASCII code point 0x15. It signals the server's rejection of a client's request to re-use an existing session. When such entities travel on the wire, they shall be encoded as a 1-octet Scalar number. Taylor & Naffah Expires August 28, 2001 [Page 8] Internet-Draft The SM2 SASL Mechanism February 2001 5. Protocol Description The next sections describe the messages exchanged between the SM2 client and server, and their interaction with their peers in the underlying mechanism. 5.1 Establishment of a new session The establishment of a new SM2 session delegates to the underlying mechanism the authentication function. Any parameters required by the underlying mechanism, MUST be passed into the SM2 mechanism when it is itself initialised. In an SM2 exchange, the client always initiates the exchange. The first SASL buffer sent by an SM2 client contains the Special Octet [NUL] indicating the initiation of the exchange, followed by the initial response, which might be 0-octet long, of the client's underlying mechanism. From this point on, the SM2 mechanism passes the challenges and responses to the underlying mechanism, and passes back the responses and challenges from the underlying mechanism to the peers. The following diagram shows the data exchanged in this process: Figure 1: Establishment of a new session. Underlying Underlying SM2 Mechanism Mechanism SM2 Client Client Server Server | | | | -- { [NUL] | eos(umir) } -------------------------------> <------------------ challenge -- -- response -------------------> ... <--------------------------------------- { utf8(sid) } -- where: umir the underlying mechanism initial response, if it has one, sid the session identifier as set by the server. Taylor & Naffah Expires August 28, 2001 [Page 9] Internet-Draft The SM2 SASL Mechanism February 2001 5.2 Re-use of an existing session If two entities have already been through the authentication phase, and have both cached the security layer parameters, a shorter exchange may take place to re-use those parameters. In the exchange below, the Evidence fields (Ec for the client, and Es for the server) are octet strings, possibly 0-octet long, that represent mechanism-specific data. An Evidence may be injected into the underlying mechanism peer's security layer context, to allow computation of a different shared secret for each re-use of the session. How a new shared secret is computed from a previously known value and an Evidence is an underlying mechanism specific issue. The mechanism data exchange for successfully re-using a session is shown below: Figure 2: Successful re-use of an existing session. Underlying Underlying SM2 Mechanism Mechanism SM2 Client Client Server Server | | | | -- { [SOH] | utf8(sid) | os(Ec) } ----------------------> <---------------------------------- { [ACK] | os(Es) } -- where: Ec the client evidence, Es the server evidence. If the server accepts the request for re-using a session, it responds with the Special Octet [ACK] and, optionally, its version of the Evidence (Es). On the other hand, if the server rejects the request for re-using a session (including the case where an unknown session identifier has been submitted), it responds with the Special Octet [NAK] only. In this case, the SM2 client MUST attempt to establish a new session with the peer, and if this fails it MUST report an authentication failure. This retry facility MUST only be attempted once if re-using a session fails. Taylor & Naffah Expires August 28, 2001 [Page 10] Internet-Draft The SM2 SASL Mechanism February 2001 The data exchange when failing to re-use a session is shown below: Figure 3: Failure re-using an existing session. Underlying Underlying SM2 Mechanism Mechanism SM2 Client Client Server Server | | | | -- { [SOH] | utf8(sid) | os(Ec) } ----------------------> <------------------------------------------- { [NAK] } -- Taylor & Naffah Expires August 28, 2001 [Page 11] Internet-Draft The SM2 SASL Mechanism February 2001 6. Example The following sections show two examples: one for an establishment of a new SM2 session, and the second one is for a successful re-use of the session already established. The underlying mechanism used with SM2 in both examples is an implementation of the SRP-SHA-160 mechanism. Lines starting with "C" denote messages sent from the client side, while those stating with "S" are from the server side. 6.1 Example of establishing a new SM2 session C1: 0000000600047465 7374 S1: 000001580100AC6B DB41324A9A9BF166 DE5E1389582FAF72 B6651987EE07FC31 92943DB56050A373 29CBB4A099ED8193 E0757767A13DD523 12AB4B03310DCD7F 48A9DA04FD50E808 3969EDB767B0CF60 95179A163AB3661A 05FBD5FAAAE82918 A9962F0B93B855F9 7993EC975EEAA80D 740ADBF4FF747359 D041D5C33EA71D28 1E446B14773BCA97 B43A23FB801676BD 207A436C6481F1D2 B9078717461A5B9D 32E688F877485445 23B524B0D57D5EA7 7A2775D2ECFA032C FBDBF52FB3786160 279004E57AE6AF87 4E7303CE53299CCC 041C7BC308D82A56 98F3A8D0C38271AE 35F8E9DBFBB694B5 C803D89F7AE435DE 236D525F54759B65 E372FCD68EF20FA7 111F9E4AFF730001 020051696E746567 726974793D686D61 632D6D64352C696E 746567726974793D 686D61632D736861 312C696E74656772 6974793D686D6163 2D726970656D642D 3136302C7265706C 6179206465746563 74696F6E C2: 0000012D00047465 737401007607EED2 250CDA986161BCF5 B7DA968952E9EFDC 2FF34A91280AF465 43096E90F1D29813 D445B63683E96797 ECC684D829274086 5E7C6E85F6C6FE22 3E4DBA4ACA38DBB3 8BCDEC00826F4D67 058A48F96AEF684E 558EED5B61A0D6E6 4FC34036DC2E085C D5BA7947BF49FEE4 BE03D340108355C8 36F34C85278069C1 CD5BB7954ECC5724 F2A8376DF76209E0 8003EAC5EAAEF50B DEDE0863E31215D8 1E17984A9C68CA02 8ABCB9DD88E23C1F 7AC961E5CDB7628C DE8D3FDCAE6DCBFB 73C588A4F84782A5 E054BF28AB90370F CD416EFFDF9B3A3E D532E599C1F5DDBB 6909DA6FD17CF606 6E0FD20E17EC8867 17EA03FE61CC2D54 0832AFEE4F2D69E9 25C8117200237265 706C617920646574 656374696F6E2C69 6E74656772697479 3D686D61632D6D64 35 S2: 0000010D0ADE6299 E766BAA0695A6D01 003635F4AF273672 E0457804F8E21835 A3D4435A9004E7A3 B1207056A3F644A5 E40DF7D89A53C3C4 4090E4CCEBA453DC 6ABC21A0EB6EB1C4 5A142994C0D4D879 0E3F3002E2DCE328 090E9A329757F261 799C5FC7FBA35A0D D30B9BFC64F8DA33 B04F261731926755 4DBD58FE1C7C1B02 F700643A291C2C34 40DC889766D4177C 856171781D689C38 6C5B45A92FDEDCE8 C6C2696BB8ACA26D EAD285B69043F373 D1D5C61E9267B6D1 0EF3921477E95869 6D10AA48EC879C3E 2E49DE3458D69B2A 72AF26F622750A4A E62AE5B09FDB9F40 E2B514C5CB548942 84947FD55DEC89B6 C9CC082F22206881 0F2D12E6F311727D F167705475EEFDB3 EEB2F14A436F705A 33 C3: 00000015149C6A9B C7D0E8E64BFD3052 D7DD5DCA02008F2E 14 Taylor & Naffah Expires August 28, 2001 [Page 12] Internet-Draft The SM2 SASL Mechanism February 2001 S3: 0000001514F8BA5F 3853896A7AECDFA2 2AD0D6E09A97AFB6 88 S4: 000000140012534D 322D5349442D3030 3030303030303031 The following is a detailed description of each step. C1: An SM2 Client initiates an establishment of a new session exchange. The SASL buffer contains the [NUL] Octet, followed by the SRP client's initial response encoded as an Extended Octet Sequence. The SRP client's initial response in this example is the Text 'test' representing U --the username. S1: The SM2 server engages in an "establishment of a new session" exchange. It decodes the SRP client's initial response and passes it to its underlying SRP server object. The SRP server evaluates the initial response and sends back a SASL buffer containing: 1. The MPI encoding of the public shared modulus N which in this example is 256-octet long. 2. The MPI encoding of the field generator g which in this example is 1-octet long (value 0x02), and finally 3. The 81-octet long Text containing the SRP server's available options. In this example, this list consists of the string: integrity=hmac-md5,integrity=hmac-sha1,integrity=hmac-ripemd- 160,replay detection. C2: The SRP client responds to the SRP server challenge by returning a SASL buffer containing: 1. The 4-octet long Text 'test' representing the authorization ID for this exchange, 2. The 256-octet long MPI A representing the SRP client's ephemeral public key, and finally 3. The 35-octet long Text containing the client's chosen options list, which in this example is: replay detection,integrity= hmac-md5. S2: The SRP server, issues the new challenge containing: 1. The 10-octet long Octet Sequence representing the salt 's', followed by 2. The 256-octet long MPI B representing the SRP server's Taylor & Naffah Expires August 28, 2001 [Page 13] Internet-Draft The SM2 SASL Mechanism February 2001 ephemeral publick key. C3: The SRP client evaluates the server's challenge and responds with the 20-octet Octet Sequence representing its Evidence: M1. S3: The SRP server evaluates the client's response and finally sends the 20-octet Octet Sequence representing its Evidence: M2. S4: The SM2 server terminates the exchange by sending to the SM2 client the session ID generated for this session. In this example it is the Text "SM2-SID-0000000001." 6.2 Example of an SM2 session re-use C1: 0000001601001253 4D322D5349442D30 3030303030303030 3100 S1: 000000020600 The following is a detailed description of each step. C1: An SM2 Client initiates a session re-use exchange. The SASL buffer contains: 1. The [SOH] Special Octet. 2. The session ID encoded as a Text. The value of this ID in the example is "SM2-SID-0000000001." 3. The Evidence of the underlying SRP client in use with the session in question. In this example this evidence is 0-octet long. S1: The SM2 server accepts the request to re-use the identified session and sends back the [ACK] Octet followed by its version of the Evidence (which in this example is 0-octet long). Taylor & Naffah Expires August 28, 2001 [Page 14] Internet-Draft The SM2 SASL Mechanism February 2001 7. Discussion 7.1 Modifications to the Java SASL API Implementing this mechanism in Java, would require modifying the proposed Java SASL API [Java API]. The modification consists of adding three new methods, with similar signatures, to both the client and server. This can be achieved by: 1. modifying the current specifications to include these methods, 2. defining a new interface, which includes these methods, and make both SaslClient and SaslServer extend it, or finally 3. adding two new interfaces, say SaslClientExt and SaslServerExt that extend SaslClient and SaslServer respectively, and include these methods. The last alternative is the most attractive, since it leaves a mechanism implementor with a choice whether to allow the implementation to be used with SM2 or not --depending on which interface the client and server implement. The interfaces in question are detailed in Appendix A. 7.2 Beyond Java The authors intend this mechanism to be useful for implementations of SASL in languages other than Java. However, such implementations MUST have the following capabilities to allow this mechanism to work: 1. A mechanism can create another mechanism. 2. The SASL Security Context, containing the crpytographic parameters of a mechanism may be extracted in a form that can be stored in a cache. 3. A mechanism (or a security layer) can be [re-]initialised from a SASL Security Context containing cryptographic parameters stored in a cache. 7.3 Cache management o Should we mandate a Time-To-Live per session for the SM2 server? o After a new session is successfully established, the SM2 server sends a session identifier to the client (see Figure 2). It is the responsibility of the client to ensure that it will be able to re-use this value in the future. In other words, the SM2 Taylor & Naffah Expires August 28, 2001 [Page 15] Internet-Draft The SM2 SASL Mechanism February 2001 client should have access to a mapping function that looks up a session identifier to re-use, from data included in a request to instantiate a new underlying mechanism client. If such a session is found, then the SM2 client would only need to 'recreate' the underlying client with the SASL Security Context of that session. 7.4 DIGEST-MD5 as an underlying mechanism for SM2 The proposed SASL mechanism DIGEST-MD5 describes a mechanism for re-use of some data negotiated in a previous exchange (section 2.2 "Subsequent Authentication" in [RFC-2831]). More specifically: "If the client has previously authenticated to the server, and remembers the values of username, realm, nonce, nonce-count, cnonce, and qop that it used in that authentication, and the SASL profile for a protocol permits an initial client response, then it MAY perform "subsequent authentication", as defined in this section." Such a mechanism can be used as an underlying mechanism for SM2. The following notes clarify the previous statement: 1. An "Initial Authentication" (section 2.1 of [RFC-2831]) is the exchange used in an SM2 establishment of a new session. 2. The SASL Security Context parameters for a DIGEST-MD5 implementation SHOULD include: username, realm, nonce, nonce-count, cnonce, and qop (described in section 2.1.2 of [RFC-2831]. 3. The client's Evidence Ec in an SM2 session re-use exchange, is a full DIGEST-MD5 "digest-response" as described in section 2.2.1 of [RFC-2831]. 4. If the DIGEST-MD5 client's mechanism "digest-response" is valid, and the the DIGEST-MD5 server chose to deem that authentication has succeeded, the SM2 server can successfully conclude a session re-use exchnage. 5. If the DIGEST-MD5 client's mechanism "digest-response" is invalid, or if it is valid but the DIGEST-MD5 server decides to refresh the authentication parameters by sending a new "digest-challenge", then an SM2 failed session re-use message should be sent back to the SM2 client. Taylor & Naffah Expires August 28, 2001 [Page 16] Internet-Draft The SM2 SASL Mechanism February 2001 8. Security Considerations 8.1 Caching cryptographic parameters SM2 relies on the ability to extract and cache the cryptographic parameters from an underlying mechanism --the SASL Security Context--, and to initialise an instance of the underlying mechanism client and/or server with that cached context. One might argue against this practice for security reasons. Yet, most cryptographic software modules have their parameters somewhere in the program memory, so SM2 is as safe as those modules. In addition, if a salt is used (the Evidence or part of it), the actual values used for each exchange will be different. This is a similar concept to caching TLS [RFC-2246] sessions and hence SM2, coupled with a strong underlying mechanism, should be no less secure. 8.2 Flexibility to use new authentication mechanisms By using a second authentication mechanism to do the actual authentication function, SM2 can always be configured to use the latest, proven, authentication techniques for which a SASL mechanism has been specified and implemented. 8.3 When to invalidate a session The server MUST discard the existing session information when an attempt to re-use the session fails. The server MUST cache the SASL Security Context for a session only when a new one is established and after the authentication function is successfully completed. Bound by the above rule, an SM2 server is thus susceptible to a denial-of-service like attack. Indeed, an attacker may repeatedly attempt to re-use sessions, thus causing the server to invalidate those sessions soon after they were established. But this would be no different to the attacker carrying out her attack on the underlying mechanism server if/when SM2 is not used. The result of such an attack would be that the full underlying authentication procedure would take place. 8.4 Updating the SASL Security Context from the Evidence The SM2 mechanism will use the security layer provided by its underlying mechanism. The cryptographic parameters of this security layer, contained in a SASL Security Context, are cached when the authentication phase is complete. These parameters may be varied on a per-connection basis Taylor & Naffah Expires August 28, 2001 [Page 17] Internet-Draft The SM2 SASL Mechanism February 2001 by means of the optional Evidence parameter passed in during the session re-use exchange (see Figure 3). What if that Evidence is not enough to update the cryptographic parameters to an acceptable security level; e.g. a weak key is obtained? Two alternatives are possible: 1. An implementation may contain a recovery mechanism that would allow it to continue the algorithm until a valid and acceptable value is obtained, or 2. An implementation may cause an error condition that would be intercepted by the SM2 peer. If it was the client, then a new session would be negotiated, otherwise if it is the server, then a failed re-use of a session reply would be returned (see Figure 4). Taylor & Naffah Expires August 28, 2001 [Page 18] Internet-Draft The SM2 SASL Mechanism February 2001 9. Acknowledgements The following people provided valuable feedback in the preparation of this document: Keith Burdis Taylor & Naffah Expires August 28, 2001 [Page 19] Internet-Draft The SM2 SASL Mechanism February 2001 References [RFC-2222] Myers, J.G., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997, . [SASL-SRP] Burdis, K.R. and R. Naffah, "Secure Remote Password SASL Mechanism", January 2001, . [RFC-2831] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000, . [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 0014, RFC 2119, March 1997, . [RFC-2279] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2279, January 1998, . [ISO-10646-1] "International Standard --Information technology-- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1 Architecture and Basic Multilingual Plane", ISO/IEC 10646-1, 1993. [Java API] Lee, R. and R. Weltman, "The Java SASL Application Program Interface", November 2000, . [RFC-2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999, . [RFC-2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999, . Taylor & Naffah Expires August 28, 2001 [Page 20] Internet-Draft The SM2 SASL Mechanism February 2001 Authors' Addresses David Taylor Forge Research Pty. Limited Suite 116, Bay 9 Locomotive Workshop, Australian Technology Park Cornwallis Street Eveleigh, NSW 1430 AU EMail: dtaylor@forge.com.au Raif S. Naffah Forge Research Pty. Limited Suite 116, Bay 9 Locomotive Workshop, Australian Technology Park Cornwallis Street Eveleigh, NSW 1430 AU EMail: raif@forge.com.au Taylor & Naffah Expires August 28, 2001 [Page 21] Internet-Draft The SM2 SASL Mechanism February 2001 Appendix A. Proposed Additions to the Java SASL API In the next sections, the type AlgorithmParamterSpec is imported from the java.security.spec package, while the proposed new interfaces are to be part of the javax.security.sasl package. All other types are from the latter package too. A.1 public interface SaslClientExt An interface that extends the SaslClient interface. An object implementing this interface can negotiate authentication using one of the IANA-registered mechanisms, and be used as a client-side underlying mechanism for the SM2 mechanism. A.1.1 getSaslSecurityContext AlgorithmParameterSpec getSaslSecurityContext() throws SaslException; Retrieves an object that encapsulates the SASL Security Context parameters for future re-use. This method can be called only after the authentication exchange has completed (i.e., when isComplete() returns true); otherwise, a SaslException is thrown. A.1.2 setSaslSecurityContext void setSaslSecurityContext(AlgorithmParameterSpec ctx) throws SaslException; Replaces the current SASL Security Context parameters of an object with those encapsulated in the designated argument. Parameter is: ctx The designated instance of the object encapsulating the new values of SASL Security Context parameters to use after successful completion of this method. Taylor & Naffah Expires August 28, 2001 [Page 22] Internet-Draft The SM2 SASL Mechanism February 2001 A.1.3 evaluateEvidence byte[] evaluateEvidence(byte[] peerEvidence) throws SaslException; Computes new values for all or some of the SASL Security Context parameters and returns an Evidence that will be sent to the peer. The rationale for this method is to (a) allow the peers to 're-cycle' their cryptographic paramemeters so each re-use of the exchange would be based on different values every time; and (b) allow the peers to check, in the absence of a full authentication exchange, that the peer really knows more than just the session ID. This method throws a SaslException if during the process of updating the SASL Security Context parameters, or while generating the Evidence, it encounters an exception. Parameter is: peerEvidence The peer's Evidence as received in a session re-use exchange. A.2 public interface SaslServerExt An interface that extends the SaslServer interface. An object implementing this interface can negotiate authentication using one of the IANA-registered mechanisms, and be used as a server-side underlying mechanism for the SM2 mechanism. A.2.1 getSaslSecurityContext AlgorithmParameterSpec getSaslSecurityContext() throws SaslException; Retrieves an object that encapsulates the SASL Security Context parameters for future re-use. This method can be called only after the authentication exchange has completed (i.e., when isComplete() returns true); otherwise, a SaslException is thrown. Taylor & Naffah Expires August 28, 2001 [Page 23] Internet-Draft The SM2 SASL Mechanism February 2001 A.2.2 setSaslSecurityContext void setSaslSecurityContext(AlgorithmParameterSpec ctx) throws SaslException; Replaces the current SASL Security Context parameters of an object with those encapsulated in the designated argument. Parameter is: ctx The designated instance of the object encapsulating the new values of SASL Security Context parameters to use after successful completion of this method. A.2.3 evaluateEvidence byte[] evaluateEvidence(byte[] peerEvidence) throws SaslException; Computes new values for all or some of the SASL Security Context parameters and returns an Evidence that will be sent to the peer. The rationale for this method is to (a) allow the peers to 're-cycle' their cryptographic paramemeters so each re-use of the exchange would be based on different values every time; and (b) allow the peers to check, in the absence of a full authentication exchange, that the peer really knows more than just the session ID. This method throws a SaslException if during the process of updating the SASL Security Context parameters, or while generating the Evidence, it encounters an exception. Parameter is: peerEvidence The peer's Evidence as received in a session re-use exchange. Taylor & Naffah Expires August 28, 2001 [Page 24] Internet-Draft The SM2 SASL Mechanism February 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Taylor & Naffah Expires August 28, 2001 [Page 25]