Network Group K.R. Burdis Internet Draft Rhodes University Expires: July 2000 January 2000 draft-burdis-cat-srp-sasl-02.txt Secure Remote Password SASL Mechanism 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 an SASL mechanism based on the Secure Remote Password protocol. This mechanism allows a client to be authenticated to a server, and optionally the server authenticated to the client. Additionally a security layer providing replay detection, integrity protection and/or confidentiality protection can be provided. 1 Conventions Used in this Document In this document, a string of 8-bit bytes may be written in two different forms: as a series of hexadecimal numbers between angle brackets, or as a sequence of ASCII characters between double quotes. For example, <68 65 6c 6c 6f 20 77 6f 72 6c 64 21> is a string of length 12; it is the same as the string "hello world!" [Netstring]. All data is encoded and sent in network byte order (big-endian). 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]. 2 Netstrings This mechanism makes extensive use of netstrings, which are described in more detail in [Netstring]: A netstring is a self-delimiting encoding of a string. Netstrings Burdis [Page 1]
draft-burdis-cat-srp-sasl-02.txt January 2000 are very easy to generate and to parse. Any string may be encoded as a netstring; there are no restrictions on length or on allowed bytes. Another virtue of a netstring is that it declares the string size up front. Thus an application can check in advance whether it has enough space to store the entire string. Any string of 8-bit bytes may be encoded as {len}":"{string}",". Here {string} is the string and {len} is a nonempty sequence of ASCII digits giving the length of {string} in decimal. The ASCII digits are <30> for 0, <31> for 1, and so on up through <39> for 9. Extra zeros at the front of {len} are prohibited: {len} begins with <30> exactly when {string} is empty. For example, the string "hello world!" is encoded as <31 32 3a 68 65 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "12:hello world!,". The empty string is encoded as "0:,". {len}":"{string}"," is called a netstring. {string} is called the interpretation of the netstring. Note that {string} may itself be a netstring. 3 Protocol Description The mechanism name associated with this protocol is "SRP-SASL". SRP is a password-based zero-knowledge authentication and key- exchange protocol developed by Thomas Wu. It has good performance, is not plaintext-equivalent and maintains perfect forward secrecy. It provides authentication (optionally mutual authentication) and the negotiation of a session key [SRP]. This mechanism is based on the optimised SRP-SHA1 protocol described at the end of section 3 in [SRP-DRAFT], since this reduces the total number of messages exchanged by grouping together pieces of information that do not depend on earlier messages. Due to the design of the mechanism, mutual authentication is MANDATORY. This document describes how the SRP-SHA1 data is encoded for transmission between the client and server, and it adds extra control information to enable the client to request whether or not replay detection, integrity protection and/or confidentiality protection should be provided by a security layer. Mechanism data exchanges are shown below: Client Server <-- N,g,Z -- -- U,A,o --> <-- s,B -- Burdis [Page 2]
draft-burdis-cat-srp-sasl-02.txt January 2000 -- M1 --> M1 = H(H(N) XOR H(g) | H(U) | s | Z | A | B | K) <-- M2 -- M2 = H(U | A | o | M1 | K) where: | is the concatenation operator H is the SHA-1 one-way function N is the prime modulus g is the generator Z is the options byte indicating which of the security services the server can provide U is the client's username A is the client's ephemeral public key o is the options byte indicating requested security services s is the client's password salt B is the server's ephemeral public key M1 is the client's evidence that the shared key is known M2 is the server's evidence that the shared key is known 3.1 Server sends N, g and Z The prime modulus (N) is encoded as a netstring (ns1). The generator (g) is encoded as a netstring (ns2). The server creates an 8-bit bit-string, most significant bit first, that specifies the security service options that it supports. * Bit 0 must be set indicating that the server suports integrity protection using the HMAC-MD5 algorithm [HMAC], support for which is MANDATORY. * If bit 1 is set then the server supports replay detection using sequence numbers. * If bit 2 is set then the server supports confidentiality protection using the Blowfish cipher in CBC mode [Blowfish]. The other bits are reserved for future use. This options byte (Z) is Burdis [Page 3]
draft-burdis-cat-srp-sasl-02.txt January 2000 encoded as a netstring (ns3). These three netstrings (ns1, ns2 and ns3) are concatenated and this string is encoded as a netstring (ns4). The resulting string (ns4) is sent to the client. For example if: N = <88 EA C4 53 65 6B 0E CC 2A AC 25 1A 9D F6 4F BB B4 D5 43 1C 4F 44 13 73 CE AF 7A 33 3A 4A FE CA 26 14 FA B4 2A 5F EF 60 01 AD 72 05 B9 DD 08 2B 1B DF BA 01 1E 15 9C 85 8C A0 E3 B9 5B 85 2C 78 09 AA 70 68 0D 48 05 16 6E 57 CF A8 30 31 89 A3 83 09 C8 9C C0 56 5B 47 3D 2F 39 43 D8 03 16 97 97 9A E1 8D 10 86 08 63 5E CF F2 2F 52 4C 9F C5 B9 8B E1 FD 92 E8 BB A1 E8 F6 8D CB 42 8E 6A F3> and: g = <02> and: Z = <07> N encoded as a netstring is: <31 32 38 3A 88 EA C4 53 65 6B 0E CC 2A AC 25 1A 9D F6 4F BB B4 D5 43 1C 4F 44 13 73 CE AF 7A 33 3A 4A FE CA 26 14 FA B4 2A 5F EF 60 01 AD 72 05 B9 DD 08 2B 1B DF BA 01 1E 15 9C 85 8C A0 E3 B9 5B 85 2C 78 09 AA 70 68 0D 48 05 16 6E 57 CF A8 30 31 89 A3 83 09 C8 9C C0 56 5B 47 3D 2F 39 43 D8 03 16 97 97 9A E1 8D 10 86 08 63 5E CF F2 2F 52 4C 9F C5 B9 8B E1 FD 92 E8 BB A1 E8 F6 8D CB 42 8E 6A F3 2C> g encoded as a netstring is: "1:<02>," or <31 3A 02 2C> Z encoded as a netstring is: "1:<07>," or <31 3A 07 2C> The final string is: "141:128:<88 EA C4 53 65 6B 0E CC 2A AC 25 1A 9D F6 4F BB B4 D5 43 1C 4F 44 13 73 CE AF 7A 33 3A 4A FE CA 26 14 FA B4 2A 5F EF 60 01 AD 72 05 B9 DD 08 2B 1B DF BA 01 1E 15 9C 85 8C A0 E3 B9 5B 85 2C 78 09 AA 70 68 0D 48 05 16 6E 57 CF A8 30 31 89 A3 83 09 C8 9C C0 56 5B 47 3D 2F 39 43 D8 03 16 97 97 9A E1 8D 10 86 08 63 5E CF F2 2F 52 4C 9F C5 B9 8B E1 FD 92 E8 BB A1 E8 F6 8D CB 42 8E 6A F3>,1:<02>,1:<07>,," Burdis [Page 4]
draft-burdis-cat-srp-sasl-02.txt January 2000 or <31 34 31 3A 31 32 38 3A 88 EA C4 53 65 6B 0E CC 2A AC 25 1A 9D F6 4F BB B4 D5 43 1C 4F 44 13 73 CE AF 7A 33 3A 4A FE CA 26 14 FA B4 2A 5F EF 60 01 AD 72 05 B9 DD 08 2B 1B DF BA 01 1E 15 9C 85 8C A0 E3 B9 5B 85 2C 78 09 AA 70 68 0D 48 05 16 6E 57 CF A8 30 31 89 A3 83 09 C8 9C C0 56 5B 47 3D 2F 39 43 D8 03 16 97 97 9A E1 8D 10 86 08 63 5E CF F2 2F 52 4C 9F C5 B9 8B E1 FD 92 E8 BB A1 E8 F6 8D CB 42 8E 6A F3 2C 31 3A 02 2C 31 3A 07 2C 2C> 3.2 Client sends request The client's username (U) is encoded as a netstring (ns1). The client generates its ephemeral public key (A) and this is encoded as a netstring (ns2). The client creates an 8-bit bit-string, most significant bit first, that specifies the security service options that it requests. (The client can only select security services that the server has indicated it can provide). * If bit 0 is set then the client requests integrity protection using the HMAC-MD5 algorithm [HMAC]. * If bit 1 is set then the client requests replay detection using sequence numbers. (Note that bit 0 must be set if this bit is set). * If bit 2 is set then the client requests confidentiality protection using the Blowfish cipher in CBC mode [Blowfish]. The other bits are reserved for future use. This options byte (o) is encoded as a netstring (ns2). These three netstrings (ns1, ns2 and ns3) are concatenated and this string is encoded as a netstring (ns4). The resulting string (ns4) is sent to the server. 3.3 Server sends response The server calculates the shared context key (K). The client's salt (s) is encoded as a netstring (ns1). The server generates its ephemeral public key (B) and this is encoded as a netstring (ns2). These two netstrings (ns1 and ns2) are concatenated and this string is encoded as a netstring (ns3). The resulting string (ns3) is sent to the server. 3.4 Client sends evidence Burdis [Page 5]
draft-burdis-cat-srp-sasl-02.txt January 2000 The client calculates the shared context key (K). The client calculates the evidence (M1) that proves to the server that it knows the shared context key (K), including N, g, s, Z, A and B as part of the calculation. M1 = H(H(N) XOR H(g) | H(U) | s | Z | A | B | K) This evidence (M1) is encoded as a netstring (ns1) and sent to the server. 3.5 Server sends evidence The client calculates the evidence (M2) that proves to the client that it knows the shared context key (K), including U, A and o as part of the calculation. M2 = H(U | A | o | M1 | K) This evidence (M2) is encoded as a netstring (ns1) and sent to the client. 4 Security Layer Depending on the options specified by the initiator, the security layer may provide integrity protection, replay detection, and/or confidentiality protection. Messages are encoded as follows: * If neither integrity nor confidentiality protection is requested then the message is sent unchanged to the other party. * if just confidentiality protection is requested then the message data is encrypted using the chosen confidentiality algorithm (ie. Blowfish). The encrypted message is encoded as a netstring and sent to the other party. * if just integrity protection is requested then the integrity checksum is calculated on the message data as described in section 4.1 * if both integrity protection and confidentiality protection are requested then the message data is first encrypted using the chosen confidentiality algorithm (ie. Blowfish). Thereafter the integrity checksum is calculated on the encrypted message data as described in section 4.1 * if replay detection is requested then the sequence number included in the integrity checksum is incremented after each message is sent, starting at zero, otherwise the sequence number is always zero 4.1 Integrity Protection Integrity protection may be provided using the HMAC-MD5 [HMAC] Burdis [Page 6]
draft-burdis-cat-srp-sasl-02.txt January 2000 algorithm. The shared context key (K) is used as the input key. The encoding and decoding of message data is described below. 4.1.1 Encoding The (possibly encrypted) message data is encoded as a netstring (ns1). The sequence number is encoded as a netstring (ns2). These two netstrings (ns1 and ns2) are concatenated and encoded as a netstring (ns3). A MAC is computed using the shared context key and ns3. The MAC is then encoded as a netstring (ns4). ns3 and ns4 are concatenated and this string is encoded as a netstring (ns5). ns5 is sent to the other party. 4.1.2 Decoding The message data is interpreted as a netstring. This string is the concatenation of two netstrings (ns3 and ns4). ns3 contains the concatenation of the received (possibly encrypted) message data netstring (ns1) and the sequence number netstring (ns2). The interpretation of ns4 is the received message authentication code (MAC). The receiver computes a message authentication code using HMAC-MD5, the shared context key and ns3. This MAC is compared with the received MAC. If the MACs do not match then that indicates that the message has been tampered with, the message should be discarded, and the other party informed. If replay detection was requested then the receiver interprets ns2, checks that the sequence number is what it expects it to be, and rejects the message if it is not. The interpretation of ns3 is the (possibly encrypted) original message. If the message is encrypted it should be decrypted using the chosen confidentiality algorithm (ie. Blowfish) and the session key (K). 5 Example The example below uses POP authentication [POP3 AUTH]. The base64 encoding of challenges and responses, as well as the "+ " preceding the responses are part of the [POP3 AUTH] specification, not part of this SASL mechanism itself. "C:" and "S:" indicate lines sent by the client and server respectively. S: +OK POP3 server ready C: AUTH SRP-SASL S: + nCpSwCJ8uEeZgn5DbQmxCAgmb6ftsJxkqrKCSJqGJSywlUZCwIlxA9XJwj2fV xs01hN85kTq8AnlVkW4U5Po5ZA3ZkLk5B7W9gd1e3KW55cvNpwWmCOcZWmd8dC1MMq SzBp b3s0CMbvUQuOqGXWXZNi/oBr9CdyMvY.7zakYxeUZsZSj2ZchpB34w0Ymi C: CJGrEZKwQsLfT6WiCJ8uEYcuV8oVukbK4jbGFmK/WjzLwAEMu3cDN/lccHr6uET Burdis [Page 7]
draft-burdis-cat-srp-sasl-02.txt January 2000 atd6MihIY5Gvr2YNAiXVic0Ot92MdwNBK64Qk0ouQ88VNsCkNedFfY9XN4tmJgt43L NLN4e/xj6vGTHemh3tp.5qeP5USy/MJ9/qLc/mOyJNAq3.XAUaEjRJRTxmAQOlmB 34w0Imi S: + 34qDpenC3eibawB5vqHzM.FB34oE3erYpK/70WbK/9gj3pdaUH3O2d2jHcuHz jaTJCFKHUtOmy9GGKooFMPHCE0xTRHH0uP936Kea7kBx7/STQvpjHQ3UzIPk1Gf9Rl MXMYzuzpJM2dvYV0Lfjko4/DDNNj6S1of2v7XlnoXElqCvQxL3O8LTpjfolhjR1SCD j50YYvEImi C: CZ0wiVpgmEU96.PIMKx1PS8wRUb0m8Wi S: + CZ0wN8a1KmQXLlbsd3Q8obkMu7wgAmqi C: S: +OK SRP-SASL authentication successful 6. Discussion Although the MD5 and SHA-1 hash functions are used in this mechanism, they could be replaced with any iterative cryptographic hash function [HMAC]. The specified algorithms were chosen for utility and availablity. The HMAC-MD5 algorithm was chosen as an integrity algorithm because it is faster than both HMAC-SHA1 and MAC algorithms based on secret key encryption algorithms [LIPKEY]. Blowfish was chosen as a cipher 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 Other algorithms that are identified as useful may be specified at a later stage. Since confidentiality protection is optional this mechanism should be usable in countries that have strict controls on the use of cryptography. 7. Security Considerations 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. Weaknesses found in MD5 do not impact HMAC-MD5 [Dobbertin]. The Blowfish cipher has undergone cryptanalysis for a long period of time and no weaknesses have been found [Blowfish]. Burdis [Page 8]
draft-burdis-cat-srp-sasl-02.txt January 2000 U, A and o sent from the client to the server, and N, g, Z, s and B sent from the server to the client could be modified by an attacker before reaching the other party. For this reason, these values are included in the respective calculations of evidence to prove that each party knows the session key. This allows each party to verify that these values were received unmodified. The use of integrity protection is RECOMMENDED to detect message tampering and to avoid session hijacking after authentication has taken place. Replay attacks may be avoided through the use of sequence numbers, because sequence numbers make each integrity protected message exchanged during a session different, and each session uses a different key. Acknowledgements Thanks to Raif S. Naffah <raif@forge.com.au> for corrections and helpful suggestions. Author's Address Keith Burdis Computer Science Department Rhodes University 6139 Grahamstown South Africa Email: cskb@cs.ru.ac.za References [Blowfish] Schneier, Bruce, "The Blowfish Encryption Algorithm", URL: http://www.counterpane.com/blowfish.html [Dobbertin] Dobbertin, Hans, "The Status of MD5 After a Recent Attack", CryptoBytes, RSA Laboratories, URL: ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf [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 [LIPKEY] Eisler, Mike, "LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM", Internet Draft, draft-ietf-cat-lipkey-03.txt [Netstring] Bernstein, Daniel J, "Netstrings", URL: ftp://koobera.math.uic.edu/www/proto/netstrings.txt [POP3 AUTH] Myers, John G, "POP3 AUTHentication command", Internet RFC 1734 Burdis [Page 9]
draft-burdis-cat-srp-sasl-02.txt January 2000 [SASL] Myers, John G, "Simple Authentication and Security Layer (SASL)", Internet RFC 2222 [SRP-DRAFT] Wu, Thomas, "The SRP Authentication and Key Exchange System", Internet Draft, draft-wu-srp-auth-03.txt [SRP] Wu, Thomas, "The Secure Remote Password Protocol", 1998 Internet Society Symposium on Network and Distributed Security Burdis [Page 10]