INTERNET-DRAFT Kurt D. Zeilenga Intended Category: Standards Track Isode Limited Expires in six months 8 July 2007 SASL Yet Another Password Mechanism Status of this Memo This document is intended to be, after appropriate review and revision, submitted to the RFC Editor as a Standards Track document. Distribution of this memo is unlimited. Technical discussion of this document will take place on the IETF SASL WG mailing list . Please send editorial comments directly to the author . By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The IETF Trust (2007). All Rights Reserved. Please see the Full Copyright section near the end of this document for more information. Zeilenga draft-zeilenga-sasl-yap-01 [Page 1] INTERNET-DRAFT SASL YAP 8 July 2007 Abstract This document describes a password authentication mechanism, called YAP-SHA-256, for use in protocols which support Simple Authentication and Security Layer (SASL) framework. The mechanism relies on security services provided by a lower layer, such as Transport Layer Security (TLS), to protect the authentication exchange, and subsequent application data exchange, from common attacks. The YAP-SHA-256 mechanism may be viewed as an alternative to other password-based SASL mechanism, such as PLAIN, CRAM-MD5, and DIGEST-MD5. 1. Introduction There exists multiple password-based methods for use in the Simple Authentication and Security Layer (SASL) [RFC4422] framework. These include the PLAIN [RFC4616], CRAM-MD5 [RFC2195], and DIGEST-MD5 [RFC2831]. None of these mechanisms, themselves, provide integrity and confidential protection over the entirety of the authentication exchange. Only DIGEST-MD5 offers a security layer and, even so, the specification and its implementations suffer from multiple problems. And while these mechanisms may be used in conjunction with lower-level security services, these mechanism do not offer any facility to bind the channels [CBIND]. This situation has lead to multiple efforts to design "better" SASL password-based mechanism. This document not only specifies yet another password mechanism, YAP-SHA-256, but defines a family of related password mechanisms, YAP-*. YAP-* is pronounced "yap-star". YAP-SHA-256 is pronounced "yap-shaw-two-fifty-six". YAP-* is a family of simple password SASL mechanisms based upon the Keyed-Hash Message Authentication Code (HMAC) [RFC2104] algorithm. The YAP-SHA-256 utilizes the SHA-256 [FIPS180-2] cryptographic hash function in conjunction with the HMAC algorithm. YAP is specified as a family of SASL mechanisms to provide hash agility. YAP mechanisms reply on services provided at a lower level, such as Transport Layer Security (TLS) [RFC4346], to secure the authentication exchange and subsequent application data exchange and, hence, YAP-SHA-256 does not offer a SASL security layer. YAP mechanisms requires the lower-level security layer to be bound [CBIND] in the authentication. Zeilenga draft-zeilenga-sasl-yap-01 [Page 2] INTERNET-DRAFT SASL YAP 8 July 2007 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119]. 2. The YAP-* Family of mechanism Each mechanism in this family differs only by the choice of hash algorithm. Each mechanism has a name of the form YAP-HASH where HASH is a string chosen to reflect the hash algorithm used. To define a new mechanism within this family, the mechanism specification need only identify that it is a YAP mechanism, identify the hash algorithm used, and identify the name of the mechanism. The name of the mechanism is to be registered as discussed in [RFC4422]. The mechanism involves a single message from the client to the server. message = authzid separator [ authcid ] separator data separator = %x00 where: - , when present, is the authorization identity in the form specified by the application protocol specification, represented in UTF-8 [RFC3629], and - is authentication identity, a simple user name [RFC4013], prepared using the SASLprep [RFC4013] and represented in UTF-8 [RFC3629], - is a Keyed-Hash Message Authentication Code (HMAC) [RFC2104] produced as described below. Implementors should note that the data portion of the message may contain a zero-valued octet and hence should parse the message front-to-back. The HMAC is produced using the mechanism-specific hash algorithm, such as SHA-256 [FIPS180-2], as the cryptographic hash function, H. The secret key, K, is the unique channel bindings [CBIND] for the lower-level security protocol, padded with zero octets to the block size of the hash function. Where the unique channel binding is longer than the block size of the hash function, K is hash of the unique channel bindings. The text is the concatenation of the authcid, the authzid, and the hash of the user's password, a simple password [RFC4013], prepared using SASLprep [RFC4013] and represented in UTF-8 [RFC3629]. That is, the is computed as illustrated by the following pseudo code. Zeilenga draft-zeilenga-sasl-yap-01 [Page 3] INTERNET-DRAFT SASL YAP 8 July 2007 HMAC( Pad( Length(ChannelBindings)>HashBlockSize ? H(ChannelBindings) : ChannelBindings, 0, HashBlockSize), Concat( authzid, authcid, H(UTF8( SASLprep( password ))))) Note, in this pseudo code, the first argument of the HMAC function is the secret key and the second is the text. The cryptographic hash function used in the HMAC is implicitly H. The Pad function pads the first argument to the length specified in the third argument with the octet value provided in the second argument. The variable HashBlockSize is the block size of hash function, H. The Length function returns the length of its argument. The Concat function returns an octet which is the concatentation of its arguments. The UTF8 function returns the UTF-8 encoding of its argument. The SASLprep function prepares it argument according to the SASLprep algorithm. The H function returns the hash of its argument. The hash of the user's password is a password equivalent. Servers may choose to store this hash instead of the user's password. In either case, the stored value must be adequately protected. Implementations SHOULD NOT advertise availabilty of any mechanism in this family unless a lower-level security service providing both data integrity and data confidentiality protection is in place. Client implementations SHOULD NOT utilize any mechanism in this family without first verifying the identity of the server within the lower-level security service. Client implementors should consult the application protocol specification, in conjuction with the specification of the lower-level security service, for details on how to implement this verification. Implementations MUST support Transport Security Layer (TLS) [RFC4346] channel bindings, as describe in [CBIND-TLS]. 3. The YAP-SHA-256 Mechanism The YAP-SHA-256 mechanism, named "YAP-SHA-256", is a YAP SASL mechanism. The YAP-SHA-256 mechanism, as the name suggests, uses the SHA-256 [FIPS180-2][RFC4634] hash algorithm. 4. YAP-SHA-256 Examples This section will provide examples of an YAP-SHA-256 authentication exchanges... Zeilenga draft-zeilenga-sasl-yap-01 [Page 4] INTERNET-DRAFT SASL YAP 8 July 2007 5. Security Considerations Security is discussed throughout this document. This family of mechanisms was specifically designed to reply on security services offered at lower-levels to secure the authentication exchange and subsequent data exchanges. To ensure lower-level security services are provided end-to-end, the mechanisms utilize channel bindings [CBIND]. To avoid disclosing the identity information to a rogue server, the client is to verify the server's identity using the lower-layer security service before utilizing any mechanism in this family. Hash agility is provided in the family of mechanisms through the specification of additional mechanisms. To avoid requiring server implementations maintain access to the user's password, a password equivalent is used. The password equivalent is a simple hash of the password. While it is likely that those choosing to store the password equivalent instead of the password would prefer the equilavent be designed to hinder dictionary attack with precomputed direction entries, a simple hash was choosen to avoid adding a server challedge. Use of the autchid as a salt was considered, but rejected as it would tie the password equivalent to a particular authcid. It was also realized that it likely that implementors would (continue to) choose to store the password instead of a mechanism specific password equivalent. Storing the password avoids significant implementation complexity and facilates mechanism agility. 6. IANA Considerations It is requested that IANA process the following request(s) upon approval of this document for publication as an RFC. Subject: Registration of SASL YAP family of mechanisms SASL family name (or prefix for the family): YAP-* Security considerations: see RFC XXXX Published specification (recommended): RFC XXXX Person & email address to contact for further information: Kurt Zeilenga Intended usage: COMMON Owner/Change controller: IESG Subject: Registration of SASL YAP-SHA-256 mechanism Zeilenga draft-zeilenga-sasl-yap-01 [Page 5] INTERNET-DRAFT SASL YAP 8 July 2007 SASL mechanism (or prefix for the family): YAP-SHA-256 Security considerations: see RFC XXXX Published specification (recommended): RFC XXXX Person & email address to contact for further information: Kurt Zeilenga Intended usage: COMMON Owner/Change controller: IESG 7. Acknowledgments TBD. 8. Author's Address Kurt D. Zeilenga Isode Limited Email: Kurt.Zeilenga@Isode.COM 9. References 9.1. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14 (also RFC 2119), March 1997. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629 (also STD 63), November 2003. [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005. [RFC4422] Melnikov, A. (Editor), K. Zeilenga (Editor), "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006. [FIPS180-2] National Institute of Standards and Technology, "Secure Hash Algorithm. NIST FIPS 180-2", August 2002. [CBIND] draft-ietf-nfsv4-channel-bindings Zeilenga draft-zeilenga-sasl-yap-01 [Page 6] INTERNET-DRAFT SASL YAP 8 July 2007 [CBIND-TLS] draft-altman-tls-channel-bindings 9.2. Informative References [RFC2195] Klensin, J., R. Catoe, and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997. [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000. [RFC4346] Dierks, T. and, E. Rescorla, "The TLS Protocol Version 1.1", RFC 4346, April 2006. [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006. [RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, August 2006. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at Zeilenga draft-zeilenga-sasl-yap-01 [Page 7] INTERNET-DRAFT SASL YAP 8 July 2007 ietf-ipr@ietf.org. Full Copyright Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Zeilenga draft-zeilenga-sasl-yap-01 [Page 8]