[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00
Network Working Group D. Cridland
Internet-Draft A. Melnikov
Expires: August 30, 2007 Isode Limited
February 26, 2007
The Hash Exchange Authentication SASL Mechanism
draft-cridland-sasl-hexa-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 August 30, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This memo defines and discusses a SASL mechanism that is based on the
exchange of hashes. It does not require the storage of a plaintext
equivalent on the server, is simple to implement, and provides a
reasonable level of security.
Cridland & Melnikov Expires August 30, 2007 [Page 1]
Internet-Draft SASL HEXA February 2007
Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. Deployability . . . . . . . . . . . . . . . . . . . . 3
2.1.2. Hash Agility . . . . . . . . . . . . . . . . . . . . . 3
2.1.3. Ease of Implementation . . . . . . . . . . . . . . . . 4
3. Notations and Definitions . . . . . . . . . . . . . . . . . . 4
3.1. HMAC and Hash functions . . . . . . . . . . . . . . . . . 4
3.1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Wire Message Format . . . . . . . . . . . . . . . . . . . 5
3.3. Prior Setup . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Authentication Process . . . . . . . . . . . . . . . . . . 5
3.4.1. Initial client message . . . . . . . . . . . . . . . . 5
3.4.2. Server challenge message . . . . . . . . . . . . . . . 6
3.4.3. Client response message . . . . . . . . . . . . . . . 6
3.4.4. Server Authentication and Mutual Auth . . . . . . . . 6
4. Mandatory to Implement . . . . . . . . . . . . . . . . . . . . 7
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Plaintext Equivalents . . . . . . . . . . . . . . . . . . 8
6.2. Hash algorithm usage . . . . . . . . . . . . . . . . . . . 8
6.3. Resistance to attacks . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Cridland & Melnikov Expires August 30, 2007 [Page 2]
Internet-Draft SASL HEXA February 2007
1. 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 [KEYWORDS].
2. Introduction
Although other hash-based [SASL] mechanisms exist, they are being
rapidly outdated by advances in computing speed and the discovery of
weaknesses in hash functions. Moreover, both [CRAM-MD5] and
[DIGEST-MD5] involve the server having plaintext equivalents in the
shared secret store.
This mechanism was borne out of a percieved need within the system
administration community to have a mechanism which was both easier to
implement and also safer than [DIGEST-MD5].
2.1. Rationale
HEXA is specifically aimed at providing three key features.
2.1.1. Deployability
HEXA is designed to be acceptable to deploy in the real world. Its
authentication database is designed such that it may be used directly
for local logins, effectively having the same properties as a typical
/etc/shadow file on UNIX systems. This allows HEXA to co-exist with
very well deployed mechanisms such as [PLAIN], freeing the need for
transitioning.
2.1.2. Hash Agility
Hash algorithms have an alarming tendancy to age. It is therefore
beneficial to allow a server administrator to switch hash algorithms.
This is only practical, however, when it is known that the new hash
algorithm can be well supported by the clients in use. Where the
clients are out of the control of the administrator, for example in
typical commercial settings, it is useful for the administrator to be
aware of what the current deployed base is able to use.
Therefore, in HEXA, clients advertise their capability to the server,
allowing a server administrator to upgrade the hash algorithm as
required.
Cridland & Melnikov Expires August 30, 2007 [Page 3]
Internet-Draft SASL HEXA February 2007
2.1.3. Ease of Implementation
In general, [DIGEST-MD5] has been found to be difficult to implement
interoperably. Even well known implementations have been found to
have interoperability problems under some circumstances. HEXA
attempts to tackle this by using a small number of operation types,
and simple parsing. This allows for simple scripting languages to
implement, as well as using hash algorithms and related functions
that are known to be well deployed.
Since no mechanism can be considered secure in practise if no
implementations exist, this specification chooses easily available
pre-existing source code above stronger, less well implemented
algorithms.
3. Notations and Definitions
3.1. HMAC and Hash functions
This specification requires the use of [HMAC], based on hash
functions such as [MD5], SHA1, or SHA-256.
Messages are shown in plain text, with the CR LF pair shown as a line
ending.
Mandatory to implement hashes are discussed in Section 4, and are
considered volatile parts of this specification, very likely to
change in future revisions of this specification.
3.1.1. Notation
We use a relatively simple notation to show the calculations
involved:
HASH(T)
An agreed hash algorithm, used to produce a cryptographically
secure hash of the input data T.
HMAC(K,T)
An [HMAC] function used with an agreed hash function, used to
produce a MAC for T with a key of K.
HMAC[n](K,T)
Where n is an integer, expands to HMAC(HMAC[n-1](K,T),T).
HMAC[1](K,T) is equivalent to HMAC(K,T).
Q + W
Where Q and W are strings, represents simple concatenation.
Cridland & Melnikov Expires August 30, 2007 [Page 4]
Internet-Draft SASL HEXA February 2007
Q ^ W
Where Q and W are strings, represents an octet by octet XOR.
SASLprep(X)
Where X is a string, represents the application of the [SASLPREP]
algorithm to the string.
3.2. Wire Message Format
HEXA uses a wire format based on a simplified variant of email
message header formats, and only transfers text. No folding or
encoding is required or allowed.
The message contains keys and values, where each key appears a
maximum of once. Keys consist of ASCII letters, numbers, and the
hyphen character. Values contain UTF-8, and begin with a non-space
character. They never contain NUL, CR, or LF. Each Key Value pair
ends with a CR LF pair.
Keys appear first, followed by a single colon (":"), followed by the
value. Any surrounding spaces are considered part of the value.
3.3. Prior Setup
The client is assumed to have an Authcid, an optional Authzid, and a
Password.
The server has a Realm, and a database keyed against Authcid
containing a Salt, and hash output known as the Verifier.
Verifier := HMAC[n](Intermediate, Salt)
Intermediate := HMAC[n](Realm + SASLprep(Authcid)
+ SASLprep(Password), Salt)
The server's database is initially populated before authentication by
temporarily calculating the Intermediate from the supplied Password,
and choosing a new Salt. A new Salt SHOULD be used whenever the
Password is changed. The hash algorithm used is also remembered by
the server - servers MAY use multiple hash algorithms.
After calculating and storing the Verifier, the Intermediate MUST be
discarded.
3.4. Authentication Process
3.4.1. Initial client message
Initially, the client sends a message containing Authcid, optionally
Authzid, a list of hash algorithm names it supports, and some random
Cridland & Melnikov Expires August 30, 2007 [Page 5]
Internet-Draft SASL HEXA February 2007
data to use as a client nonce, this message is ClientMessage:
Authcid:mel
Hashes:MD5 SHA1 SHA-256
Client-Nonce:laksjdoijcosijdv
Channel-Bindings:TLS
3.4.2. Server challenge message
The server looks up Authcid in its database, selects the strongest
hash algorithm mutually supported, and returns the hash algorithm,
the number of cycles it uses, and the value of Salt. It also creates
some random data for use as a server nonce. Because this MUST be
textual, servers MAY base64 encode this data, however, this is an
implementation detail. The server sends the server nonce, Salt, and
Realm to the client, along with an indication of which channel
binding the server will use, if any:
Realm:example.net
Salt:aajvskjhvslkjdnvcn
Hash:MD5
Hash-Cycles:5
Server-Nonce:ksjdnclksdhufdh
Channel-Binding:TLS
3.4.3. Client response message
The client stores this message precisely as received, as
ServerMessage.
The client now calculates Intermediate and Verifier as above, and in
addition a hash Key, and a value Exchange, such that:
Key := HMAC[n](Verifier, ClientMessage
+ ServerMessage + ChannelBinding)
Exchange := Key ^ Intermediate
If there is no channel binding available that the server supports,
then ChannelBinding will be an empty string. Exchange is represented
as hex, and the result is sent to the server:
Hash-Exchange:1f2d...
3.4.4. Server Authentication and Mutual Auth
The server can now construct Key, extract Intermediate from Exchange,
and verify Intermediate against the stored hash output Verifier. In
order to prove to the client that it can do so, it sends the client a
Cridland & Melnikov Expires August 30, 2007 [Page 6]
Internet-Draft SASL HEXA February 2007
final message containing a hash output Authentication, such that:
Intermediate := Exchange ^ Key
Authentication := HMAC[n](Intermediate, ChannelBinding
+ ServerMessage + Salt + ClientMessage)
This has is sent to the client as:
Server-Auth:3f4d5a...
4. Mandatory to Implement
The rationale behind this mechanism is ease of deployment and
implementation, thus implementations MUST provide a configuration
which supports the [MD5] hash algorithm using a minimal number of
cycles of 16. Implementations SHOULD also support SHA-256.
This is because both [MD5], and [HMAC] implementations which are
hardcoded to use [MD5], are easily available in many languages and
environments.
5. Formal Syntax
Insert boilerplate about [ABNF] here.
wire-message = *key-value
key-value = key ":" value CRLF
key = ALPHA *( ALPHA / "-" / DIGIT )
value = utf8-text
utf8-text = 1*( VCHAR / SP / UTF-2 / UTF8-3 / UTF8-4 )
; visible UTF-8 or space.
hash-output = 1*( HEXDIG )
; Output of hash algorithm, generally 32 or more has digits.
; Following productions all conform to wire-message:
client-init-message = authcid [ authzid ] hashes client-nonce
[ channel-bindings ] *( extension )
server-challenge-message = realm hash hash-cycles server-nonce
[ channel-binding ] *( extension )
client-response-message = hash-exchange *( extension )
server-auth-message = server-auth *( extension )
; Following productions all conform to key-value:
; client-init-message:
Cridland & Melnikov Expires August 30, 2007 [Page 7]
Internet-Draft SASL HEXA February 2007
authcid = "Authcid" ":" utf8text CRLF
authzid = "Authzid" ":" utf8text CRLF
; SASLPrepped authcid/authzid.
hashes = "Hashes" ":" hash-name *( SP hash-name ) CRLF
client-nonce = "Client-Nonce" ":" utf8text CRLF
; MUST be generated afresh with reasonable entropy.
channel-bindings = "Channel-Bindings" ":" channel-binding-name
*( SP channel-binding-name ) CRLF
; server-challenge-message:
realm = "Realm" ":" utf8text CRLF
hash = "Hash" ":" hash-name CRLF
hash-cycles = "Cycles" ":" 1*( DIGIT ) CRLF
server-nonce = "Server-Nonce" ":" utf8text CRLF
; MUST be generated afresh with reasonable entropy.
channel-binding = "Channel-Binding:" ":" channel-binding-name CRLF
; client-response-message:
hash-exchange = "Hash-Exchange" ":" hash-output CRLF
; server-auth-message:
server-auth = "Server-Auth" ":" hash-output CRLF
; Values:
channel-binding-name = ALPHA *( ALPHA / DIGIT / "-" )
hash-name = ALPHA *( ALPHA / DIGIT / "-" )
; Extensions:
extension = key-value
6. Security Considerations
6.1. Plaintext Equivalents
The intermediate hash B is a plaintext equivalent. Clients SHOULD
NOT store this, and MUST NOT store the original plaintext password.
Servers MUST NOT store B.
6.2. Hash algorithm usage
In general, it is thought that the recursive application of hash
functions increases the strength of a hash. In particular, if the
hash has no weaknesses at all, merely doubling the number of
iterations will cause an offline dictionary attack to take twice as
much CPU resource. Making this a variable, negotiated, factor allows
very simple increases in security, as long as the hash algorithm
itself is not compromised sufficiently that a non-brute-force attack
Cridland & Melnikov Expires August 30, 2007 [Page 8]
Internet-Draft SASL HEXA February 2007
becomes practical.
The exact hash algorithm used may be changed by live deployments.
HEXA provides a simple method for server administrators to discover
actual availability of new hash algorithms in clients, simplifying a
hash algorithm change.
6.3. Resistance to attacks
HEXA is thought to be resistent to slightly more attacks than
[DIGEST-MD5]:
Downgrade
Assuming that HEXA can be negotiated at all, a downgrade attack
inside HEXA cannot be mounted, as complete messages are used as
input to the hashing functions - a man-in-the-middle attack will
cause the authentication to fail.
Server based attack
Merely obtaining the authentication database will not directly
allow an attcker to authenticate masquerading as a legitimate user
without substantial offline dictionary attacks. However, if an
attacker can both obtain the authentication database and observe
traffic on the wire, then the attacker can obtain B. As with
[DIGEST-MD5], this will not yield the password without an
expensive offline-dictionary attack.
Client based attack
Clients typically store sufficient data to reauthenticate later
without interactively requesting passwords from the user. Like
[DIGEST-MD5], clients need not store the actual password, but can
merely store B for this purpose. This practise is not
recommended, as an attacker obtaining B can authenticate as the
user.
7. References
7.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Cridland & Melnikov Expires August 30, 2007 [Page 9]
Internet-Draft SASL HEXA February 2007
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[SASLPREP]
Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, February 2005.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
7.2. Informative References
[CRAM-MD5]
Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response",
RFC 2195, September 1997.
[DIGEST-MD5]
Leach, P. and C. Newman, "Using Digest Authentication as a
SASL Mechanism", RFC 2831, May 2000.
[PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4616, August 2006.
Authors' Addresses
Dave Cridland
Isode Limited
5 Castle Business Village
36, Station Road
Hampton, Middlesex TW12 2BX
GB
Email: dave.cridland@isode.com
Cridland & Melnikov Expires August 30, 2007 [Page 10]
Internet-Draft SASL HEXA February 2007
Alexey Melnikov
Isode Limited
5 Castle Business Village
36, Station Road
Hampton, Middlesex TW12 2BX
GB
Email: alexey.melnikov@isode.com
Cridland & Melnikov Expires August 30, 2007 [Page 11]
Internet-Draft SASL HEXA February 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).
Cridland & Melnikov Expires August 30, 2007 [Page 12]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/