idnits 2.17.1 draft-burdis-cat-srp-sasl-02.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: ---------------------------------------------------------------------------- ** 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 10 longer pages, the longest (page 2) being 61 lines 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 are 2 instances 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 (January 2000) is 8868 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) == Unused Reference: 'SASL' is defined on line 489, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Blowfish' -- Possible downref: Non-RFC (?) normative reference: ref. 'Dobbertin' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') -- Unexpected draft version: The latest known version of draft-ietf-cat-lipkey is -02, but you're referring to -03. -- Possible downref: Non-RFC (?) normative reference: ref. 'Netstring' ** 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: 9 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Group K.R. Burdis 2 Internet Draft Rhodes University 3 Expires: July 2000 January 2000 4 draft-burdis-cat-srp-sasl-02.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 replay detection, integrity 35 protection and/or confidentiality protection can be 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]. 44 All data is encoded and sent in network byte order (big-endian). 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 50 2 Netstrings 52 This mechanism makes extensive use of netstrings, which are described 53 in more detail in [Netstring]: 55 A netstring is a self-delimiting encoding of a string. Netstrings 56 are very easy to generate and to parse. Any string may be encoded 57 as a netstring; there are no restrictions on length or on allowed 58 bytes. Another virtue of a netstring is that it declares the 59 string size up front. Thus an application can check in advance 60 whether it has enough space to store the entire string. 62 Any string of 8-bit bytes may be encoded as {len}":"{string}",". 63 Here {string} is the string and {len} is a nonempty sequence of 64 ASCII digits giving the length of {string} in decimal. The ASCII 65 digits are <30> for 0, <31> for 1, and so on up through <39> for 66 9. Extra zeros at the front of {len} are prohibited: {len} begins 67 with <30> exactly when {string} is empty. 69 For example, the string "hello world!" is encoded as <31 32 3a 68 70 65 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "12:hello world!,". 71 The empty string is encoded as "0:,". 73 {len}":"{string}"," is called a netstring. {string} is called the 74 interpretation of the netstring. 76 Note that {string} may itself be a netstring. 78 3 Protocol Description 80 The mechanism name associated with this protocol is "SRP-SASL". 82 SRP is a password-based zero-knowledge authentication and key- 83 exchange protocol developed by Thomas Wu. It has good performance, is 84 not plaintext-equivalent and maintains perfect forward secrecy. It 85 provides authentication (optionally mutual authentication) and the 86 negotiation of a session key [SRP]. 88 This mechanism is based on the optimised SRP-SHA1 protocol described 89 at the end of section 3 in [SRP-DRAFT], since this reduces the total 90 number of messages exchanged by grouping together pieces of 91 information that do not depend on earlier messages. Due to the design 92 of the mechanism, mutual authentication is MANDATORY. 94 This document describes how the SRP-SHA1 data is encoded for 95 transmission between the client and server, and it adds extra control 96 information to enable the client to request whether or not replay 97 detection, integrity protection and/or confidentiality protection 98 should be provided by a security layer. 100 Mechanism data exchanges are shown below: 102 Client Server 104 <-- N,g,Z -- 106 -- U,A,o --> 108 <-- s,B -- 109 -- M1 --> 111 M1 = H(H(N) XOR H(g) | H(U) | s | Z | A | B | K) 113 <-- M2 -- 115 M2 = H(U | A | o | M1 | K) 117 where: 119 | is the concatenation operator 121 H is the SHA-1 one-way function 123 N is the prime modulus 125 g is the generator 127 Z is the options byte indicating which of the security services the 128 server can provide 130 U is the client's username 132 A is the client's ephemeral public key 134 o is the options byte indicating requested security services 136 s is the client's password salt 138 B is the server's ephemeral public key 140 M1 is the client's evidence that the shared key is known 142 M2 is the server's evidence that the shared key is known 144 3.1 Server sends N, g and Z 146 The prime modulus (N) is encoded as a netstring (ns1). The generator 147 (g) is encoded as a netstring (ns2). 149 The server creates an 8-bit bit-string, most significant bit first, 150 that specifies the security service options that it supports. 152 * Bit 0 must be set indicating that the server suports integrity 153 protection using the HMAC-MD5 algorithm [HMAC], support for which 154 is MANDATORY. 156 * If bit 1 is set then the server supports replay detection using 157 sequence numbers. 159 * If bit 2 is set then the server supports confidentiality 160 protection using the Blowfish cipher in CBC mode [Blowfish]. 162 The other bits are reserved for future use. This options byte (Z) is 163 encoded as a netstring (ns3). 165 These three netstrings (ns1, ns2 and ns3) are concatenated and this 166 string is encoded as a netstring (ns4). The resulting string (ns4) is 167 sent to the client. 169 For example if: 171 N = <88 EA C4 53 65 6B 0E CC 2A AC 25 1A 9D F6 4F BB 172 B4 D5 43 1C 4F 44 13 73 CE AF 7A 33 3A 4A FE CA 173 26 14 FA B4 2A 5F EF 60 01 AD 72 05 B9 DD 08 2B 174 1B DF BA 01 1E 15 9C 85 8C A0 E3 B9 5B 85 2C 78 175 09 AA 70 68 0D 48 05 16 6E 57 CF A8 30 31 89 A3 176 83 09 C8 9C C0 56 5B 47 3D 2F 39 43 D8 03 16 97 177 97 9A E1 8D 10 86 08 63 5E CF F2 2F 52 4C 9F C5 178 B9 8B E1 FD 92 E8 BB A1 E8 F6 8D CB 42 8E 6A F3> 180 and: 182 g = <02> 184 and: 186 Z = <07> 188 N encoded as a netstring is: 190 <31 32 38 3A 88 EA C4 53 65 6B 0E CC 2A AC 25 1A 9D F6 191 4F BB B4 D5 43 1C 4F 44 13 73 CE AF 7A 33 3A 4A FE CA 192 26 14 FA B4 2A 5F EF 60 01 AD 72 05 B9 DD 08 2B 1B DF 193 BA 01 1E 15 9C 85 8C A0 E3 B9 5B 85 2C 78 09 AA 70 68 194 0D 48 05 16 6E 57 CF A8 30 31 89 A3 83 09 C8 9C C0 56 195 5B 47 3D 2F 39 43 D8 03 16 97 97 9A E1 8D 10 86 08 63 196 5E CF F2 2F 52 4C 9F C5 B9 8B E1 FD 92 E8 BB A1 E8 F6 197 8D CB 42 8E 6A F3 2C> 199 g encoded as a netstring is: 201 "1:<02>," or <31 3A 02 2C> 203 Z encoded as a netstring is: 205 "1:<07>," or <31 3A 07 2C> 207 The final string is: 209 "141:128:<88 EA C4 53 65 6B 0E CC 2A AC 25 1A 9D F6 4F 210 BB B4 D5 43 1C 4F 44 13 73 CE AF 7A 33 3A 4A FE CA 26 211 14 FA B4 2A 5F EF 60 01 AD 72 05 B9 DD 08 2B 1B DF BA 212 01 1E 15 9C 85 8C A0 E3 B9 5B 85 2C 78 09 AA 70 68 0D 213 48 05 16 6E 57 CF A8 30 31 89 A3 83 09 C8 9C C0 56 5B 214 47 3D 2F 39 43 D8 03 16 97 97 9A E1 8D 10 86 08 63 5E 215 CF F2 2F 52 4C 9F C5 B9 8B E1 FD 92 E8 BB A1 E8 F6 8D 216 CB 42 8E 6A F3>,1:<02>,1:<07>,," 218 or 220 <31 34 31 3A 31 32 38 3A 88 EA C4 53 65 6B 0E CC 2A AC 221 25 1A 9D F6 4F BB B4 D5 43 1C 4F 44 13 73 CE AF 7A 33 222 3A 4A FE CA 26 14 FA B4 2A 5F EF 60 01 AD 72 05 B9 DD 223 08 2B 1B DF BA 01 1E 15 9C 85 8C A0 E3 B9 5B 85 2C 78 224 09 AA 70 68 0D 48 05 16 6E 57 CF A8 30 31 89 A3 83 09 225 C8 9C C0 56 5B 47 3D 2F 39 43 D8 03 16 97 97 9A E1 8D 226 10 86 08 63 5E CF F2 2F 52 4C 9F C5 B9 8B E1 FD 92 E8 227 BB A1 E8 F6 8D CB 42 8E 6A F3 2C 31 3A 02 2C 31 3A 07 228 2C 2C> 230 3.2 Client sends request 232 The client's username (U) is encoded as a netstring (ns1). The client 233 generates its ephemeral public key (A) and this is encoded as a 234 netstring (ns2). 236 The client creates an 8-bit bit-string, most significant bit first, 237 that specifies the security service options that it requests. (The 238 client can only select security services that the server has 239 indicated it can provide). 241 * If bit 0 is set then the client requests integrity protection 242 using the HMAC-MD5 algorithm [HMAC]. 244 * If bit 1 is set then the client requests replay detection using 245 sequence numbers. (Note that bit 0 must be set if this bit is 246 set). 248 * If bit 2 is set then the client requests confidentiality 249 protection using the Blowfish cipher in CBC mode [Blowfish]. 251 The other bits are reserved for future use. This options byte (o) is 252 encoded as a netstring (ns2). 254 These three netstrings (ns1, ns2 and ns3) are concatenated and this 255 string is encoded as a netstring (ns4). The resulting string (ns4) is 256 sent to the server. 258 3.3 Server sends response 260 The server calculates the shared context key (K). 262 The client's salt (s) is encoded as a netstring (ns1). The server 263 generates its ephemeral public key (B) and this is encoded as a 264 netstring (ns2). 266 These two netstrings (ns1 and ns2) are concatenated and this string 267 is encoded as a netstring (ns3). The resulting string (ns3) is sent 268 to the server. 270 3.4 Client sends evidence 271 The client calculates the shared context key (K). 273 The client calculates the evidence (M1) that proves to the server 274 that it knows the shared context key (K), including N, g, s, Z, A and 275 B as part of the calculation. 277 M1 = H(H(N) XOR H(g) | H(U) | s | Z | A | B | K) 279 This evidence (M1) is encoded as a netstring (ns1) and sent to the 280 server. 282 3.5 Server sends evidence 284 The client calculates the evidence (M2) that proves to the client 285 that it knows the shared context key (K), including U, A and o as 286 part of the calculation. 288 M2 = H(U | A | o | M1 | K) 290 This evidence (M2) is encoded as a netstring (ns1) and sent to the 291 client. 293 4 Security Layer 295 Depending on the options specified by the initiator, the security 296 layer may provide integrity protection, replay detection, and/or 297 confidentiality protection. Messages are encoded as follows: 299 * If neither integrity nor confidentiality protection is requested 300 then the message is sent unchanged to the other party. 302 * if just confidentiality protection is requested then the 303 message data is encrypted using the chosen confidentiality 304 algorithm (ie. Blowfish). The encrypted message is encoded as a 305 netstring and sent to the other party. 307 * if just integrity protection is requested then the integrity 308 checksum is calculated on the message data as described in section 309 4.1 311 * if both integrity protection and confidentiality protection are 312 requested then the message data is first encrypted using the 313 chosen confidentiality algorithm (ie. Blowfish). Thereafter the 314 integrity checksum is calculated on the encrypted message data as 315 described in section 4.1 317 * if replay detection is requested then the sequence number included 318 in the integrity checksum is incremented after each message is 319 sent, starting at zero, otherwise the sequence number is always 320 zero 322 4.1 Integrity Protection 324 Integrity protection may be provided using the HMAC-MD5 [HMAC] 325 algorithm. The shared context key (K) is used as the input key. The 326 encoding and decoding of message data is described below. 328 4.1.1 Encoding 330 The (possibly encrypted) message data is encoded as a netstring 331 (ns1). The sequence number is encoded as a netstring (ns2). These 332 two netstrings (ns1 and ns2) are concatenated and encoded as a 333 netstring (ns3). A MAC is computed using the shared context key and 334 ns3. The MAC is then encoded as a netstring (ns4). 336 ns3 and ns4 are concatenated and this string is encoded as a 337 netstring (ns5). ns5 is sent to the other party. 339 4.1.2 Decoding 341 The message data is interpreted as a netstring. This string is the 342 concatenation of two netstrings (ns3 and ns4). ns3 contains the 343 concatenation of the received (possibly encrypted) message data 344 netstring (ns1) and the sequence number netstring (ns2). The 345 interpretation of ns4 is the received message authentication code 346 (MAC). 348 The receiver computes a message authentication code using HMAC-MD5, 349 the shared context key and ns3. This MAC is compared with the 350 received MAC. If the MACs do not match then that indicates that the 351 message has been tampered with, the message should be discarded, and 352 the other party informed. 354 If replay detection was requested then the receiver interprets ns2, 355 checks that the sequence number is what it expects it to be, and 356 rejects the message if it is not. 358 The interpretation of ns3 is the (possibly encrypted) original 359 message. If the message is encrypted it should be decrypted using the 360 chosen confidentiality algorithm (ie. Blowfish) and the session key 361 (K). 363 5 Example 365 The example below uses POP authentication [POP3 AUTH]. The base64 366 encoding of challenges and responses, as well as the "+ " preceding 367 the responses are part of the [POP3 AUTH] specification, not part of 368 this SASL mechanism itself. 370 "C:" and "S:" indicate lines sent by the client and server 371 respectively. 373 S: +OK POP3 server ready 374 C: AUTH SRP-SASL 375 S: + nCpSwCJ8uEeZgn5DbQmxCAgmb6ftsJxkqrKCSJqGJSywlUZCwIlxA9XJwj2fV 376 xs01hN85kTq8AnlVkW4U5Po5ZA3ZkLk5B7W9gd1e3KW55cvNpwWmCOcZWmd8dC1MMq 377 SzBp b3s0CMbvUQuOqGXWXZNi/oBr9CdyMvY.7zakYxeUZsZSj2ZchpB34w0Ymi 378 C: CJGrEZKwQsLfT6WiCJ8uEYcuV8oVukbK4jbGFmK/WjzLwAEMu3cDN/lccHr6uET 379 atd6MihIY5Gvr2YNAiXVic0Ot92MdwNBK64Qk0ouQ88VNsCkNedFfY9XN4tmJgt43L 380 NLN4e/xj6vGTHemh3tp.5qeP5USy/MJ9/qLc/mOyJNAq3.XAUaEjRJRTxmAQOlmB 381 34w0Imi 382 S: + 34qDpenC3eibawB5vqHzM.FB34oE3erYpK/70WbK/9gj3pdaUH3O2d2jHcuHz 383 jaTJCFKHUtOmy9GGKooFMPHCE0xTRHH0uP936Kea7kBx7/STQvpjHQ3UzIPk1Gf9Rl 384 MXMYzuzpJM2dvYV0Lfjko4/DDNNj6S1of2v7XlnoXElqCvQxL3O8LTpjfolhjR1SCD 385 j50YYvEImi 386 C: CZ0wiVpgmEU96.PIMKx1PS8wRUb0m8Wi 387 S: + CZ0wN8a1KmQXLlbsd3Q8obkMu7wgAmqi 388 C: 389 S: +OK SRP-SASL authentication successful 391 6. Discussion 393 Although the MD5 and SHA-1 hash functions are used in this mechanism, 394 they could be replaced with any iterative cryptographic hash function 395 [HMAC]. 397 The specified algorithms were chosen for utility and availablity. 399 The HMAC-MD5 algorithm was chosen as an integrity algorithm because 400 it is faster than both HMAC-SHA1 and MAC algorithms based on secret 401 key encryption algorithms [LIPKEY]. 403 Blowfish was chosen as a cipher because [Blowfish]: 404 * it is free from intellectual property constraints 405 * it is fast 406 * it supports variable key lengths from 32 bits to 448 bits 407 * it has withstood cryptanalysis since 1993 408 * a number of implementations in various programming languages are 409 freely available 411 Other algorithms that are identified as useful may be specified at a 412 later stage. 414 Since confidentiality protection is optional this mechanism should be 415 usable in countries that have strict controls on the use of 416 cryptography. 418 7. Security Considerations 420 This mechanism relies on the security of SRP, which bases its 421 security on the difficulty of solving the Diffie-Hellman problem in 422 the multiplicative field modulo a large safe prime. See section 4 423 "Security Considerations" of [SRP-DRAFT] and section 4 "Security 424 analysis" of [SRP]. 426 This mechanism also relies on the security of the HMAC algorithm and 427 the underlying hash function. Section 6 "Security" of [HMAC] 428 discusses these security issues in detail. Weaknesses found in MD5 do 429 not impact HMAC-MD5 [Dobbertin]. 431 The Blowfish cipher has undergone cryptanalysis for a long period of 432 time and no weaknesses have been found [Blowfish]. 434 U, A and o sent from the client to the server, and N, g, Z, s and B 435 sent from the server to the client could be modified by an attacker 436 before reaching the other party. For this reason, these values are 437 included in the respective calculations of evidence to prove that 438 each party knows the session key. This allows each party to verify 439 that these values were received unmodified. 441 The use of integrity protection is RECOMMENDED to detect message 442 tampering and to avoid session hijacking after authentication has 443 taken place. 445 Replay attacks may be avoided through the use of sequence numbers, 446 because sequence numbers make each integrity protected message 447 exchanged during a session different, and each session uses a 448 different key. 450 Acknowledgements 452 Thanks to Raif S. Naffah for corrections and 453 helpful suggestions. 455 Author's Address 457 Keith Burdis 458 Computer Science Department 459 Rhodes University 460 6139 Grahamstown 461 South Africa 463 Email: cskb@cs.ru.ac.za 465 References 467 [Blowfish] Schneier, Bruce, "The Blowfish Encryption Algorithm", 468 URL: http://www.counterpane.com/blowfish.html 470 [Dobbertin] Dobbertin, Hans, "The Status of MD5 After a Recent 471 Attack", CryptoBytes, RSA Laboratories, URL: 472 ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf 474 [HMAC] Krawczyk, Hugo et.al. "HMAC: Keyed-Hashing for Message 475 Authentication", Internet RFC 2104 477 [KEYWORDS] Bradner, Scott, "Key words for use in RFCs to Indicate 478 Requirement Levels", Internet RFC 2119 480 [LIPKEY] Eisler, Mike, "LIPKEY - A Low Infrastructure Public Key 481 Mechanism Using SPKM", Internet Draft, draft-ietf-cat-lipkey-03.txt 483 [Netstring] Bernstein, Daniel J, "Netstrings", URL: 484 ftp://koobera.math.uic.edu/www/proto/netstrings.txt 486 [POP3 AUTH] Myers, John G, "POP3 AUTHentication command", Internet 487 RFC 1734 489 [SASL] Myers, John G, "Simple Authentication and Security 490 Layer (SASL)", Internet RFC 2222 492 [SRP-DRAFT] Wu, Thomas, "The SRP Authentication and Key Exchange 493 System", Internet Draft, draft-wu-srp-auth-03.txt 495 [SRP] Wu, Thomas, "The Secure Remote Password Protocol", 1998 496 Internet Society Symposium on Network and Distributed Security