doc/specification/draft-zeilenga-sasl-yap-00.txt

   1
   2
   3
   4
   5
   6
   7 INTERNET-DRAFT                                      Kurt D. Zeilenga
   8 Intended Category: Standards Track                  Isode Limited
   9 Expires in six months                               25 February 2007
  10
  11
  12
  13                    SASL Yet Another Password Mechanism
  14                      <draft-zeilenga-sasl-yap-00.txt>
  15
  16
  17
  18 Status of this Memo
  19
  20   This document is intended to be, after appropriate review and
  21   revision, submitted to the RFC Editor as a Standards Track document.
  22   Distribution of this memo is unlimited.  Technical discussion of this
  23   document will take place on the IETF SASL WG mailing list <ietf-
  24   sasl@imc.org>.  Please send editorial comments directly to the author
  25   <Kurt.Zeilenga@Isode.COM>.
  26
  27   By submitting this Internet-Draft, each author represents that any
  28   applicable patent or other IPR claims of which he or she is aware have
  29   been or will be disclosed, and any of which he or she becomes aware
  30   will be disclosed, in accordance with Section 6 of BCP 79.
  31
  32   Internet-Drafts are working documents of the Internet Engineering Task
  33   Force (IETF), its areas, and its working groups. Note that other
  34   groups may also distribute working documents as Internet-Drafts.
  35
  36   Internet-Drafts are draft documents valid for a maximum of six months
  37   and may be updated, replaced, or obsoleted by other documents at any
  38   time. It is inappropriate to use Internet-Drafts as reference material
  39   or to cite them other than as "work in progress."
  40
  41   The list of current Internet-Drafts can be accessed at
  42   http://www.ietf.org/1id-abstracts.html.
  43
  44   The list of Internet-Draft Shadow Directories can be accessed at
  45   http://www.ietf.org/shadow.html.
  46
  47
  48   Copyright (C) The IETF Trust (2007).  All Rights Reserved.
  49
  50   Please see the Full Copyright section near the end of this document
  51   for more information.
  52
  53
  54
  55
  56
  57
  58 Zeilenga               draft-zeilenga-sasl-yap-00               [Page 1]
  59 \f
  60 INTERNET-DRAFT                  SASL YAP                25 February 2007
  61
  62
  63 Abstract
  64
  65   This document describes a password authentication mechanism, called
  66   YAP-SHA-256, for use in protocols support Simple Authentication and
  67   Security Layer (SASL) framework.  The mechanism relies on security
  68   services provided by a lower layer, such as Transport Layer Security
  69   (TLS), to protect the authentication exchange, and subsequent
  70   application data exchange, from common attacks.  The YAP-SHA-256
  71   mechanism may be viewed as an alternative to other password-based SASL
  72   mechanism, such as PLAIN, CRAM-MD5, and DIGEST-MD5.
  73
  74
  75 1. Introduction
  76
  77   There exists multiple password-based methods for use in the Simple
  78   Authentication and Security Layer (SASL) [RFC4422] framework.  These
  79   include the PLAIN [RFC4616], CRAM-MD5 [RFC2195], and DIGEST-MD5
  80   [RFC2831].  None of these mechanisms, themselves, provide integrity
  81   and confidential protection over the entirety of the authentication
  82   exchange.  Only DIGEST-MD5 offers a security layer and, even so, the
  83   specification and implementations suffer from multiple problems.  And
  84   while these mechanisms may be used in conjunction with lower-level
  85   security services, these mechanism do not offer any facility to bind
  86   the channels [CBIND].
  87
  88   This situation has lead to multiple efforts to design "better" SASL
  89   password-based mechanism.  This document not only specifies yet
  90   another password mechanism, YAP-SHA-256, but defines a family of
  91   related password mechanisms.
  92
  93   The YAP is a family of simple password SASL mechanisms based upon the
  94   Keyed-Hash Message Authentication Code (HMAC) [RFC2104] algorithm.
  95   The YAP-SHA-256 utilizes the SHA-256 [FIPS180-2] cryptographic hash
  96   function in conjunction with the HMAC algorithm.  YAP is specified as
  97   a family of SASL mechanisms to provide hash agility.
  98
  99   YAP mechanisms reply on services provided at a lower level, such as
 100   Transport Layer Security (TLS) [RFC4346], to secure the authentication
 101   exchange and subsequent application data exchange and, hence,
 102   YAP-SHA-256 does not offer a SASL security layer.  YAP mechanisms
 103   requires the lower-level security layer to be bound [CBIND] in the
 104   authentication.
 105
 106
 107 1.1 Terminology
 108
 109   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 110   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 111
 112
 113
 114 Zeilenga               draft-zeilenga-sasl-yap-00               [Page 2]
 115 \f
 116 INTERNET-DRAFT                  SASL YAP                25 February 2007
 117
 118
 119   document are to be interpreted as described in BCP 14 [RFC2119].
 120
 121 2. The YAP-* Family of mechanism
 122
 123   Each mechanism in this family differs only by the choice of hash
 124   algorithm.  Each mechanism has a name of the form YAP-HASH where HASH
 125   is a string chosen to reflect the hash algorithm used.  To define a
 126   new mechanism within this family, the mechanism specification need
 127   only identify that it is a YAP mechanism, identify the hash algorithm
 128   used, and identify the name of the mechanism.  The name of the
 129   mechanism is to be registered as discussed in [RFC4422].
 130
 131   The mechanism involves a single message from the client to the server.
 132
 133       message = authcid separator [ authzid ] separator data
 134       separator = %x00
 135
 136   where:
 137       - <authcid> is authentication identity, a simple user name
 138         [RFC4013], prepared using the SASLprep [RFC4013] and represented
 139         in UTF-8 [RFC3629],
 140
 141       - <authzid>, when present, is the authorization identity in the
 142         form specified by the application protocol specification,
 143         represented in UTF-8 [RFC3629], and
 144
 145       - <data> is Base64 [RFC4648] encoding of a Keyed-Hash Message
 146         Authentication Code (HMAC) [RFC2104] produced as described
 147         below.
 148
 149   The mechanism-specific hash algorithm, such as SHA-256 [FIPS180-2], is
 150   used as the cryptographic hash function, H, in computing the HMAC.
 151   The secret key, K, is the unique channel bindings [CBIND] for the
 152   lower-level security protocol, padded with zero octets to the block
 153   size of the hash function.  Where the unique channel binding is longer
 154   than the block size of the hash function, K is hash of the unique
 155   channel bindings.  The text is the concatenation of the authcid, the
 156   authzid, and the hash of the concatenation of the authcid and user's
 157   password, a simple password [RFC4013], prepared using SASLprep
 158   [RFC4013], and represented in UTF-8 [RFC3629].  That is, the <data> is
 159   computed as illustrated by the following pseudo code.
 160
 161     Base64( HMAC(
 162       K( Pad( LEN(ChannelBindings)>HashBlockSize
 163         ? H(ChannelBindings) : ChannelBindings ), 0, HashBlockSize),
 164       Concat( authcid, authzid,
 165         H( authcid, UTF-8( SASLprep( password ))))))
 166
 167
 168
 169
 170 Zeilenga               draft-zeilenga-sasl-yap-00               [Page 3]
 171 \f
 172 INTERNET-DRAFT                  SASL YAP                25 February 2007
 173
 174
 175   The text encompasses all parameters of the exchange to ensure
 176   integrity of all parameters.
 177
 178   The text includes a hash encompassing the password, instead of the
 179   password itself, to allow the server to store this hash instead of the
 180   password.  This hash also encompasses the authcid to make it harder to
 181   mount dictionary attacks using pre-computed dictionary entries.
 182
 183   Implementations SHOULD NOT advertise availabilty of any mechanism in
 184   this family unless a lower-level security service provding both data
 185   integrity and data confidentiality protection is in place.  Client
 186   implementations SHOULD NOT utilize any mechanism in this family
 187   without first verifying the identity of the server within the
 188   lower-level security service.  Client implementors should consult the
 189   application protocol specification, in conjuction with the
 190   specification of the lower-level security service, for details on how
 191   to implement this verification.
 192
 193   Implementations MUST support Transport Security Layer (TLS) [RFC4346]
 194   channel bindings, as describe in [CBIND-TLS].
 195
 196
 197   3. The YAP-SHA256 Mechanism
 198
 199   The YAP-SHA-256 mechanism, named "YAP-SHA-256", is a YAP SASL
 200   mechanism.  The YAP-SHA-256 mechanism, as the name suggests, uses the
 201   SHA-256 [FIPS180-2][RFC4634] hash algorithm.
 202
 203
 204 4. Security Considerations
 205
 206   Security is discussed throughout this document.
 207
 208   This family of mechanisms was specifically designed to reply on
 209   security services offered at lower-levels to secure the authentication
 210   exchange and subsequent data exchanges.  To ensure lower-level
 211   security services are provided end-to-end, the mechanisms utilize
 212   channel bindings [CBIND].
 213
 214   To avoid disclosing the identity information to a rogue server, the
 215   client is to verify the server's identity using the lower-layer
 216   security service before utilizing any mechanism in this family.
 217
 218   Hash agility is provided in the family of mechanisms through the
 219   specification of additional mechanisms.
 220
 221
 222
 223
 224
 225
 226 Zeilenga               draft-zeilenga-sasl-yap-00               [Page 4]
 227 \f
 228 INTERNET-DRAFT                  SASL YAP                25 February 2007
 229
 230
 231 5. IANA Considerations
 232
 233   It is requested that IANA process the following request(s) upon
 234   approval of this document for publication as an RFC.
 235
 236       Subject: Registration of SASL YAP family of mechanisms
 237       SASL family name (or prefix for the family): YAP-*
 238       Security considerations: see RFC XXXX
 239       Published specification (recommended): RFC XXXX
 240       Person & email address to contact for further information:
 241            Kurt Zeilenga <kurt.zeilenga@isode.com>
 242       Intended usage: COMMON
 243       Owner/Change controller: IESG
 244
 245       Subject: Registration of SASL YAP-SHA-256 mechanism
 246       SASL mechanism (or prefix for the family): YAP-SHA-256
 247       Security considerations: see RFC XXXX
 248       Published specification (recommended): RFC XXXX
 249       Person & email address to contact for further information:
 250            Kurt Zeilenga <kurt.zeilenga@isode.com>
 251       Intended usage: COMMON
 252       Owner/Change controller: IESG
 253
 254
 255 6. Acknowledgments
 256
 257   TBD.
 258
 259
 260 7. Author's Address
 261
 262   Kurt D. Zeilenga
 263   Isode Limited
 264
 265   Email: Kurt.Zeilenga@Isode.COM
 266
 267
 268 8. References
 269
 270
 271 8.1. Normative References
 272
 273   [RFC2104]     Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
 274                 Keyed-Hashing for Message Authentication", RFC 2104,
 275                 February 1997.
 276
 277   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
 278                 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
 279
 280
 281
 282 Zeilenga               draft-zeilenga-sasl-yap-00               [Page 5]
 283 \f
 284 INTERNET-DRAFT                  SASL YAP                25 February 2007
 285
 286
 287   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
 288                 10646", RFC 3629 (also STD 63), November 2003.
 289
 290   [RFC4013]     Zeilenga, K., "SASLprep: Stringprep Profile for User
 291                 Names and Passwords", RFC 4013, February 2005.
 292
 293   [RFC4422]     Melnikov, A. (Editor), K. Zeilenga (Editor), "Simple
 294                 Authentication and Security Layer (SASL)", RFC 4422,
 295                 June 2006.
 296
 297   [RFC4648]     Josefsson, S., "The Base16, Base32, and Base64 Data
 298                 Encodings", RFC 4648, October 2006.
 299
 300
 301   [FIPS180-2]   National Institute of Standards and Technology, "Secure
 302                 Hash Algorithm. NIST FIPS 180-2", August 2002.
 303   [CBIND] draft-ietf-nfsv4-channel-bindings
 304
 305   [CBIND-TLS] draft-altman-tls-channel-bindings
 306
 307
 308 8.2. Informative References
 309
 310   [RFC2195]     Klensin, J., R. Catoe, and P. Krumviede, "IMAP/POP
 311                 AUTHorize Extension for Simple Challenge/Response", RFC
 312                 2195, September 1997.
 313
 314   [RFC2831]     Leach, P. and C. Newman, "Using Digest Authentication as
 315                 a SASL Mechanism", RFC 2831, May 2000.
 316
 317   [RFC4346]     Dierks, T. and, E. Rescorla, "The TLS Protocol Version
 318                 1.1", RFC 4346, April 2006.
 319
 320   [RFC4616]     Zeilenga, K., "The PLAIN Simple Authentication and
 321                 Security Layer (SASL) Mechanism", RFC 4616, August 2006.
 322
 323   [RFC4634]     Eastlake 3rd, D. and T. Hansen, "US Secure Hash
 324                 Algorithms (SHA and HMAC-SHA)", RFC 4634, August 2006.
 325
 326
 327
 328 Intellectual Property
 329
 330   The IETF takes no position regarding the validity or scope of any
 331   Intellectual Property Rights or other rights that might be claimed to
 332   pertain to the implementation or use of the technology described in
 333   this document or the extent to which any license under such rights
 334   might or might not be available; nor does it represent that it has
 335
 336
 337
 338 Zeilenga               draft-zeilenga-sasl-yap-00               [Page 6]
 339 \f
 340 INTERNET-DRAFT                  SASL YAP                25 February 2007
 341
 342
 343   made any independent effort to identify any such rights.  Information
 344   on the procedures with respect to rights in RFC documents can be found
 345   in BCP 78 and BCP 79.
 346
 347   Copies of IPR disclosures made to the IETF Secretariat and any
 348   assurances of licenses to be made available, or the result of an
 349   attempt made to obtain a general license or permission for the use of
 350   such proprietary rights by implementers or users of this specification
 351   can be obtained from the IETF on-line IPR repository at
 352   http://www.ietf.org/ipr.
 353
 354   The IETF invites any interested party to bring to its attention any
 355   copyrights, patents or patent applications, or other proprietary
 356   rights that may cover technology that may be required to implement
 357   this standard.  Please address the information to the IETF at
 358   ietf-ipr@ietf.org.
 359
 360
 361
 362 Full Copyright
 363
 364   Copyright (C) The IETF Trust (2007).
 365
 366   This document is subject to the rights, licenses and restrictions
 367   contained in BCP 78, and except as set forth therein, the authors
 368   retain all their rights.
 369
 370   This document and the information contained herein are provided on an
 371   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 372   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 373   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 374   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 375   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 376   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Zeilenga               draft-zeilenga-sasl-yap-00               [Page 7]
 395 \f