idnits 2.17.1 draft-cridland-sasl-hexa-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 463. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 487. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (February 26, 2007) is 6270 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: 'UTF-8' is defined on line 413, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') ** Obsolete normative reference: RFC 4013 (ref. 'SASLPREP') (Obsoleted by RFC 7613) -- Obsolete informational reference (is this intentional?): RFC 2831 (ref. 'DIGEST-MD5') (Obsoleted by RFC 6331) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Cridland 3 Internet-Draft A. Melnikov 4 Expires: August 30, 2007 Isode Limited 5 February 26, 2007 7 The Hash Exchange Authentication SASL Mechanism 8 draft-cridland-sasl-hexa-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 30, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This memo defines and discusses a SASL mechanism that is based on the 42 exchange of hashes. It does not require the storage of a plaintext 43 equivalent on the server, is simple to implement, and provides a 44 reasonable level of security. 46 Table of Contents 48 1. Conventions used in this document . . . . . . . . . . . . . . 3 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.1.1. Deployability . . . . . . . . . . . . . . . . . . . . 3 52 2.1.2. Hash Agility . . . . . . . . . . . . . . . . . . . . . 3 53 2.1.3. Ease of Implementation . . . . . . . . . . . . . . . . 4 54 3. Notations and Definitions . . . . . . . . . . . . . . . . . . 4 55 3.1. HMAC and Hash functions . . . . . . . . . . . . . . . . . 4 56 3.1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. Wire Message Format . . . . . . . . . . . . . . . . . . . 5 58 3.3. Prior Setup . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.4. Authentication Process . . . . . . . . . . . . . . . . . . 5 60 3.4.1. Initial client message . . . . . . . . . . . . . . . . 5 61 3.4.2. Server challenge message . . . . . . . . . . . . . . . 6 62 3.4.3. Client response message . . . . . . . . . . . . . . . 6 63 3.4.4. Server Authentication and Mutual Auth . . . . . . . . 6 64 4. Mandatory to Implement . . . . . . . . . . . . . . . . . . . . 7 65 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 6.1. Plaintext Equivalents . . . . . . . . . . . . . . . . . . 8 68 6.2. Hash algorithm usage . . . . . . . . . . . . . . . . . . . 8 69 6.3. Resistance to attacks . . . . . . . . . . . . . . . . . . 9 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 74 Intellectual Property and Copyright Statements . . . . . . . . . . 12 76 1. Conventions used in this document 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [KEYWORDS]. 82 2. Introduction 84 Although other hash-based [SASL] mechanisms exist, they are being 85 rapidly outdated by advances in computing speed and the discovery of 86 weaknesses in hash functions. Moreover, both [CRAM-MD5] and 87 [DIGEST-MD5] involve the server having plaintext equivalents in the 88 shared secret store. 90 This mechanism was borne out of a percieved need within the system 91 administration community to have a mechanism which was both easier to 92 implement and also safer than [DIGEST-MD5]. 94 2.1. Rationale 96 HEXA is specifically aimed at providing three key features. 98 2.1.1. Deployability 100 HEXA is designed to be acceptable to deploy in the real world. Its 101 authentication database is designed such that it may be used directly 102 for local logins, effectively having the same properties as a typical 103 /etc/shadow file on UNIX systems. This allows HEXA to co-exist with 104 very well deployed mechanisms such as [PLAIN], freeing the need for 105 transitioning. 107 2.1.2. Hash Agility 109 Hash algorithms have an alarming tendancy to age. It is therefore 110 beneficial to allow a server administrator to switch hash algorithms. 111 This is only practical, however, when it is known that the new hash 112 algorithm can be well supported by the clients in use. Where the 113 clients are out of the control of the administrator, for example in 114 typical commercial settings, it is useful for the administrator to be 115 aware of what the current deployed base is able to use. 117 Therefore, in HEXA, clients advertise their capability to the server, 118 allowing a server administrator to upgrade the hash algorithm as 119 required. 121 2.1.3. Ease of Implementation 123 In general, [DIGEST-MD5] has been found to be difficult to implement 124 interoperably. Even well known implementations have been found to 125 have interoperability problems under some circumstances. HEXA 126 attempts to tackle this by using a small number of operation types, 127 and simple parsing. This allows for simple scripting languages to 128 implement, as well as using hash algorithms and related functions 129 that are known to be well deployed. 131 Since no mechanism can be considered secure in practise if no 132 implementations exist, this specification chooses easily available 133 pre-existing source code above stronger, less well implemented 134 algorithms. 136 3. Notations and Definitions 138 3.1. HMAC and Hash functions 140 This specification requires the use of [HMAC], based on hash 141 functions such as [MD5], SHA1, or SHA-256. 143 Messages are shown in plain text, with the CR LF pair shown as a line 144 ending. 146 Mandatory to implement hashes are discussed in Section 4, and are 147 considered volatile parts of this specification, very likely to 148 change in future revisions of this specification. 150 3.1.1. Notation 152 We use a relatively simple notation to show the calculations 153 involved: 154 HASH(T) 155 An agreed hash algorithm, used to produce a cryptographically 156 secure hash of the input data T. 157 HMAC(K,T) 158 An [HMAC] function used with an agreed hash function, used to 159 produce a MAC for T with a key of K. 160 HMAC[n](K,T) 161 Where n is an integer, expands to HMAC(HMAC[n-1](K,T),T). 162 HMAC[1](K,T) is equivalent to HMAC(K,T). 163 Q + W 164 Where Q and W are strings, represents simple concatenation. 166 Q ^ W 167 Where Q and W are strings, represents an octet by octet XOR. 168 SASLprep(X) 169 Where X is a string, represents the application of the [SASLPREP] 170 algorithm to the string. 172 3.2. Wire Message Format 174 HEXA uses a wire format based on a simplified variant of email 175 message header formats, and only transfers text. No folding or 176 encoding is required or allowed. 178 The message contains keys and values, where each key appears a 179 maximum of once. Keys consist of ASCII letters, numbers, and the 180 hyphen character. Values contain UTF-8, and begin with a non-space 181 character. They never contain NUL, CR, or LF. Each Key Value pair 182 ends with a CR LF pair. 184 Keys appear first, followed by a single colon (":"), followed by the 185 value. Any surrounding spaces are considered part of the value. 187 3.3. Prior Setup 189 The client is assumed to have an Authcid, an optional Authzid, and a 190 Password. 192 The server has a Realm, and a database keyed against Authcid 193 containing a Salt, and hash output known as the Verifier. 195 Verifier := HMAC[n](Intermediate, Salt) 196 Intermediate := HMAC[n](Realm + SASLprep(Authcid) 197 + SASLprep(Password), Salt) 199 The server's database is initially populated before authentication by 200 temporarily calculating the Intermediate from the supplied Password, 201 and choosing a new Salt. A new Salt SHOULD be used whenever the 202 Password is changed. The hash algorithm used is also remembered by 203 the server - servers MAY use multiple hash algorithms. 205 After calculating and storing the Verifier, the Intermediate MUST be 206 discarded. 208 3.4. Authentication Process 210 3.4.1. Initial client message 212 Initially, the client sends a message containing Authcid, optionally 213 Authzid, a list of hash algorithm names it supports, and some random 214 data to use as a client nonce, this message is ClientMessage: 216 Authcid:mel 217 Hashes:MD5 SHA1 SHA-256 218 Client-Nonce:laksjdoijcosijdv 219 Channel-Bindings:TLS 221 3.4.2. Server challenge message 223 The server looks up Authcid in its database, selects the strongest 224 hash algorithm mutually supported, and returns the hash algorithm, 225 the number of cycles it uses, and the value of Salt. It also creates 226 some random data for use as a server nonce. Because this MUST be 227 textual, servers MAY base64 encode this data, however, this is an 228 implementation detail. The server sends the server nonce, Salt, and 229 Realm to the client, along with an indication of which channel 230 binding the server will use, if any: 232 Realm:example.net 233 Salt:aajvskjhvslkjdnvcn 234 Hash:MD5 235 Hash-Cycles:5 236 Server-Nonce:ksjdnclksdhufdh 237 Channel-Binding:TLS 239 3.4.3. Client response message 241 The client stores this message precisely as received, as 242 ServerMessage. 244 The client now calculates Intermediate and Verifier as above, and in 245 addition a hash Key, and a value Exchange, such that: 247 Key := HMAC[n](Verifier, ClientMessage 248 + ServerMessage + ChannelBinding) 249 Exchange := Key ^ Intermediate 251 If there is no channel binding available that the server supports, 252 then ChannelBinding will be an empty string. Exchange is represented 253 as hex, and the result is sent to the server: 255 Hash-Exchange:1f2d... 257 3.4.4. Server Authentication and Mutual Auth 259 The server can now construct Key, extract Intermediate from Exchange, 260 and verify Intermediate against the stored hash output Verifier. In 261 order to prove to the client that it can do so, it sends the client a 262 final message containing a hash output Authentication, such that: 264 Intermediate := Exchange ^ Key 265 Authentication := HMAC[n](Intermediate, ChannelBinding 266 + ServerMessage + Salt + ClientMessage) 268 This has is sent to the client as: 270 Server-Auth:3f4d5a... 272 4. Mandatory to Implement 274 The rationale behind this mechanism is ease of deployment and 275 implementation, thus implementations MUST provide a configuration 276 which supports the [MD5] hash algorithm using a minimal number of 277 cycles of 16. Implementations SHOULD also support SHA-256. 279 This is because both [MD5], and [HMAC] implementations which are 280 hardcoded to use [MD5], are easily available in many languages and 281 environments. 283 5. Formal Syntax 285 Insert boilerplate about [ABNF] here. 287 wire-message = *key-value 288 key-value = key ":" value CRLF 289 key = ALPHA *( ALPHA / "-" / DIGIT ) 290 value = utf8-text 291 utf8-text = 1*( VCHAR / SP / UTF-2 / UTF8-3 / UTF8-4 ) 292 ; visible UTF-8 or space. 293 hash-output = 1*( HEXDIG ) 294 ; Output of hash algorithm, generally 32 or more has digits. 296 ; Following productions all conform to wire-message: 298 client-init-message = authcid [ authzid ] hashes client-nonce 299 [ channel-bindings ] *( extension ) 300 server-challenge-message = realm hash hash-cycles server-nonce 301 [ channel-binding ] *( extension ) 302 client-response-message = hash-exchange *( extension ) 303 server-auth-message = server-auth *( extension ) 305 ; Following productions all conform to key-value: 307 ; client-init-message: 309 authcid = "Authcid" ":" utf8text CRLF 310 authzid = "Authzid" ":" utf8text CRLF 311 ; SASLPrepped authcid/authzid. 312 hashes = "Hashes" ":" hash-name *( SP hash-name ) CRLF 313 client-nonce = "Client-Nonce" ":" utf8text CRLF 314 ; MUST be generated afresh with reasonable entropy. 315 channel-bindings = "Channel-Bindings" ":" channel-binding-name 316 *( SP channel-binding-name ) CRLF 318 ; server-challenge-message: 319 realm = "Realm" ":" utf8text CRLF 320 hash = "Hash" ":" hash-name CRLF 321 hash-cycles = "Cycles" ":" 1*( DIGIT ) CRLF 322 server-nonce = "Server-Nonce" ":" utf8text CRLF 323 ; MUST be generated afresh with reasonable entropy. 324 channel-binding = "Channel-Binding:" ":" channel-binding-name CRLF 326 ; client-response-message: 327 hash-exchange = "Hash-Exchange" ":" hash-output CRLF 329 ; server-auth-message: 330 server-auth = "Server-Auth" ":" hash-output CRLF 332 ; Values: 333 channel-binding-name = ALPHA *( ALPHA / DIGIT / "-" ) 334 hash-name = ALPHA *( ALPHA / DIGIT / "-" ) 336 ; Extensions: 337 extension = key-value 339 6. Security Considerations 341 6.1. Plaintext Equivalents 343 The intermediate hash B is a plaintext equivalent. Clients SHOULD 344 NOT store this, and MUST NOT store the original plaintext password. 345 Servers MUST NOT store B. 347 6.2. Hash algorithm usage 349 In general, it is thought that the recursive application of hash 350 functions increases the strength of a hash. In particular, if the 351 hash has no weaknesses at all, merely doubling the number of 352 iterations will cause an offline dictionary attack to take twice as 353 much CPU resource. Making this a variable, negotiated, factor allows 354 very simple increases in security, as long as the hash algorithm 355 itself is not compromised sufficiently that a non-brute-force attack 356 becomes practical. 358 The exact hash algorithm used may be changed by live deployments. 359 HEXA provides a simple method for server administrators to discover 360 actual availability of new hash algorithms in clients, simplifying a 361 hash algorithm change. 363 6.3. Resistance to attacks 365 HEXA is thought to be resistent to slightly more attacks than 366 [DIGEST-MD5]: 367 Downgrade 368 Assuming that HEXA can be negotiated at all, a downgrade attack 369 inside HEXA cannot be mounted, as complete messages are used as 370 input to the hashing functions - a man-in-the-middle attack will 371 cause the authentication to fail. 372 Server based attack 373 Merely obtaining the authentication database will not directly 374 allow an attcker to authenticate masquerading as a legitimate user 375 without substantial offline dictionary attacks. However, if an 376 attacker can both obtain the authentication database and observe 377 traffic on the wire, then the attacker can obtain B. As with 378 [DIGEST-MD5], this will not yield the password without an 379 expensive offline-dictionary attack. 380 Client based attack 381 Clients typically store sufficient data to reauthenticate later 382 without interactively requesting passwords from the user. Like 383 [DIGEST-MD5], clients need not store the actual password, but can 384 merely store B for this purpose. This practise is not 385 recommended, as an attacker obtaining B can authenticate as the 386 user. 388 7. References 390 7.1. Normative References 392 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 393 Specifications: ABNF", RFC 4234, October 2005. 395 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 396 Hashing for Message Authentication", RFC 2104, 397 February 1997. 399 [KEYWORDS] 400 Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, March 1997. 403 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 404 April 1992. 406 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and 407 Security Layer (SASL)", RFC 4422, June 2006. 409 [SASLPREP] 410 Zeilenga, K., "SASLprep: Stringprep Profile for User Names 411 and Passwords", RFC 4013, February 2005. 413 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 414 10646", STD 63, RFC 3629, November 2003. 416 7.2. Informative References 418 [CRAM-MD5] 419 Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP 420 AUTHorize Extension for Simple Challenge/Response", 421 RFC 2195, September 1997. 423 [DIGEST-MD5] 424 Leach, P. and C. Newman, "Using Digest Authentication as a 425 SASL Mechanism", RFC 2831, May 2000. 427 [PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and 428 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 430 Authors' Addresses 432 Dave Cridland 433 Isode Limited 434 5 Castle Business Village 435 36, Station Road 436 Hampton, Middlesex TW12 2BX 437 GB 439 Email: dave.cridland@isode.com 440 Alexey Melnikov 441 Isode Limited 442 5 Castle Business Village 443 36, Station Road 444 Hampton, Middlesex TW12 2BX 445 GB 447 Email: alexey.melnikov@isode.com 449 Full Copyright Statement 451 Copyright (C) The IETF Trust (2007). 453 This document is subject to the rights, licenses and restrictions 454 contained in BCP 78, and except as set forth therein, the authors 455 retain all their rights. 457 This document and the information contained herein are provided on an 458 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 459 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 460 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 461 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 462 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 463 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 465 Intellectual Property 467 The IETF takes no position regarding the validity or scope of any 468 Intellectual Property Rights or other rights that might be claimed to 469 pertain to the implementation or use of the technology described in 470 this document or the extent to which any license under such rights 471 might or might not be available; nor does it represent that it has 472 made any independent effort to identify any such rights. Information 473 on the procedures with respect to rights in RFC documents can be 474 found in BCP 78 and BCP 79. 476 Copies of IPR disclosures made to the IETF Secretariat and any 477 assurances of licenses to be made available, or the result of an 478 attempt made to obtain a general license or permission for the use of 479 such proprietary rights by implementers or users of this 480 specification can be obtained from the IETF on-line IPR repository at 481 http://www.ietf.org/ipr. 483 The IETF invites any interested party to bring to its attention any 484 copyrights, patents or patent applications, or other proprietary 485 rights that may cover technology that may be required to implement 486 this standard. Please address the information to the IETF at 487 ietf-ipr@ietf.org. 489 Acknowledgment 491 Funding for the RFC Editor function is provided by the IETF 492 Administrative Support Activity (IASA).