CAT Working Group K.R. Burdis Internet Draft Rhodes University Expires: March 2000 September 1999 draft-burdis-cat-srp-sasl-01.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 integrity 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]. 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 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. Burdis [Page 1]
draft-burdis-cat-srp-sasl-01.txt September 1999 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. 3 Protocol Description This mechanism is based on the SRP-SHA1 protocol described in [SRP- DRAFT]. Additionally optimised SRP as described in [SRP] is used. It 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 mutual authentication and integrity protection should take place. Client Server <-- N, g -- -- c,A --> <-- s,B -- -- M1,o,m --> <-- M2 -- 3.1 Server sends N and g The prime modulus (N) is encoded as a netstring. The generator (g) is encoded as a netstring. These two netstrings are appended and this string is encoded as a netstring. The resulting string 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: Burdis [Page 2]
draft-burdis-cat-srp-sasl-01.txt September 1999 g = <02> N encoded as a netstring is: 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>, g encoded as a netstring is: 1:<02>, The final string is: 137: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>,, 3.2 Client sends request The client's username (c) is encoded as a netstring. The client generates its ephemeral public key (A) and this is encoded as a netstring. These two netstrings are appended and this string is encoded as a netstring. The resulting string is sent to the server. 3.3 Server sends response The client's salt (s) is encoded as a netstring. The server generates its ephemeral public key (B) and this is encoded as a netstring. These two netstrings are appended and this string is encoded as a netstring. The resulting string is sent to the client. 3.4 Client sends evidence The client calculates the shared context key (k). The client calculates the evidence that proves to the server that it knows the shared context key. This evidence (M1) is encoded as a netstring. The client creates an 8-bit bit-string that specifies the options that it requests. If bit 0 is set then the client requests mutual authentication. If bit 1 is set then the client requests integrity protection. The other bits are reserved for future use. This options Burdis [Page 3]
draft-burdis-cat-srp-sasl-01.txt September 1999 byte (o) is encoded as a netstring. The client calculates a message authentication code (MAC) over the options byte netstring. The HMAC-SHA1 algorithm [HMAC] is used, with the shared context key (k) as the input key. The MAC (m) is encoded as a netstring. These three netstrings are appended together and this string is encoded as a netstring. The resulting string is sent to the client. 3.5 Server sends evidence The server calculates the shared context key (k). If the client requested mutual authentication then the server calculates the evidence (M2) that proves to the client that it knows the shared context key. This evidence is encoded as a netstring and sent to the client. (Note that section 5.2 of [SASL] "Server returns success with additional data" applies here.) 4 Security Layer The security layer provides integrity protection using the HMAC-SHA1 [HMAC] algorithm. The shared context key (k) is used as the input key. The encoding and decoding of message data is described below. 4.1 Encoding The message data is encoded as a netstring. A MAC is computed using the shared context key and the unencoded message data. The MAC is then encoded as a netstring. These two netstrings are appended and the string is encoded as a netstring. The resulting string is sent to the other party. 4.2 Decoding The message data is interpreted as a netstring. This string is then interpreted as two netstrings. The first netstring interpretation is the received message data. The second netstring interpretation is the received message authentication code (MAC). A message authentication code is computed using the shared context key and the received message data. This MAC is compared with the received MAC. If the MACs do not match then that indicates that the message has been tampered with and the message should be discarded, and the other party informed. 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 Burdis [Page 4]
draft-burdis-cat-srp-sasl-01.txt September 1999 respectively. S: +OK POP3 server ready C: AUTH SRP S: + nCpSwCJ8uEeZgn5DbQmxCAgmb6ftsJxkqrKCSJqGJSywlUZCwIlxA9XJwj2fV xs01hN85kTq8AnlVkW4U5Po5ZA3ZkLk5B7W9gd1e3KW55cvNpwWmCOcZWmd8dC1MMq SzBp b3s0CMbvUQuOqGXWXZNi/oBr9CdyMvY.7zakYxeUZsZSj2ZchpB34w0Ymi C: CJGrEZKwQsLfT6WiCJ8uEYcuV8oVukbK4jbGFmK/WjzLwAEMu3cDN/lccHr6uET 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 authentication successful 6. Discussion Although the SHA-1 hash function is used in this mechanism, it could be replaced with with any iterative cryptographic hash function [HMAC]. It was decided not to provide support for confidentiality protection. Such support usually requires the negotiation of a suitable cryptographic algorithm and it is felt that such negotiation would make the protocol uncessarily complex. It is suggested that those who need a mechanism with this funtionality use one of the GSS-API based mechanisms. Avoiding confidentiality protection also has benefits in that it may allow use of this mechanism in countries that have strict controls on the use of cryptography. It is felt that a simple SASL mechanism that provides authentication and integrity protection will be useful. 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. Please see section 4 "Security Considerations" of [SRP-DRAFT] and section 4 "Security analysis" of [SRP]. This mechanism also relies on the security of the HMAC algorithm and the underlying hash function. Section 6 "Security" of [HMAC] discusses these security issues in detail. The options byte that is used by the client to possibly request mutual authentication and integrity protection could be modified by an attacker before reaching the server. For this reason a MAC, generated using HMAC-SHA1 and the shared context key, is used to insure the server of its integrity. Burdis [Page 5]
draft-burdis-cat-srp-sasl-01.txt September 1999 8. Author's Address Keith Burdis Computer Science Department Rhodes University 6139 Grahamstown Email: cskb@cs.ru.ac.za 9. References [Netstring] Bernstein, Daniel J, "Netstrings", URL: ftp://koobera.math.uic.edu/www/proto/netstrings.txt [HMAC] Krawczyk, Hugo et.al. "HMAC: Keyed-Hashing for Message Authentication", Internet RFC 2104 [POP3 AUTH] Myers, John G, "POP3 AUTHentication command", Internet RFC 1734 [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 6]