draft-ietf-httpauth-scram-auth-00.txt   draft-ietf-httpauth-scram-auth-01.txt 
HTTPAUTH A. Melnikov HTTPAUTH A. Melnikov
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Intended status: Standards Track July 01, 2013 Intended status: Standards Track October 18, 2013
Expires: January 02, 2014 Expires: April 21, 2014
Salted Challenge Response (SCRAM) HTTP Authentication Mechanism Salted Challenge Response (SCRAM) HTTP Authentication Mechanism
draft-ietf-httpauth-scram-auth-00.txt draft-ietf-httpauth-scram-auth-01.txt
Abstract Abstract
The secure authentication mechanism most widely deployed and used by The secure 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
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 January 02, 2014. This Internet-Draft will expire on April 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 2, line 29 skipping to change at page 2, line 29
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 5 3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 5
4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 6 4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 6
5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7 5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7
5.1. SCRAM Attributes . . . . . . . . . . . . . . . . . . . . . 9 5.1. SCRAM Attributes . . . . . . . . . . . . . . . . . . . . . 9
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
10. Design Motivations . . . . . . . . . . . . . . . . . . . . . 16 10. Design Motivations . . . . . . . . . . . . . . . . . . . . . 16
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16
12. Internet-Draft Change History . . . . . . . . . . . . . . . . 16 12. Internet-Draft Change History . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17
13.2. Informative References . . . . . . . . . . . . . . . . . . 17 13.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Conventions Used in This Document 1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Formal syntax is defined by [RFC5234] including the core rules Formal syntax is defined by [RFC5234] including the core rules
skipping to change at page 8, line 19 skipping to change at page 8, line 19
"SCRAM-SHA-1" authentication starts with sending the "Authorization" "SCRAM-SHA-1" authentication starts with sending the "Authorization"
request header field defined by HTTP/1.1, Part 7 request header field defined by HTTP/1.1, Part 7
[I-D.ietf-httpbis-p7-auth] containing "SCRAM-SHA-1" authentication [I-D.ietf-httpbis-p7-auth] containing "SCRAM-SHA-1" authentication
scheme and the following attributes: scheme and the following attributes:
o A "realm" attribute MAY be included to indicate the scope of o A "realm" attribute MAY be included to indicate the scope of
protection in the manner described in HTTP/1.1, Part 7 protection in the manner described in HTTP/1.1, Part 7
[I-D.ietf-httpbis-p7-auth]. As specified in [I-D.ietf-httpbis-p7-auth]. As specified in
[I-D.ietf-httpbis-p7-auth], the "realm" attribute MUST NOT appear [I-D.ietf-httpbis-p7-auth], the "realm" attribute MUST NOT appear
more than once. more than once. The realm attribute only appears in the first
SCRAM message to the server and in the first SCRAM response from
the server.
o The client also includes the "client-first-message" containing: o The client also includes the "client-first-message" containing:
* a header ("g" attribute) consisting of a flag indicating * a header ("g" attribute) consisting of a flag indicating
whether channel binding is supported-but-not-used, not whether channel binding is supported-but-not-used, not
supported, or used ; supported, or used . Note that the "g" attribute always starts
with "n", "y" or "p", otherwise the message is invalid and
authentication MUST fail.
* SCRAM username and a random, unique nonce attributes. * SCRAM username and a random, unique nonce attributes.
Note that the client's first message will always start with "n",
"y" or "p", otherwise the message is invalid and authentication
MUST fail.
In HTTP response, the server sends WWW-Authenticate header field In HTTP response, the server sends WWW-Authenticate header field
containing: a unique session identifier (the "sid" attribute) plus containing: a unique session identifier (the "sid" attribute) plus
the "server-first-message" containing the user's iteration count i, the "server-first-message" containing the user's iteration count i,
the user's salt, and the nonce with a concatenation of the client- the user's salt, and the nonce with a concatenation of the client-
specified one with a server nonce. specified one with a server nonce.
The client then responds with another HTTP request with the The client then responds with another HTTP request with the
Authorization header field, which includes the "sid" attribute Authorization header field, which includes the "sid" attribute
received in the previous server response, together with "client- received in the previous server response, together with "client-
final-message" data. The latter has the same nonce and a ClientProof final-message" data. The latter has the same nonce and a ClientProof
skipping to change at page 13, line 14 skipping to change at page 13, line 14
iteration-count = "i=" posit-number iteration-count = "i=" posit-number
;; A positive number. ;; A positive number.
client-first-message-bare = client-first-message-bare =
[reserved-mext ","] [reserved-mext ","]
username "," nonce ["," extensions] username "," nonce ["," extensions]
client-first-message = client-first-message =
"g=" gs2-header client-first-message-bare "g=" gs2-header client-first-message-bare
;; Note that this doesn't include "realm" and
;; other generic HTTP directives.
server-first-message = server-first-message =
[reserved-mext ","] nonce "," salt "," [reserved-mext ","] nonce "," salt ","
iteration-count ["," extensions] iteration-count ["," extensions]
;; Note that this doesn't include "realm", "sid" and
;; other generic HTTP directives.
client-final-message-without-proof = client-final-message-without-proof =
channel-binding "," nonce ["," channel-binding "," nonce [","
extensions] extensions]
client-final-message = client-final-message =
client-final-message-without-proof "," proof client-final-message-without-proof "," proof
;; Note that this doesn't include "sid" and
;; other generic HTTP directives.
server-error = "e=" server-error-value server-error = "e=" server-error-value
server-error-value = "invalid-encoding" / server-error-value = "invalid-encoding" /
"extensions-not-supported" / ; unrecognized 'm' value "extensions-not-supported" / ; unrecognized 'm' value
"invalid-proof" / "invalid-proof" /
"channel-bindings-dont-match" / "channel-bindings-dont-match" /
"server-does-support-channel-binding" / "server-does-support-channel-binding" /
; server does not support channel binding ; server does not support channel binding
"channel-binding-not-supported" / "channel-binding-not-supported" /
 End of changes. 11 change blocks. 
12 lines changed or deleted 18 lines changed or added

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