draft-ietf-httpauth-scram-auth-02.txt   draft-ietf-httpauth-scram-auth-03.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 July 4, 2014
Expires: January 5, 2015 Expires: January 5, 2015
Salted Challenge Response (SCRAM) HTTP Authentication Mechanism Salted Challenge Response (SCRAM) HTTP Authentication Mechanism
draft-ietf-httpauth-scram-auth-02.txt draft-ietf-httpauth-scram-auth-03.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 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. SCRAM Attributes . . . . . . . . . . . . . . . . . . . . . 9 5.1. Example reauthentication . . . . . . . . . . . . . . . . . 9
5.2. SCRAM Attributes . . . . . . . . . . . . . . . . . . . . . 10
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10. Design Motivations . . . . . . . . . . . . . . . . . . . . . 17 10. Design Motivations . . . . . . . . . . . . . . . . . . . . . 17
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18
12. Internet-Draft Change History . . . . . . . . . . . . . . . . 17 12. Internet-Draft Change History . . . . . . . . . . . . . . . . 18
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 13.1. Normative References . . . . . . . . . . . . . . . . . . . 18
13.2. Informative References . . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
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 30 skipping to change at page 7, line 30
hash function as defined in [RFC3174]. 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.1, and defined in and their attributes are described in Section 5.2, and defined in
Section 6. Section 6.
challenge-scram = scram-name [1*SP 1#auth-param] challenge-scram = scram-name [1*SP 1#auth-param]
; Complies with <challenge> ABNF from RFC 7235. ; Complies with <challenge> ABNF from RFC 7235.
; Included in the WWW-Authenticate header field. ; Included in the WWW-Authenticate header field.
credentials-scram = scram-name [1*SP 1#auth-param] credentials-scram = scram-name [1*SP 1#auth-param]
; Complies with <credentials> from RFC 7235. ; Complies with <credentials> from RFC 7235.
; Included in the Authorization header field. ; Included in the Authorization header field.
skipping to change at page 8, line 17 skipping to change at page 8, line 17
password 'pencil' are used): password 'pencil' are used):
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" SCRAM-SHA-1 realm="testrealm@host.com"
S: [...] S: [...]
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",
g=n,n=user,r=fyko+d2lbbFgONRv9qkxdawL g=n,n=user,r=fyko+d2lbbFgONRv9qkxdawL
C: [...] C: [...]
S: HTTP/1.1 401 Unauthorized S: HTTP/1.1 401 Unauthorized
skipping to change at page 9, line 27 skipping to change at page 9, line 27
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. specified one with a server nonce. [[CREF1: OPEN ISSUE:
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. SCRAM Attributes 5.1. Example reauthentication
If the server supports SCRAM reauthentication, reauthentication can
look like this:
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: [...]
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Digest realm="realm1@host.com",
Digest realm="realm2@host.com",
Digest realm="realm3@host.com",
SCRAM-SHA-1 realm="realm3@host.com",
SCRAM-SHA-1 realm="testrealm@host.com", sr=3rfcNHYJY1ZVvWVs7j
S: [...]
[Client authenticates as usual.]
[Some time later client decides to reauthenticate.
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".
Should some counter be added to make "sr" unique for each reauth???]
C: GET /resource HTTP/1.1
C: Host: server.example.com
C: Authorization: SCRAM-SHA-1 realm="testrealm@host.com",
c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
C: [...]
S: HTTP/1.1 200 Ok
S: Authentication-Info: SCRAM-SHA-1
sid=AAAABBBBCCCCDDDD,
v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
S: [...Other header fields and resource body...]
5.2. SCRAM Attributes
This section describes the permissible attributes, their use, and the This section describes the permissible attributes, their use, and the
format of their values. All attribute names are single US-ASCII format of their values. All attribute names are single US-ASCII
letters and are case-sensitive. letters and are case-sensitive.
Note that the order of attributes in client or server messages is Note that the order of attributes in client or server messages is
fixed, with the exception of extension attributes (described by the fixed, with the exception of extension attributes (described by the
"extensions" ABNF production), which can appear in any order in the "extensions" ABNF production), which can appear in any order in the
designated positions. See the ABNF section for authoritative designated positions. See the ABNF section for authoritative
reference. reference.
 End of changes. 8 change blocks. 
15 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/