One document matched: draft-zeilenga-sasl-yap-01.txt

Differences from draft-zeilenga-sasl-yap-00.txt

INTERNET-DRAFT                                      Kurt D. Zeilenga
Intended Category: Standards Track                  Isode Limited
Expires in six months                               8 July 2007



                   SASL Yet Another Password Mechanism
                     <draft-zeilenga-sasl-yap-01.txt>



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 <ietf-
  sasl@imc.org>.  Please send editorial comments directly to the author
  <Kurt.Zeilenga@Isode.COM>.

  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:
      - <authzid>, when present, is the authorization identity in the
        form specified by the application protocol specification,
        represented in UTF-8 [RFC3629], and

      - <authcid> is authentication identity, a simple user name
        [RFC4013], prepared using the SASLprep [RFC4013] and represented
        in UTF-8 [RFC3629],

      - <data> 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 <data> 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 <kurt.zeilenga@isode.com>
      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 <kurt.zeilenga@isode.com>
      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]