idnits 2.17.1 draft-zeilenga-sasl-yap-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (30 May 2009) is 5446 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC4648' is defined on line 321, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) -- Obsolete informational reference (is this intentional?): RFC 2831 (Obsoleted by RFC 6331) -- Obsolete informational reference (is this intentional?): RFC 4634 (Obsoleted by RFC 6234) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- No information found for draft-ietf-sasl-scram-xx - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Experimental Isode Limited 4 Expires in six months 30 May 2009 6 SASL Yet Another Password Mechanism 7 9 Status of this Memo 11 This document is intended to be, after appropriate review and 12 revision, submitted to the RFC Editor as a Experimental document. 13 Distribution of this memo is unlimited. Technical discussion of this 14 document may take place on the IETF SASL WG mailing list . Please send editorial comments directly to the author 16 . 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference material 28 or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 Abstract 41 This document describes a password authentication mechanism, called 42 YAP-SHA-256-TLS-UNIQ, for use in protocols which support Simple 43 Authentication and Security Layer (SASL) framework. The mechanism 44 relies on security services provided by a lower layer, such as 45 Transport Layer Security (TLS), to protect the authentication 46 exchange, and subsequent application data exchange, from common 47 attacks. The YAP-SHA-256-TLS-UNIQ mechanism can be viewed as an 48 alternative to other password-based SASL mechanism, such as PLAIN, 49 CRAM-MD5, and DIGEST-MD5. 51 1. Introduction 53 There exist multiple password-based mechanisms for use in the Simple 54 Authentication and Security Layer (SASL) [RFC4422] framework. These 55 include the PLAIN [RFC4616], CRAM-MD5 [RFC2195], and DIGEST-MD5 56 [RFC2831]. None of these mechanisms, themselves, provide integrity 57 and confidential protection over the entirety of the authentication 58 exchange. Only DIGEST-MD5 offers a security layer and, even so, the 59 specification and its implementations suffer from multiple problems. 60 And while these mechanisms may be used in conjunction with lower-level 61 security services, these mechanism do not offer any facility to bind 62 the channels [RFC5056]. 64 This situation has lead to multiple efforts to design "better" SASL 65 password-based mechanism. This document not only specifies yet 66 another password mechanism, YAP-SHA-256-TLS-UNIQ, but defines a family 67 of related password mechanisms, YAP-*. 69 YAP-* is a family of simple password SASL mechanisms based upon the 70 Keyed-Hash Message Authentication Code (HMAC) [RFC2104] algorithm and 71 unique channel bindings [RFC5056]. 73 The YAP-SHA256-TLS-UNIQ is a YAP mechanism which uses the SHA-256 74 [FIPS180-2] cryptographic hash function in conjunction with the HMAC 75 algorithm and the tls-unique [CBT-TLS-U] unique channel bindings. 77 YAP is specified as a family of SASL mechanisms to provide hash 78 agility and channel binding type agility. 80 YAP mechanisms rely on services provided at a lower level, such as 81 Transport Layer Security (TLS) [RFC5246], to secure the authentication 82 exchange and subsequent application data exchange and, hence, YAP 83 mechanisms do not offer a SASL security layer. YAP mechanisms require 84 the lower-level security layer to be bound in the authentication using 85 unique channel bindings [RFC5056]. YAP relies on client to 86 authenticate the server within this lower-level security layer to 87 avoid information disclosure to rogue servers. 89 1.1 Experimental 91 This specification is part of a research and development effort 92 exploring alternatives to current password-based authentication 93 mechanisms. 95 Implementors of this specification ought to considered implementing 96 the SCRAM [SCRAM] mechanism being developed by the IETF for 97 publication on the Standards Track. 99 1.2 Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 2. The YAP-* Family of Mechanisms 107 Each mechanism in this family differs by the choice of hash algorithm 108 and the choice of unique channel binding type. Each mechanism has a 109 name of the form YAP-HA-CBT where HA is a string chosen to reflect the 110 hash algorithm used and CBT is a string choosen to reflect the channel 111 binding type. HA and CBT are to be choose so the mechanism name does 112 not exceed 20 characters imposed by the SASL Technical Specification 113 [RFC4422]. While it not required that each mechanism use the same HA 114 string for a particular hash algorithm or the same CBT for a 115 particular channel binding type as those used in previously registered 116 mechanisms, reuse of the encouraged. 118 To define a new mechanism within the YAP family of mechanisms, the 119 mechanism specification must indicate that it is a YAP mechanism, 120 identify the hash algorithm used, identify the channel binding type 121 used and specify the name the mechanism and cause this name to be 122 registered with IANA in accordance with the SASL Technical 123 Specification. The mechanism specification should detail security 124 considerations specific to hash algorithm and channel binding types 125 selected. 127 3. The YAP Mechanism 129 The mechanism involves a single message from the client to the server. 131 message = authzid separator [ authcid ] separator data 132 separator = %x00 134 where: 135 - , when present, is the authorization identity in the 136 form specified by the application protocol specification, 137 represented in UTF-8 [RFC3629], and 139 - is authentication identity, a simple user name 140 [RFC4013], prepared using the SASLprep [RFC4013] and represented 141 in UTF-8 [RFC3629], 143 - is a Keyed-Hash Message Authentication Code (HMAC) 144 [RFC2104] produced as described below. 146 Implementors should note that the data portion of the message may 147 contain a zero-valued octet and hence should parse the message 148 front-to-back. 150 The HMAC is produced using the mechanism-specific hash algorithm, such 151 as SHA-256, as the cryptographic hash function, H. The secret key, K, 152 is the unique channel binding [RFC5056] for the lower-level security 153 protocol, padded with zero octets to the block size of the hash 154 function. Where the unique channel binding is longer than the block 155 size of the hash function, K is hash of the unique channel binding. 156 The text is the concatenation of the authcid, the authzid, and the 157 hash of the user's password, a simple password [RFC4013], prepared 158 using SASLprep [RFC4013] and represented in UTF-8 [RFC3629]. That is, 159 the is computed as illustrated by the following pseudo code. 161 HMAC( 162 Pad( Length(ChannelBinding)>HashBlockSize 163 ? H(ChannelBinding) : ChannelBinding, 0, HashBlockSize), 164 Concat(authzid, authcid, H(UTF8(SASLprep(password))))) 166 Note, in this pseudo code, the first argument of the HMAC function is 167 the secret key and the second is the text. The cryptographic hash 168 function used in the HMAC is implicitly H. The Pad function pads the 169 first argument to the length specified in the third argument with the 170 octet value provided in the second argument. The variable 171 HashBlockSize is the block size of hash function, H. The Length 172 function returns the length of its argument. The Concat function 173 returns an octet which is the concatenation of its arguments. The 174 UTF8 function returns the UTF-8 encoding of its argument. The 175 SASLprep function prepares it argument according to the SASLprep 176 algorithm. The H function returns the hash of its argument. 178 The hash of the user's password is a password equivalent. Servers may 179 choose to store this hash instead of the user's password. In either 180 case, the stored value must be adequately protected. 182 Implementations SHOULD NOT advertise availability of any mechanism in 183 this family unless a lower-level security service providing both data 184 integrity and data confidentiality protection is in place. Client 185 implementations SHOULD NOT utilize any mechanism in this family 186 without first verifying the identity of the server within the 187 lower-level security service. Client implementors should consult the 188 application protocol specification, in conjunction with the 189 specification of the lower-level security service, for details on how 190 to implement this verification. 192 4. The YAP-SHA-256-TLS-UNIQ Mechanism 194 The YAP-SHA-256-TLS-UNIQ mechanism is a YAP mechanism which utilizes 195 the SHA-256 [FIPS180-2][RFC4634] hash algorithm and the tls-unique 196 unique channel binding type [CBT-TLS-U]. This type is for use with 197 Transport Layer Security (TLS) [RFC5246]. 199 The mechanism is named "YAP-SHA-256-TLS-UNIQ". 201 5. YAP-SHA-256-TLS-UNIQ Example 203 Consider a client authenticating as "kurt" with the password "secret" 204 who is not wishing to act as another user which has established TLS 205 channel which has the tls-unique binding of 206 zHsxigXXUssRg9iVRbw5AX/dgRVlUgBz/RfjI7c4woM= (base64). 208 The client compute the HMAC over the authzid, authcid, and password as 209 described in section 3 with the binding as the secret key. The 210 client would construct text input the HMAC by concatenating the empty 211 authzid string with the "kurt" authcid string with the hash of the 212 properly prepared password. SASLprep("secret") returns "secret". The 213 hash of this string (when encoded as UTF-8), is 214 K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols= (base64). The HMAC for 215 this text and key is Ksarn7PFnqCgi4ewSYOfXIyP8ImNcmpoWmtCgA0QqT4= 216 (base64). 218 The client would construct and send the message which contained first 219 zero octets for the authzid, then a 00 (hex) octet for a separator, 220 followed by 4 octets 6b 75 72 74 (hex) representing the authcid 221 "kurt", followed by 00 (hex) octet for a separator, followed by 32 222 octets HMAC value. This would produce a message of 223 AGt1cnQAKsarn7PFnqCgi4ewSYOfXIyP8ImNcmpoWmtCgA0QqT4= (base64). 225 6. Security Considerations 226 Security is discussed throughout this document. 228 This family of mechanisms was specifically designed to rely on 229 security services offered at lower-levels to secure mechanism 230 negotiation, the authentication exchange and subsequent data 231 exchanges. To ensure lower-level security services are provided 232 end-to-end, the mechanisms utilize unique channel bindings [RFC5056]. 234 To avoid disclosing the identity information to a rogue server, the 235 client verifies the server's identity using the lower-layer security 236 service before utilizing any mechanism in this family. 238 Hash agility and channel binding type agility is provided in the 239 family of mechanisms through the specification of additional 240 mechanisms. 242 To avoid requiring server implementations maintain access to the 243 user's password, a password equivalent is used. The password 244 equivalent is a simple hash of the password. 246 While it is likely that those choosing to store the password 247 equivalent instead of the password would prefer the equivalent be 248 designed to hinder dictionary attack with precomputed dictionary 249 entries, a simple hash was chosen to avoid adding a server challenge. 250 Use of the authcid as a salt was considered but rejected as it would 251 tie the password equivalent to a particular authcid. It is desirable 252 for the password equivalent to be usable with multiple authcid values 253 (kurt and KURT) representing the same entity. It was also realized 254 that it likely that implementors would (continue to) choose to store 255 the password instead of a mechanism-specific password equivalent. 256 Storing the password avoids significant implementation complexity and 257 facilitates mechanism agility. 259 YAP-SHA-256-TLS-UNIQ uses the SHA-256 hash algorithm and tls-unique 260 channel binding type. At the time of this writing, there are no known 261 attacks on SHA-256 hash algorithm or tls-unique channel binding type 262 which are applicable to this mechanism. 264 7. IANA Considerations 266 It is requested that IANA process the following request(s) upon 267 approval of this document for publication as an RFC. 269 Subject: Registration of SASL YAP family of mechanisms 270 SASL family name (or prefix for the family): YAP-* 271 Security considerations: see RFC XXXX 272 Published specification (recommended): RFC XXXX 273 Person & email address to contact for further information: 274 Kurt Zeilenga 275 Intended usage: COMMON 277 Subject: Registration of SASL YAP SHA-256 tls_endpoint mechanism 278 SASL name (or prefix for the family): YAP-SHA-256-TLS-UNIQ 279 Security considerations: see RFC XXXX 280 Published specification (recommended): RFC XXXX 281 Person & email address to contact for further information: 282 Kurt Zeilenga 283 Intended usage: COMMON 285 7. Acknowledgments 287 TBD. 289 8. Author's Address 291 Kurt D. Zeilenga 292 Isode Limited 294 Email: Kurt.Zeilenga@Isode.COM 296 9. References 298 [[Note to the RFC Editor: please replace the citation tags used in 299 referencing Internet-Drafts with tags of the form RFCnnnn where 300 possible.]] 302 9.1. Normative References 304 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: 305 Keyed-Hashing for Message Authentication", RFC 2104, 306 February 1997. 308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 311 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 312 10646", RFC 3629 (also STD 63), November 2003. 314 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User 315 Names and Passwords", RFC 4013, February 2005. 317 [RFC4422] Melnikov, A. (Editor), K. Zeilenga (Editor), "Simple 318 Authentication and Security Layer (SASL)", RFC 4422, 319 June 2006. 321 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 322 Encodings", RFC 4648, October 2006. 324 [RFC5056] Williams, N., "on the Use of Channel Bidnings to Secure 325 Channels", RFC 5056, November 2007. 327 [FIPS180-2] National Institute of Standards and Technology, "Secure 328 Hash Algorithm. NIST FIPS 180-2", August 2002. 330 [CBT-TLS-U] Zhu, Larry, "Registration of TLS unique channel bindings 331 (generic)", http://www.iana.org/assignments/channel- 332 binding-types/tls-unique, June 26, 2008. 334 9.2. Informative References 336 [RFC2195] Klensin, J., R. Catoe, and P. Krumviede, "IMAP/POP 337 AUTHorize Extension for Simple Challenge/Response", RFC 338 2195, September 1997. 340 [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as 341 a SASL Mechanism", RFC 2831, May 2000. 343 [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and 344 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 346 [RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash 347 Algorithms (SHA and HMAC-SHA)", RFC 4634, August 2006. 349 [RFC5246] Dierks, T. and, E. Rescorla, "The Transport Layer 350 Security (TLS) Protocol Version 1.2", RFC 5246, August 351 2008. 353 [SCRAM] Menon-Sen, A., el. al, "Salted Challenge Response 354 (SCRAM) SASL Mechanism", draft-ietf-sasl-scram-xx.txt, a 355 work in progress. 357 Full Copyright 359 Copyright (c) 2009 IETF Trust and the persons identified as the 360 document authors. All rights reserved. 362 This document is subject to BCP 78 and the IETF Trust's Legal 363 Provisions Relating to IETF Documents in effect on the date of 364 publication of this document (http://trustee.ietf.org/license-info). 365 Please review these documents carefully, as they describe your rights 366 and restrictions with respect to this document. 368 This document may contain material from IETF Documents or IETF 369 Contributions published or made publicly available before November 10, 370 2008. The person(s) controlling the copyright in some of this material 371 may not have granted the IETF Trust the right to allow modifications 372 of such material outside the IETF Standards Process. Without 373 obtaining an adequate license from the person(s) controlling the 374 copyright in such materials, this document may not be modified outside 375 the IETF Standards Process, and derivative works of it may not be 376 created outside the IETF Standards Process, except to format it for 377 publication as an RFC or to translate it into languages other than 378 English.