Network Working Group D. Taylor Internet-Draft R. Naffah Expires: May 10, 2002 Forge Research November 9, 2001 SM2 -- A Session Management Capable SASL Mechanism draft-naffah-cat-sasl-sm2-01 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 May 10, 2002. 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 May 10, 2002 [Page 1] Internet-Draft The SM2 SASL Mechanism November 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 4.8 Unsigned Integers (UINT) . . . . . . . . . . . . . . . . . . 8 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 B. Changes since last draft . . . . . . . . . . . . . . . . . . 25 Full Copyright Statement . . . . . . . . . . . . . . . . . . 26 Taylor & Naffah Expires May 10, 2002 [Page 2] Internet-Draft The SM2 SASL Mechanism November 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 May 10, 2002 [Page 3] Internet-Draft The SM2 SASL Mechanism November 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 May 10, 2002 [Page 4] Internet-Draft The SM2 SASL Mechanism November 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]. Taylor & Naffah Expires May 10, 2002 [Page 5] Internet-Draft The SM2 SASL Mechanism November 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 encoding [RFC-2279] 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 May 10, 2002 [Page 6] Internet-Draft The SM2 SASL Mechanism November 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 MUST 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, are listed below: The ASCII code point 0x00. It signals the start of an "establishment of a new session" exchange. The ASCII code point 0x01. It signals the start of a "re-use session" exchange. The ASCII code point 0x06. It signals the server's Taylor & Naffah Expires May 10, 2002 [Page 7] Internet-Draft The SM2 SASL Mechanism November 2001 acceptance of a client's request to re-use an existing session; and finally 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 1-octet Scalar numbers. 4.8 Unsigned Integers (UINT) This mechanism uses unsigned integer values ranging from zero to 4,294,967,296. When such entities travel on the wire, they shall be encoded as 4-octet Scalar numbers. We shall use the syntax uint(n) to denote the encoding of an Unsinged Integer n. Taylor & Naffah Expires May 10, 2002 [Page 8] Internet-Draft The SM2 SASL Mechanism November 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 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. When the underlying mechanism exchange has concluded, the SM2 server sends (a) a session identifier and (b) a Time-To-Live (TTL) indication to the SM2 client. The session identifier will be used by the SM2 client if/when it will later re-use this session, while the TTL indicates to the SM2 client, how long, in seconds, the SM2 server will attempt to keep valid this session's parameters for later re-use by the SM2 client. A TTL indicator value of zero means that the session is valid forever. The following diagram shows the data exchanged in this process: Taylor & Naffah Expires May 10, 2002 [Page 9] Internet-Draft The SM2 SASL Mechanism November 2001 Figure 1: Establishment of a new session. Underlying Underlying SM2 Mechanism Mechanism SM2 Client Client Server Server | | | | -- { | eos(umir) } -------------------------------> <------------------ challenge -- -- response -------------------> ... <--------------------------- { utf8(sid) | uint(ttl) } -- where: umir the underlying mechanism initial response, if it has one, sid the session identifier as set by the server. ttl the session Time-To-Live indication in seconds. 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: Taylor & Naffah Expires May 10, 2002 [Page 10] Internet-Draft The SM2 SASL Mechanism November 2001 Figure 2: Successful re-use of an existing session. Underlying Underlying SM2 Mechanism Mechanism SM2 Client Client Server Server | | | | -- { | utf8(sid) | os(Ec) } ----------------------> <---------------------------------- { | 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 and 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 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. 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 | | | | -- { | utf8(sid) | os(Ec) } ----------------------> <------------------------------------------- { } -- Taylor & Naffah Expires May 10, 2002 [Page 11] Internet-Draft The SM2 SASL Mechanism November 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: 0000000F00000000 0A00000006000474 657374 S1: 000001C00100AC6B 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 020A251CA1230431 ABA188CE00AE6D61 6E6461746F72793D 7265706C61792064 6574656374696F6E 2C7265706C617920 646574656374696F 6E2C696E74656772 6974793D686D6163 2D736861312C696E 746567726974793D 686D61632D6D6435 2C636F6E66696465 6E7469616C697479 3D6165732C636F6E 666964656E746961 6C6974793D636173 74352C636F6E6669 64656E7469616C69 74793D626C6F7766 6973682C6D617862 756666657273697A 653D323134373438 33363433 C2: 0000015F0100407D 3913C5AAABB611C5 42328A208021C934 53D2FA3F1E3F253B 3F46A800A8D973EF 893941AFF6E31590 D8FF8B2A3B702979 B961E0EE1F0E6FC4 9B0B133587B27982 C2B66EBBEB9B5F1B 8D33E62FC81393F4 88D2463CAFE0AC74 4985117CDA14685A F90F0A0A42751F5D B1C2C24F6D54422D D135864E2F5A346F 6C94836F788FDE45 01D5F30228CBB066 832D1A9E010D94B7 F8D2DC8220F7B950 87EA7835AD7CFB52 3D6FE2BAF68DE885 57F29BBACFB1C47F 0025A589AC0603FD 33BE3FA53B8AE1E9 D77D241EA1458016 B9F57FD7BBA87F9F 80DE53012564A719 7ABC0E028C4055BD 825DFEB253A31F48 C7393A9E872140BF 8CE479DD0D975492 6E5F0C5DB0860004 7465737400557265 706C617920646574 656374696F6E2C69 6E74656772697479 3D686D61632D6D64 352C636F6E666964 656E7469616C6974 793D626C6F776669 73682C6D61786275 6666657273697A65 3D32313437343833 363433 S2: 000001020100A2AC B28D526F4601C90E DDF740243881C345 7B781D1D325DC95F 0CC8B728062D93AE 10693F97A89DB370 3612F89E130251A7 84C87AF5F016A76B BAECC1EFC0DA24F2 5C2FAC77CC5A33C4 5562AAF74DB99237 12BF29F5D9B6D15D 94CE4680B04653C2 663B66F237E3567C 7DED5D4728536E96 3AC8DEC185D508AA 9F6C993CABE7A037 25BC9B002B72EED7 954F7018194810F2 FFB04F6E239BA11D AC3179431CBB310D D1A87F5A9BB56C0F 80E90237A17E9982 A8EFD122228F684F 310170A3800F8FC4 DCD94889CE8B6AD7 6CDF0D69DF33A288 98B34AB5EA9575BA Taylor & Naffah Expires May 10, 2002 [Page 12] Internet-Draft The SM2 SASL Mechanism November 2001 4070CF3FE7D339A6 BC0B2D395395EACD A5B041B68104B683 B40B9B167B646095 4DE567D04338 C3: 00000015140020A0 94A727918CC8DC26 92A87C9435D53C7F 70 S3: 000000180012534D 322D5349442D3030 3030303030303031 00000000 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 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), 3. The Octet Sequence encoding of the user's salt which in this example is 10-octet long, and finally 4. The 174-octet long Text containing the SRP server's available options. In this example, this list consists of the string (white spaces added for clarity): mandatory = replay detection, replay detection, integrity = hmac-sha1, integrity = hmac-md5, confidentiality = aes, confidentiality = cast5, confidentiality = blowfish, maxbuffersize = 2147483643. C2: The SRP client responds to the SRP server challenge by returning a SASL buffer containing: 1. The 256-octet long MPI A representing the SRP client's ephemeral public key, 2. The 4-octet long Text 'test' representing the authorization ID for this exchange, and finally 3. The 85-octet long Text containing the client's chosen options list, which in this example is (white spaces added for clarity): replay detection, integrity = hmac-md5, Taylor & Naffah Expires May 10, 2002 [Page 13] Internet-Draft The SM2 SASL Mechanism November 2001 confidentiality = blowfish, maxbuffersize = 2147483643". S2: The SRP server, issues a new challenge containing the 256-octet long MPI B representing the SRP server's 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 SM2 server terminates the exchange by sending to the SM2 client the session ID generated for this session, followed by the TTL indicator. In this example the session ID is the Text "SM2-SID-0000000001," while the TTL indicator is zero. 6.2 Example of an SM2 session re-use C1: 0000001A01001253 4D322D5349442D30 3030303030303030 310465261450 S1: 0000000606046526 1450 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 Special Octet, 2. The session ID encoded as a Text. The value of this ID in the example is "SM2-SID-0000000001," and finally 3. The Evidence of the underlying SRP client in use with the session in question. In this example this evidence is 4-octet long. S1: The SM2 server accepts the request to re-use the identified session and sends back the Special Octet followed by its version of the Evidence (which in this example is 4-octet long). Taylor & Naffah Expires May 10, 2002 [Page 14] Internet-Draft The SM2 SASL Mechanism November 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 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 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 Taylor & Naffah Expires May 10, 2002 [Page 15] Internet-Draft The SM2 SASL Mechanism November 2001 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 May 10, 2002 [Page 16] Internet-Draft The SM2 SASL Mechanism November 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 May 10, 2002 [Page 17] Internet-Draft The SM2 SASL Mechanism November 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 May 10, 2002 [Page 18] Internet-Draft The SM2 SASL Mechanism November 2001 9. Acknowledgements The following people provided valuable feedback in the preparation of this document Keith Burdis Taylor & Naffah Expires May 10, 2002 [Page 19] Internet-Draft The SM2 SASL Mechanism November 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", November 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 May 10, 2002 [Page 20] Internet-Draft The SM2 SASL Mechanism November 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 May 10, 2002 [Page 21] Internet-Draft The SM2 SASL Mechanism November 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 May 10, 2002 [Page 22] Internet-Draft The SM2 SASL Mechanism November 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 May 10, 2002 [Page 23] Internet-Draft The SM2 SASL Mechanism November 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 May 10, 2002 [Page 24] Internet-Draft The SM2 SASL Mechanism November 2001 Appendix B. Changes since last draft Changed SHOULD to MUST in Section 4.6. Added the Unsigned Integer type in Section 4. Added TTL indication in protocol exchange. Updated the examples to use the new SASL-SRP draft. Updated the references. Taylor & Naffah Expires May 10, 2002 [Page 25] Internet-Draft The SM2 SASL Mechanism November 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 May 10, 2002 [Page 26]