draft-ietf-httpauth-scram-auth-11.txt   draft-ietf-httpauth-scram-auth-12.txt 
HTTPAUTH A. Melnikov HTTPAUTH A. Melnikov
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Intended status: Standards Track November 25, 2015 Intended status: Standards Track November 28, 2015
Expires: May 28, 2016 Expires: May 31, 2016
Salted Challenge Response (SCRAM) HTTP Authentication Mechanism Salted Challenge Response (SCRAM) HTTP Authentication Mechanism
draft-ietf-httpauth-scram-auth-11.txt draft-ietf-httpauth-scram-auth-12.txt
Abstract Abstract
The secure authentication mechanism most widely deployed and used by The authentication mechanism most widely deployed and used by
Internet application protocols is the transmission of clear-text Internet application protocols is the transmission of clear-text
passwords over a channel protected by Transport Layer Security (TLS). passwords over a channel protected by Transport Layer Security (TLS).
There are some significant security concerns with that mechanism, There are some significant security concerns with that mechanism,
which could be addressed by the use of a challenge response which could be addressed by the use of a challenge response
authentication mechanism protected by TLS. Unfortunately, the HTTP authentication mechanism protected by TLS. Unfortunately, the HTTP
Digest challenge response mechanism presently on the standards track Digest challenge response mechanism presently on the standards track
failed widespread deployment, and have had success only in limited failed widespread deployment, and have had success only in limited
use. use.
This specification describes a family of HTTP authentication This specification describes a family of HTTP authentication
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 28, 2016. This Internet-Draft will expire on May 31, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 13, line 47 skipping to change at page 13, line 47
sid = "sid=" token sid = "sid=" token
;; See token definition in RFC 7235. ;; See token definition in RFC 7235.
stale = "stale=" ( "true" / "false" ) stale = "stale=" ( "true" / "false" )
realm = "realm=" <as defined in RFC 7235> realm = "realm=" <as defined in RFC 7235>
8. Security Considerations 8. Security Considerations
If the authentication exchange is performed without a strong security If the authentication exchange is performed without a strong session
layer (such as TLS with data confidentiality), then a passive encryption (such as TLS with data confidentiality), then a passive
eavesdropper can gain sufficient information to mount an offline eavesdropper can gain sufficient information to mount an offline
dictionary or brute-force attack which can be used to recover the dictionary or brute-force attack which can be used to recover the
user's password. The amount of time necessary for this attack user's password. The amount of time necessary for this attack
depends on the cryptographic hash function selected, the strength of depends on the cryptographic hash function selected, the strength of
the password and the iteration count supplied by the server. SCRAM the password and the iteration count supplied by the server. SCRAM
allows the server/server administrator to increase the iteration allows the server/server administrator to increase the iteration
count over time in order to slow down the above attacks. (Note that count over time in order to slow down the above attacks. (Note that
a server that is only in posession of "StoredKey" and "ServerKey" a server that is only in posession of "StoredKey" and "ServerKey"
can't automatic increase the iteration count upon successful can't automatic increase the iteration count upon successful
authentication. Such increase would require resetting user's authentication. Such increase would require resetting user's
skipping to change at page 14, line 39 skipping to change at page 14, line 39
SCRAM does not negotiate a hash function to use. Hash function SCRAM does not negotiate a hash function to use. Hash function
negotiation is left to the HTTP authentication mechanism negotiation. negotiation is left to the HTTP authentication mechanism negotiation.
It is important that clients be able to sort a locally available list It is important that clients be able to sort a locally available list
of mechanisms by preference so that the client may pick the most of mechanisms by preference so that the client may pick the most
preferred of a server's advertised mechanism list. This preference preferred of a server's advertised mechanism list. This preference
order is not specified here as it is a local matter. The preference order is not specified here as it is a local matter. The preference
order should include objective and subjective notions of mechanism order should include objective and subjective notions of mechanism
cryptographic strength (e.g., SCRAM with a successor to SHA-1 may be cryptographic strength (e.g., SCRAM with a successor to SHA-1 may be
preferred over SCRAM with SHA-1). preferred over SCRAM with SHA-1).
SCRAM does not protect against downgrade attacks of channel binding
types. The complexities of negotiation a channel binding type, and
handling down-grade attacks in that negotiation, was intentionally
left out of scope for this document.
A hostile server can perform a computational denial-of-service attack A hostile server can perform a computational denial-of-service attack
on clients by sending a big iteration count value. on clients by sending a big iteration count value.
See [RFC4086] for more information about generating randomness. See [RFC4086] for more information about generating randomness.
This document recommends use of SCRAM with SHA-256 hash. SCRAM-SHA-1
is registered for database compatibility with implementations of RFC
5802 (such as IMAP or XMPP servers) which want to also expose HTTP
access to a related service, but it is not recommended for new
deployments.
9. IANA Considerations 9. IANA Considerations
New mechanisms in the SCRAM- family are registered according to the New mechanisms in the SCRAM- family are registered according to the
IANA procedure specified in [RFC5802]. IANA procedure specified in [RFC5802].
Note to future SCRAM- mechanism designers: each new SCRAM- HTTP Note to future SCRAM- mechanism designers: each new SCRAM- HTTP
authentication mechanism MUST be explicitly registered with IANA and authentication mechanism MUST be explicitly registered with IANA and
MUST comply with SCRAM- mechanism naming convention defined in MUST comply with SCRAM- mechanism naming convention defined in
Section 4 of this document. Section 4 of this document.
 End of changes. 7 change blocks. 
12 lines changed or deleted 13 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/