draft-ietf-httpauth-scram-auth-03.txt   draft-ietf-httpauth-scram-auth-04.txt 
HTTPAUTH A. Melnikov HTTPAUTH A. Melnikov
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Intended status: Standards Track July 4, 2014 Intended status: Standards Track November 10, 2014
Expires: January 5, 2015 Expires: May 14, 2015
Salted Challenge Response (SCRAM) HTTP Authentication Mechanism Salted Challenge Response (SCRAM) HTTP Authentication Mechanism
draft-ietf-httpauth-scram-auth-03.txt draft-ietf-httpauth-scram-auth-04.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 5, 2015. This Internet-Draft will expire on May 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
Table of Contents Table of Contents
1. Conventions Used in This Document . . . . . . . . . . . . . . 2 1. Conventions Used in This Document . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 6 3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 6
4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 7 4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 7
5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7 5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7
5.1. Example reauthentication . . . . . . . . . . . . . . . . . 9 5.1. One round trip reauthentication . . . . . . . . . . . . . . 10
5.2. SCRAM Attributes . . . . . . . . . . . . . . . . . . . . . 10 5.2. SCRAM Attributes . . . . . . . . . . . . . . . . . . . . . 11
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
10. Design Motivations . . . . . . . . . . . . . . . . . . . . . 17 10. Design Motivations . . . . . . . . . . . . . . . . . . . . . 19
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19
12. Internet-Draft Change History . . . . . . . . . . . . . . . . 18 12. Internet-Draft Change History . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 13.1. Normative References . . . . . . . . . . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
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
defined in Appendix B of [RFC5234]. defined in Appendix B of [RFC5234].
skipping to change at page 7, line 18 skipping to change at page 7, line 18
Section 6. Section 6.
4. SCRAM Mechanism Names 4. SCRAM Mechanism Names
A SCRAM mechanism name (authentication scheme) is a string "SCRAM-" A SCRAM mechanism name (authentication scheme) is a string "SCRAM-"
followed by the uppercased name of the underlying hash function taken followed by the uppercased name of the underlying hash function taken
from the IANA "Hash Function Textual Names" registry (see from the IANA "Hash Function Textual Names" registry (see
http://www.iana.org) . http://www.iana.org) .
For interoperability, all HTTP clients and servers supporting SCRAM For interoperability, all HTTP clients and servers supporting SCRAM
MUST implement the SCRAM-SHA-1 authentication mechanism, i.e. an MUST implement the SCRAM-SHA-1 authentication mechanism, [[CREF1:
authentication mechanism from the SCRAM family that uses the SHA-1 OPEN ISSUE: Possibly switch to SHA-256 as the mandatory-to-
hash function as defined in [RFC3174]. implement.]] i.e. an authentication mechanism from the SCRAM family
that uses the SHA-1 hash function as defined in [RFC3174].
5. SCRAM Authentication Exchange 5. SCRAM Authentication Exchange
SCRAM is a HTTP Authentication mechanism whose client response SCRAM is a HTTP Authentication mechanism whose client response
(<credentials-scram>) and server challenge (<challenge-scram>) (<credentials-scram>) and server challenge (<challenge-scram>)
messages are text-based messages containing one or more attribute- messages are text-based messages containing one or more attribute-
value pairs separated by commas. Each attribute has a one-letter value pairs separated by commas. Each attribute has a one-letter
name, with the exception of a couple of attributes which are generic name, with the exception of a couple of attributes which are generic
to HTTP authentication, such as "realm" (and "sid"). The messages to HTTP authentication, such as "realm" (and "sid"). The messages
and their attributes are described in Section 5.2, and defined in and their attributes are described in Section 5.2, and defined in
skipping to change at page 8, line 49 skipping to change at page 8, line 49
S: HTTP/1.1 200 Ok S: HTTP/1.1 200 Ok
S: Authentication-Info: SCRAM-SHA-1 S: Authentication-Info: SCRAM-SHA-1
sid=AAAABBBBCCCCDDDD, sid=AAAABBBBCCCCDDDD,
v=rmF9pqV8S7suAoZWja4dJRkFsKQ= v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
S: [...Other header fields and resource body...] S: [...Other header fields and resource body...]
Note that in the example above the client can also initiate SCRAM Note that in the example above the client can also initiate SCRAM
authentication without first being prompted by the server. authentication without first being prompted by the server.
"SCRAM-SHA-1" authentication starts with sending the "Authorization" Initial "SCRAM-SHA-1" authentication starts with sending the
request header field defined by HTTP/1.1, Part 7 [RFC7235] containing "Authorization" request header field defined by HTTP/1.1, Part 7
"SCRAM-SHA-1" authentication scheme and the following attributes:
[RFC7235] containing "SCRAM-SHA-1" authentication 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 [RFC7235]. protection in the manner described in HTTP/1.1, Part 7 [RFC7235].
As specified in [RFC7235], the "realm" attribute MUST NOT appear As specified in [RFC7235], the "realm" attribute MUST NOT appear
more than once. The realm attribute only appears in the first more than once. The realm attribute only appears in the first
SCRAM message to the server and in the first SCRAM response from SCRAM message to the server and in the first SCRAM response from
the server. the server.
o The client also includes the "client-first-message" containing: o The client also includes the "client-first-message" containing:
skipping to change at page 9, line 27 skipping to change at page 9, line 29
supported, or used . Note that the "g" attribute always starts supported, or used . Note that the "g" attribute always starts
with "n", "y" or "p", otherwise the message is invalid and with "n", "y" or "p", otherwise the message is invalid and
authentication MUST fail. authentication MUST fail.
* SCRAM username and a random, unique nonce attributes. * SCRAM username and a random, unique nonce attributes.
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. [[CREF1: OPEN ISSUE: specified one with a server nonce. [[CREF2: OPEN ISSUE:
Alternatively, the "sid" attribute can be another header field.]] Alternatively, the "sid" attribute can be another header field.]]
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
computed using the selected hash function (SHA-1) as explained computed using the selected hash function (SHA-1) as explained
earlier. earlier.
The server verifies the nonce and the proof, and, finally, it The server verifies the nonce and the proof, and, finally, it
responds with a 200 HTTP response with the Authentication-Info header responds with a 200 HTTP response with the Authentication-Info header
field containing "server-final-message", concluding the field containing "server-final-message", concluding the
authentication exchange. authentication exchange.
The client then authenticates the server by computing the The client then authenticates the server by computing the
ServerSignature and comparing it to the value sent by the server. If ServerSignature and comparing it to the value sent by the server. If
the two are different, the client MUST consider the authentication the two are different, the client MUST consider the authentication
exchange to be unsuccessful and it might have to drop the connection. exchange to be unsuccessful and it might have to drop the connection.
5.1. Example reauthentication 5.1. One round trip reauthentication
If the server supports SCRAM reauthentication, reauthentication can If the server supports SCRAM reauthentication, the server sends in
look like this: its initial HTTP response a WWW-Authenticate header field containing:
the "realm" attribute (as defined earlier), the "sr" attribute that
contains the server part of the "r" attribute (see Section 5.2 and
optional "ttl" attribute (which contains the "sr" value validity in
seconds).
If the client has authenticated to the same realm before (i.e. it
remembers "i" and "s" attributes for a user from earlies
authentication exchanges with the server), it can respond to that
with "client-final-message".
If the server considers the server part of the nonce (the "r"
attribute) to be still valid, it will provide access to the requested
resource (assuming the client hash verifies correctly, of course).
However if the server considers that the server part of the nonce is
stale (for example if the "sr" value is used after the "ttl"
seconds), the server returns "401 Unauthorized" containing the SCRAM
mechanism name with a new "sr" and optional "ttl" attributes.
Reauthentication can look like this:
C: GET /resource HTTP/1.1 C: GET /resource HTTP/1.1
C: Host: server.example.com C: Host: server.example.com
C: [...] C: [...]
S: HTTP/1.1 401 Unauthorized S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Digest realm="realm1@host.com", S: WWW-Authenticate: Digest realm="realm1@host.com",
Digest realm="realm2@host.com", Digest realm="realm2@host.com",
Digest realm="realm3@host.com", Digest realm="realm3@host.com",
SCRAM-SHA-1 realm="realm3@host.com", SCRAM-SHA-1 realm="realm3@host.com",
SCRAM-SHA-1 realm="testrealm@host.com", sr=3rfcNHYJY1ZVvWVs7j SCRAM-SHA-1 realm="testrealm@host.com", sr=3rfcNHYJY1ZVvWVs7j
SCRAM-SHA-1 realm="testrealm2@host.com", sr=AAABBBCCCDDD, ttl=120
S: [...] S: [...]
[Client authenticates as usual.] [Client authenticates as usual to realm "testrealm@host.com"]
[Some time later client decides to reauthenticate. [Some time later client decides to reauthenticate.
It will use the cached "i" and "s" from earlies exchanges. It will use the cached "i" and "s" from earlies exchanges.
It will use the server advertised "sr" value as the server part of the "r". It will use the server advertised "sr" value as the server part of the "r".
Should some counter be added to make "sr" unique for each reauth???] Should some counter be added to make "sr" unique for each reauth???]
C: GET /resource HTTP/1.1 C: GET /resource HTTP/1.1
C: Host: server.example.com C: Host: server.example.com
C: Authorization: SCRAM-SHA-1 realm="testrealm@host.com", C: Authorization: SCRAM-SHA-1 realm="testrealm@host.com",
c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
skipping to change at page 12, line 5 skipping to change at page 13, line 7
described earlier, the client supplies an initial value in its described earlier, the client supplies an initial value in its
first message, and the server augments that value with its own first message, and the server augments that value with its own
nonce in its first response. It is important that this value be nonce in its first response. It is important that this value be
different for each authentication (see [RFC4086] for more details different for each authentication (see [RFC4086] for more details
on how to achieve this). The client MUST verify that the initial on how to achieve this). The client MUST verify that the initial
part of the nonce used in subsequent messages is the same as the part of the nonce used in subsequent messages is the same as the
nonce it initially specified. The server MUST verify that the nonce it initially specified. The server MUST verify that the
nonce sent by the client in the second message is the same as the nonce sent by the client in the second message is the same as the
one sent by the server in its first message. one sent by the server in its first message.
o sr: Server component of the nonce (the "r" attribute) when used
for re-authentication.
o c: This REQUIRED attribute specifies the base64-encoded GS2 header o c: This REQUIRED attribute specifies the base64-encoded GS2 header
and channel-binding data. It is sent by the client in its second and channel-binding data. It is sent by the client in its second
authentication message. The attribute data consist of: authentication message. The attribute data consist of:
* the GS2 header from the client's first message (recall that the * the GS2 header from the client's first message (recall that the
GS2 header contains a channel binding flag ). This header is GS2 header contains a channel binding flag ). This header is
going to include channel binding type prefix (see [RFC5056]), going to include channel binding type prefix (see [RFC5056]),
if and only if the client is using channel binding; if and only if the client is using channel binding;
* followed by the external channel's channel binding data, if and * followed by the external channel's channel binding data, if and
 End of changes. 12 change blocks. 
28 lines changed or deleted 54 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/