idnits 2.17.1 draft-burdis-cat-srp-sasl-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 1) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1999) is 9020 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'Netstring' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 1734 (ref. 'POP3 AUTH') (Obsoleted by RFC 5034) ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) -- Possible downref: Non-RFC (?) normative reference: ref. 'SRP' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K.R. Burdis 2 Internet Draft Rhodes University 3 Expires: March 1999 August 1999 4 draft-burdis-cat-srp-sasl-00.txt 6 Secure Remote Password SASL Mechanism 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes an SASL mechanism based on the Secure Remote 32 Password protocol. This mechanism allows a client to be authenticated 33 to a server, and optionally the server authenticated to the client. 34 Additionally a security layer providing integrity protection can be 35 provided. 37 1 Conventions Used in this Document 39 In this document, a string of 8-bit bytes may be written in two 40 different forms: as a series of hexadecimal numbers between angle 41 brackets, or as a sequence of ASCII characters between double quotes. 42 For example, <68 65 6c 6c 6f 20 77 6f 72 6c 64 21> is a string of 43 length 12; it is the same as the string "hello world!" [Netstring]. 45 2 Netstrings 47 This mechanism makes extensive use of netstrings, which are described 48 in more detail in [Netstring]. 50 A netstring is a self-delimiting encoding of a string. Netstrings are 51 very easy to generate and to parse. Any string may be encoded as a 52 netstring; there are no restrictions on length or on allowed bytes. 53 Another virtue of a netstring is that it declares the string size up 54 front. Thus an application can check in advance whether it has enough 55 space to store the entire string. 57 Any string of 8-bit bytes may be encoded as {len}":"{string}",". Here 58 {string} is the string and {len} is a nonempty sequence of ASCII 59 digits giving the length of {string} in decimal. The ASCII digits are 60 <30> for 0, <31> for 1, and so on up through <39> for 9. Extra zeros 61 at the front of {len} are prohibited: {len} begins with <30> exactly 62 when {string} is empty. 64 For example, the string "hello world!" is encoded as <31 32 3a 68 65 65 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "12:hello world!,". The 66 empty string is encoded as "0:,". 68 {len}":"{string}"," is called a netstring. {string] is called the 69 interpretation of the netstring [Netstring]. 71 3 Protocol Description 73 This mechanism is based on the SRP-SHA1 protocol described in [SRP- 74 DRAFT]. Additionally optimised SRP as described in [SRP] is used. 75 It describes how the SRP-SHA1 data is encoded for transmission 76 between the client and server, and it adds extra control information 77 to enable the client to request whether or not mutual authentication 78 and integrity protection should take place. 80 Client Server 82 <-- N, g -- 84 -- c,A --> 86 <-- s,B -- 88 -- M1,o,m --> 90 <-- M2 -- 92 3.1 Server sends N and g 94 The prime modulus (N) is encoded as a netstring. The generator (g) is 95 encoded as a netstring. These two netstrings are appended and this 96 string is encoded as a netstring. The resulting string is sent to the 97 client. 99 For example if: 101 N = <88 EA C4 53 65 6B 0E CC 2A AC 25 1A 9D F6 4F BB 102 B4 D5 43 1C 4F 44 13 73 CE AF 7A 33 3A 4A FE CA 103 26 14 FA B4 2A 5F EF 60 01 AD 72 05 B9 DD 08 2B 104 1B DF BA 01 1E 15 9C 85 8C A0 E3 B9 5B 85 2C 78 105 09 AA 70 68 0D 48 05 16 6E 57 CF A8 30 31 89 A3 106 83 09 C8 9C C0 56 5B 47 3D 2F 39 43 D8 03 16 97 107 97 9A E1 8D 10 86 08 63 5E CF F2 2F 52 4C 9F C5 108 B9 8B E1 FD 92 E8 BB A1 E8 F6 8D CB 42 8E 6A F3> 110 and: 112 g = <02> 114 N encoded as a netstring is: 116 128:<88 EA C4 53 65 6B 0E CC 2A AC 25 1A 9D F6 4F BB 117 B4 D5 43 1C 4F 44 13 73 CE AF 7A 33 3A 4A FE CA 26 14 118 FA B4 2A 5F EF 60 01 AD 72 05 B9 DD 08 2B 1B DF BA 01 119 1E 15 9C 85 8C A0 E3 B9 5B 85 2C 78 09 AA 70 68 0D 48 120 05 16 6E 57 CF A8 30 31 89 A3 83 09 C8 9C C0 56 5B 47 121 3D 2F 39 43 D8 03 16 97 97 9A E1 8D 10 86 08 63 5E CF 122 F2 2F 52 4C 9F C5 B9 8B E1 FD 92 E8 BB A1 E8 F6 8D CB 123 42 8E 6A F3>, 125 g encoded as a netstring is: 127 1:<02>, 129 The final string is: 131 137:128:<88 EA C4 53 65 6B 0E CC 2A AC 25 1A 9D F6 4F 132 BB B4 D5 43 1C 4F 44 13 73 CE AF 7A 33 3A 4A FE CA 26 133 14 FA B4 2A 5F EF 60 01 AD 72 05 B9 DD 08 2B 1B DF BA 134 01 1E 15 9C 85 8C A0 E3 B9 5B 85 2C 78 09 AA 70 68 0D 135 48 05 16 6E 57 CF A8 30 31 89 A3 83 09 C8 9C C0 56 5B 136 47 3D 2F 39 43 D8 03 16 97 97 9A E1 8D 10 86 08 63 5E 137 CF F2 2F 52 4C 9F C5 B9 8B E1 FD 92 E8 BB A1 E8 F6 8D 138 CB 42 8E 6A F3>,1:<02>,, 140 3.2 Client sends request 142 The client's username (c) is encoded as a netstring. The client 143 generates its ephemeral public key (A) and this is encoded as a 144 netstring. These two netstrings are appended and this string is 145 encoded as a netstring. The resulting string is sent to the server. 147 3.3 Server sends response 149 The client's salt (s) is encoded as a netstring. The server generates 150 its ephemeral public key (B) and this is encoded as a netstring. 151 These two netstrings are appended and this string is encoded as a 152 netstring. The resulting string is sent to the client. 154 3.4 Client sends evidence 156 The client calculates the shared context key (k). 158 The client calculates the evidence that proves to the server that it 159 knows the shared context key. This evidence (M1) is encoded as a 160 netstring. 162 The client creates an 8-bit bit-string that specifies the options 163 that it requests. If bit 0 is set then the client requests mutual 164 authentication. If bit 1 is set then the client requests integrity 165 protection. The other bits are reserved for future use. This options 166 byte (o) is encoded as a netstring. 168 The client calculates a message authentication code (MAC) over the 169 options byte netstring. The HMAC-SHA1 algorithm [HMAC] is used, with 170 the shared context key (k) as the input key. The MAC (m) is encoded 171 as a netstring. 173 These three netstrings are appended together and this string is 174 encoded as a netstring. The resulting string is sent to the client. 176 3.5 Server sends evidence 178 The server calculates the shared context key (k). 180 If the client requested mutual authentication then the server 181 calculates the evidence (M2) that proves to the client that it knows 182 the shared context key. This evidence is encoded as a netstring and 183 sent to the client. (Note that section 5.2 of [SASL] "Server returns 184 success with additional data" applies here.) 186 4 Security Layer 188 The security layer provides integrity protection using the HMAC-SHA1 189 [HMAC] algorithm. The shared context key (k) is used as the input 190 key. The encoding and decoding of message data is described below. 192 4.1 Encoding 194 The message data is encoded as a netstring. A MAC is computed using 195 the shared context key and the unencoded message data. The MAC is 196 then encoded as a netstring. These two netstrings are appended and 197 the string is encoded as a netstring. The resulting string is sent to 198 the other party. 200 4.2 Decoding 202 The message data is interpreted as a netstring. This string is then 203 interpreted as two netstrings. The first netstring interpretation is 204 the received message data. The second netstring interpretation is the 205 received message authentication code (MAC). A message authentication 206 code is computed using the shared context key and the received 207 message data. This MAC is compared with the received MAC. If the MACs 208 do not match then that indicates that the message has been tampered 209 with and the message should be discarded, and the other party 210 informed. 212 5 Example 214 The example below uses POP authentication [POP3 AUTH]. The base64 215 encoding of challenges and responses, as well as the "+ " preceding 216 the responses are part of the [POP3 AUTH] specification, not part of 217 this SASL mechanism itself. 219 "C:" and "S:" indicate lines sent by the client and server 220 respectively. 222 S: +OK POP3 server ready 223 C: AUTH SRP 224 S: + nCpSwCJ8uEeZgn5DbQmxCAgmb6ftsJxkqrKCSJqGJSywlUZCwIlxA9XJwj2fV 225 xs01hN85kTq8AnlVkW4U5Po5ZA3ZkLk5B7W9gd1e3KW55cvNpwWmCOcZWmd8dC1MMq 226 SzBp b3s0CMbvUQuOqGXWXZNi/oBr9CdyMvY.7zakYxeUZsZSj2ZchpB34w0Ymi 227 C: CJGrEZKwQsLfT6WiCJ8uEYcuV8oVukbK4jbGFmK/WjzLwAEMu3cDN/lccHr6uET 228 atd6MihIY5Gvr2YNAiXVic0Ot92MdwNBK64Qk0ouQ88VNsCkNedFfY9XN4tmJgt43L 229 NLN4e/xj6vGTHemh3tp.5qeP5USy/MJ9/qLc/mOyJNAq3.XAUaEjRJRTxmAQOlmB 230 34w0Imi 231 S: + 34qDpenC3eibawB5vqHzM.FB34oE3erYpK/70WbK/9gj3pdaUH3O2d2jHcuHz 232 jaTJCFKHUtOmy9GGKooFMPHCE0xTRHH0uP936Kea7kBx7/STQvpjHQ3UzIPk1Gf9Rl 233 MXMYzuzpJM2dvYV0Lfjko4/DDNNj6S1of2v7XlnoXElqCvQxL3O8LTpjfolhjR1SCD 234 j50YYvEImi 235 C: CZ0wiVpgmEU96.PIMKx1PS8wRUb0m8Wi 236 S: + CZ0wN8a1KmQXLlbsd3Q8obkMu7wgAmqi 237 C: 238 S: +OK SRP authentication successful 240 Security Considerations 242 This mechanism relies on the security of SRP, which is believed to be 243 extremely secure. Please see section 4 "Security Considerations" of 244 [SRP-DRAFT] and section 4 "Security analysis" of [SRP]. 246 The options byte that is used by the client to possibly request 247 mutual authentication and integrity protection could be modified by 248 an attacker before reaching the server. For this reason a MAC 249 generated using HMAC-SHA1 and the shared context key is used to 250 insure the server of its integrity. 252 6. Author's Address 254 Keith Burdis 255 Computer Science Department 256 Rhodes University 257 6139 Grahamstown 259 Email: cskb@cs.ru.ac.za 261 7. References 263 [Netstring] Bernstein, Daniel J, "Netstrings", URL: 264 ftp://koobera.math.uic.edu/www/proto/netstrings.txt 266 [HMAC] Krawczyk, Hugo et.al. "HMAC: Keyed-Hashing for Message 267 Authentication", Internet RFC 2104 269 [POP3 AUTH] Myers, John G, "POP3 AUTHentication command", 270 Internet RFC 1734 272 [SASL] Myers, John G, "Simple Authentication and Security Layer 273 (SASL)", Internet RFC 2222 275 [SRP-DRAFT] Wu, Thomas, "The SRP Authentication and Key Exchange 276 System", Internet Draft, draft-wu-srp-auth-03.txt 278 [SRP] Wu, Thomas, "The Secure Remote Password Protocol", 1998 Internet 279 Society Symposium on Network and Distributed Security