One document matched: draft-josefsson-password-auth-00.txt
Network Working Group S. Josefsson
Internet-Draft March 28, 2007
Intended status: Standards Track
Expires: September 29, 2007
A Password-based Authentication Protocol
draft-josefsson-password-auth-00
Status of this Memo
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 September 29, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Josefsson Expires September 29, 2007 [Page 1]
Internet-Draft A Password-based Authentication Protocol March 2007
Abstract
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 and, using the GS2
framework, how it may 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in this Document . . . . . . . . . . . . . . 4
3. Wire Protocol . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Challenge Token . . . . . . . . . . . . . . . . . . . . . 5
3.2. Response . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Mandatory to implement algorithm: HMAC-SHA-256 . . . . . . . . 7
4.1. HMAC-SHA-256 Challenge . . . . . . . . . . . . . . . . . . 7
4.2. HMAC-SHA-256 Response . . . . . . . . . . . . . . . . . . 7
5. Using the protocol with GSS-API . . . . . . . . . . . . . . . 9
5.1. How Applications Specify the Password . . . . . . . . . . 9
6. Using the protocol with SASL . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Josefsson Expires September 29, 2007 [Page 2]
Internet-Draft A Password-based Authentication Protocol March 2007
1. Introduction
Several application protocols, for example SMTP and IMAP, use the
Simple Authentication and Security Layer (SASL) [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 [2], 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)
[5] mechanism described in this document, when used with the GS2 [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.
Josefsson Expires September 29, 2007 [Page 3]
Internet-Draft A Password-based Authentication Protocol March 2007
2. Conventions Used in this Document
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].
Josefsson Expires September 29, 2007 [Page 4]
Internet-Draft A Password-based Authentication Protocol March 2007
3. Wire Protocol
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.
3.1. Challenge Token
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]
Josefsson Expires September 29, 2007 [Page 5]
Internet-Draft A Password-based Authentication Protocol March 2007
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-
endien order (i.e., most significant byte first) denoting the length
of the "channel_binding" field.
The "channel_binding" contains the channel binding data. See [2] for
more information.
The "challenge" field contains the challenge data associated with the
algorithm indicated by the "algorithm_identifier" field.
3.2. Response
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.
Josefsson Expires September 29, 2007 [Page 6]
Internet-Draft A Password-based Authentication Protocol March 2007
4. Mandatory to implement algorithm: HMAC-SHA-256
Implementations MUST support the HMAC-SHA-256 algorithm. It is based
on HMAC [3] and SHA-256 [4]. The "algorithm_identifier" value for it
is:
algorithm algorithm_identifier (in HEX)
------------ -----------------------------
HMAC-SHA-256 06BC12783278CBBC2783CBBA9832892389
4.1. HMAC-SHA-256 Challenge
The "challenge" field MUST consist of 32 bytes of random data.
4.2. HMAC-SHA-256 Response
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-endien 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
Josefsson Expires September 29, 2007 [Page 7]
Internet-Draft A Password-based Authentication Protocol March 2007
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. ]
Josefsson Expires September 29, 2007 [Page 8]
Internet-Draft A Password-based Authentication Protocol March 2007
5. Using the protocol with GSS-API
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 consits 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.]
5.1. How Applications Specify the Password
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]. [XXX]
Josefsson Expires September 29, 2007 [Page 9]
Internet-Draft A Password-based Authentication Protocol March 2007
6. Using the protocol with SASL
The GS2 [7] framework can use the GSS-API mechanism based on this
protocol directly.
The GS2 mechanism name for the HMAC-SHA-256 mandatory algorithm is
computed from the OID, and is "GS2-TBC".
Josefsson Expires September 29, 2007 [Page 10]
Internet-Draft A Password-based Authentication Protocol March 2007
7. IANA Considerations
None
Josefsson Expires September 29, 2007 [Page 11]
Internet-Draft A Password-based Authentication Protocol March 2007
8. Security Considerations
TBA
Josefsson Expires September 29, 2007 [Page 12]
Internet-Draft A Password-based Authentication Protocol March 2007
9. Copying conditions
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.
Josefsson Expires September 29, 2007 [Page 13]
Internet-Draft A Password-based Authentication Protocol March 2007
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Williams, N., "On the Use of Channel Bindings to Secure
Channels", draft-williams-on-channel-binding-00 (work in
progress), August 2006.
[3] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[4] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-2, August 2002,
<http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2.pdf>.
10.2. Informative References
[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.
Josefsson Expires September 29, 2007 [Page 14]
Internet-Draft A Password-based Authentication Protocol March 2007
Author's Address
Simon Josefsson
Email: simon@josefsson.org
Josefsson Expires September 29, 2007 [Page 15]
Internet-Draft A Password-based Authentication Protocol March 2007
Full Copyright Statement
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.
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
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Josefsson Expires September 29, 2007 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-21 18:02:56 |