| TOC |
|
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 22, 2008.
Copyright © The IETF Trust (2007).
There is a lack of a simple, standardized, secure and modern password-based mechanism for user authentication in application protocols. This document specify a challenge/response protocol that provide password-based authentication services. We describe how the protocol may be used as a GSS-API mechanism. Via the GS2 framework, it can also be used as a SASL mechanism. The protocol supports HMAC-SHA-256 as the mandatory to implement algorithm, and it supports channel bindings. The intended use is by application protocol that today use CRAM-MD5 or DIGEST-MD5 via SASL, or by GSS-API applications that needs a password based method. The protocol is applicable to other environments, such as EAP, should the need arise.
See <http://josefsson.org/password/> for more information.
1.
Introduction
2.
Conventions Used in this Document
3.
Wire Protocol
3.1.
Challenge Token
3.2.
Response
4.
Mandatory to implement algorithm: HMAC-SHA-256
4.1.
HMAC-SHA-256 Challenge
4.2.
HMAC-SHA-256 Response
5.
Using the protocol with GSS-API
5.1.
How Applications Specify the Password
6.
SASL GS2 Mechanism Name
7.
IANA Considerations
8.
Security Considerations
9.
Copying conditions
10.
References
10.1.
Normative References
10.2.
Informative References
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
Several application protocols, for example SMTP and IMAP, use the Simple Authentication and Security Layer (SASL) (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.) [6] for user authentication. The SASL framework supports several authentication mechanisms based on different technologies. Authentication based on a username and password may use the TLS+EXTERN, TLS+PLAIN, CRAM-MD5, DIGEST-MD5 or the Kerberos V5 mechanism. Other mechanisms are (to my knowledge) not standardized nor widely deployed.
A quick overview of some perceived disadvantages with the current options:
TLS+EXTERN lack support for channel bindings, and TLS-SRP is not widely recognized thus leaving TLS without any password based authentication mechanism.
TLS+PLAIN lack support for channel bindings (Williams, N., “On the Use of Channel Bindings to Secure Channels,” November 2007.) [4], and it transmits the password to the peer, which is considered sub-optimal from a security perspective.
CRAM-MD5 lack support for channel bindings, authorization identities, and is based on the deprecated MD5 hash algorithm.
DIGEST-MD5 is based on the deprecated MD5 hash algorithm, and does not use HMAC or a similar widely studied hash-based authentication mode.
Kerberos V5 requires that there is a Kerberos V5 infrastructure in place, and needs out-of-band (from the application protocol's point of view) communication.
The Generic Security Service Application Program Interface (GSS-API) (Linn, J., “Generic Security Service Application Program Interface Version 2, Update 1,” January 2000.) [5] mechanism described in this document, when used with the GS2 (Josefsson, S., “Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family,” February 2007.) [7] SASL mechanism, provides channel bindings, authorization identity, hash agility with initial support for HMAC-SHA-256, and will not reveal the password to the peer.
Finally, we note that the GSS-API framework currently do not have any password-based standard mechanism, and this document provides one.
| TOC |
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 [1] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
The term "big-endian" is used for brevity to refer to the most-significant-octet-first encoding of integers in binary structures.
| TOC |
This section describes the format of the tokens which are exchanged between the client and the server.
The protocol consists of one challenge packet, sent from the server to the client, and one response packet, send from the client to the server.
For compatibility with the GSS-API framework, the challenge is prefixed with the mechanism-independent token format, as described by RFC 2743 section 3.1. This description is self-contained and you need not implement GSS-API to support this protocol.
The protocol does not specify control messages to signal (un)successful authentication to the peer. It is anticipated that this protocol will be used in other authentication protocols or frameworks that has sufficient signalling capabilities. This is true for GSS-API, SASL and EAP. If a need arise to specify control messages, the protocol is flexible and allows this do be made inside a specific algorithm.
| TOC |
The challenge is sent from the server to the client, and its format is illustrated below.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x60 | length... /
/ algorithm_identifier /
/ channel_binding_length |
/ channel_binding |
/ challenge |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first byte is fixed to 0x60.
The "length" field contains the sum of the lengths of the "algorithm_identifier" and "challenge" fields. The length is encoded as a DER length values.
For reference, DER length value encoding means that for lengths less than 128, it shall be represented in a single octet with bit 8 (high order) set to "0" and the remaining bits representing the value. If the indicated value is 128 or more, it shall be represented in two or more octets, with bit 8 of the first octet set to "1" and the remaining bits of the first octet specifying the number of additional octets. The subsequent octets carry the value, 8 bits per octet, most significant digit first. The minimum number of octets shall be used to encode the length (i.e., no octets representing leading zeros shall be included within the length encoding).
[XXX: Add example code to encode/decode DER lengths]
The "algorithm_identifier" contains a fixed string that correspond to the algorithm which is used. The strings will be DER encoded Object Identifiers (including the DER tag and length) but it is suggested that implementations compare the field against known supported algorithms.
The "channel_binding_length" is a 4 byte integer encoded in big-endian order (i.e., most significant byte first) denoting the length of the "channel_binding" field.
The "channel_binding" contains the channel binding data. See [4] (Williams, N., “On the Use of Channel Bindings to Secure Channels,” November 2007.) for more information.
The "challenge" field contains the challenge data associated with the algorithm indicated by the "algorithm_identifier" field.
| TOC |
The response is sent from the client to the server, and its format is illustrated below.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ response /
/ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "response" field contains the response for the given challenge. Its format depends on the "algorithm_identifier" used.
| TOC |
Implementations MUST support the HMAC-SHA-256 algorithm. It is based on HMAC (Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” February 1997.) [2] and SHA-256 (National Institute of Standards and Technology, “Secure Hash Standard,” August 2002.) [3]. The "algorithm_identifier" value for it is:
algorithm algorithm_identifier (in HEX)
------------ -----------------------------
HMAC-SHA-256 06092B06010401DA470401
| TOC |
The "challenge" field MUST consist of 32 bytes of random data.
| TOC |
The "response" field is structured, illustrated as follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ hmac_response (32 bytes) /
/ |
| authentication_identity_length |
| /
/ authentication_identity /
/ /
/ [authorization_identity] /
/ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "hmac_response" MUST consist of the output from the HMAC-SHA-256 algorithm using the "challenge" as input and the password as "key". The size is always 32 bytes.
The "authentication_identity_length" is a 4 byte integer encoded in big-endian order (i.e., most significant byte first) denoting the length of the "authentication_identity" field.
The "authentication_identity" is a variable-length field (the length is in "authentication_identity_length") which contains an authentication identity.
The "authorization_identity" is a variable-length field; its length can be deduced from "authentication_identity_length" and the size of the entire structure. In particular, if there is data left in the structure after the "authentication_identity" field, the data constitutes the "authorization_identity".
[XXX: Use PKCS#5 PBKDF2? The username could be salt. The problem is that we need to send the iteration length over the wire too, which complicate things.]
[XXX: Support stored hashed password on the server. For example, the "key" stored on the server wouldn't have to be the password straight, it could be a hashed value, possibly the PBKDF2 output, based on the authid and password. ]
| TOC |
The Challenge Token has the necessary format to serve as a mechanism-independent GSS-API Request Token. The Response Token serve as the GSS-API Response Token. The protocol consists only of one round-trip. Calling GSS_Init_sec_context will return the Challenge Token with a GSS_S_CONTINUE_NEEDED status return. Passing the token to GSS_Accept_sec_context will either lead to a GSS_S_COMPLETE status return or a failure (thus, in particular, it will never lead to a GSS_S_CONTINUE_NEEDED status return).
The HMAC-SHA-256 value is derived from the registered Object Identifier 1.3.6.1.4.1.11591.4.1.
[XXX: Discuss GSS-API flags.]
| TOC |
The GSS-API framework does not deal with initial acquisation of credentials. Thus, how application set the password that the GSS-CRAM implementation will use is outside of the scope of GSS-API.
However, this particular GSS-API design choice seriously limits the usefulness of this mechanism, therefor it is considered whether to mandate, for use with GSS-CRAM, a specific method for applications to set the password. One option here would be [8] (Ts'o, T., “GSS Conversation C-bindings Interface,” .). [XXX]
| TOC |
The GS2 (Josefsson, S., “Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family,” February 2007.) [7] framework can use the GSS-API mechanism based on this protocol directly.
The OID is 1.3.6.1.4.1.11591.4.1. The ASN.1 DER encoding of the OID, including the tag and length, is (in hex) 06 09 2B 06 01 04 01 DA 47 04 01. The SHA-1 hash of the ASN.1 DER encoding is (in hex) 3e 0d 90 8a 97 7b 6c da 9e 48 29 2b ca 63 7b 8d 9d 6b 96 d1. Convert the first ten octets to binary, and re-group them in groups of 5, and convert them back to decimal, which results in these computations:
hex: 3E 0D 90 8A 97 7B 6C DA 9E 48 binary: 00111110 00001101 10010000 10001010 10010111 01111011 01101100 11011010 10011110 01001000 binary in groups of 5: 00111 11000 00110 11001 00001 00010 10100 10111 01111 01101 10110 01101 10101 00111 10010 01000 decimal of each group: 7 24 6 25 1 2 20 23 15 13 22 13 21 7 18 8 base32 encoding: H Y G Z B C U X P N W N V H S I
The last step translate each decimal value using table 3 in Base32 [6]. Thus the SASL mechanism name for the HMAC-SHA-256 mechanism is "GS2-HYGZBCUXPNWNVHSI".
| TOC |
None
| TOC |
TBA
| TOC |
Regarding this entire document or any portion of it (including the pseudocode and C code), the author makes no guarantees and is not responsible for any damage resulting from its use. The author grants irrevocable permission to anyone to use, modify, and distribute it in any way that does not diminish the rights of anyone else to use, modify, and distribute it, provided that redistributed derivative works do not contain misleading author or version information. Derivative works need not be licensed under similar terms.
| TOC |
| TOC |
| [1] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [2] | Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” RFC 2104, February 1997. |
| [3] | National Institute of Standards and Technology, “Secure Hash Standard,” FIPS PUB 180-2, August 2002. |
| [4] | Williams, N., “On the Use of Channel Bindings to Secure Channels,” RFC 5056, November 2007. |
| TOC |
| [5] | Linn, J., “Generic Security Service Application Program Interface Version 2, Update 1,” RFC 2743, January 2000. |
| [6] | Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” RFC 4422, June 2006. |
| [7] | Josefsson, S., “Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family,” draft-ietf-sasl-gs2-06 (work in progress), February 2007. |
| [8] | Ts'o, T., “GSS Conversation C-bindings Interface,” WWW http://www3.ietf.org/proceedings/99nov/I-D/draft-ietf-cat-gss-conv-00.txt. |
| TOC |
| Simon Josefsson | |
| Email: | simon@josefsson.org |
| TOC |
Copyright © 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.
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 ietf-ipr@ietf.org.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).