draft-ietf-httpauth-digest-10.txt   draft-ietf-httpauth-digest-11.txt 
HTTPAuth R. Shekh-Yusef, Ed. HTTPAuth R. Shekh-Yusef, Ed.
Internet-Draft Avaya Internet-Draft Avaya
Obsoletes: 2617 (if approved) D. Ahrens Obsoletes: 2617 (if approved) D. Ahrens
Intended status: Standards Track Independent Intended status: Standards Track Independent
Expires: July 14, 2015 S. Bremer Expires: July 24, 2015 S. Bremer
Netzkonform Netzkonform
January 10, 2015 January 20, 2015
HTTP Digest Access Authentication HTTP Digest Access Authentication
draft-ietf-httpauth-digest-10 draft-ietf-httpauth-digest-11
Abstract Abstract
HTTP provides a simple challenge-response authentication mechanism HTTP provides a simple challenge-response authentication mechanism
that may be used by a server to challenge a client request and by a that may be used by a server to challenge a client request and by a
client to provide authentication information. This document defines client to provide authentication information. This document defines
the HTTP Digest Authentication scheme that can be used with the HTTP the HTTP Digest Authentication scheme that can be used with the HTTP
authentication mechanism. authentication mechanism.
Editorial Note (To be removed by RFC Editor before publication) Editorial Note (To be removed by RFC Editor before publication)
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 July 14, 2015. This Internet-Draft will expire on July 24, 2015.
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 3, line 41 skipping to change at page 3, line 41
that may be used by a server to challenge a client request and by a that may be used by a server to challenge a client request and by a
client to provide authentication information. This document defines client to provide authentication information. This document defines
the HTTP Digest Authentication scheme that can be used with the HTTP the HTTP Digest Authentication scheme that can be used with the HTTP
authentication mechanism. authentication mechanism.
The details of the challenge-response authentication mechanism are The details of the challenge-response authentication mechanism are
specified in the "Hypertext Transfer Protocol (HTTP/1.1): specified in the "Hypertext Transfer Protocol (HTTP/1.1):
Authentication" [RFC7235]. Authentication" [RFC7235].
The combination of this document with the definition of the "Basic" The combination of this document with the definition of the "Basic"
authentication scheme [BASIC] and [RFC7235] obsolete RFC 2617. authentication scheme [BASIC] and [RFC7235] obsolete [RFC2617].
1.1. Terminology 1.1. Terminology
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 RFC 2119 [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Syntax Convention 2. Syntax Convention
2.1. Examples 2.1. Examples
In the interest of clarity and readability, the extended parameters In the interest of clarity and readability, the extended parameters
or the header fields and parameters in the examples in this document or the header fields and parameters in the examples in this document
might be broken into multiple lines. Any line that is indented in might be broken into multiple lines. Any line that is indented in
this document is a continuation of the preceding line. this document is a continuation of the preceding line.
skipping to change at page 4, line 37 skipping to change at page 4, line 37
HTTP method, and the requested URI. In this way, the password is HTTP method, and the requested URI. In this way, the password is
never sent in the clear, and the username can be hashed, depending on never sent in the clear, and the username can be hashed, depending on
the indication received from the server. The username and password the indication received from the server. The username and password
must be prearranged in some fashion not addressed by this document. must be prearranged in some fashion not addressed by this document.
The security of this protocol is critically dependent on the The security of this protocol is critically dependent on the
randomness of the randomly chosen parameters, such as client and randomness of the randomly chosen parameters, such as client and
server nonces. These should be generated by a strong random or server nonces. These should be generated by a strong random or
properly seeded pseudorandom source (see [RFC4086]). properly seeded pseudorandom source (see [RFC4086]).
Some or all of the parameters used in the various headers fields used For the following parameters, the value can be encoded using
by this document can be sent using the [RFC5987] encoding. [RFC5987] encoding: username.
3.2. Representation of Digest Values 3.2. Representation of Digest Values
An optional header field allows the server to specify the algorithm An optional header field allows the server to specify the algorithm
used to create the checksum or digest. This documents adds SHA-256 used to create the checksum or digest. This documents adds SHA-256
and SHA-512/256 algorithms. To maintain backwards compatibility with and SHA-512/256 algorithms. To maintain backwards compatibility with
[RFC2617], the MD5 algorithm is still supported but NOT RECOMMENDED. [RFC2617], the MD5 algorithm is still supported but NOT RECOMMENDED.
The size of the digest depends on the algorithm used. The bits in The size of the digest depends on the algorithm used. The bits in
the digest are converted from the most significant to the least the digest are converted from the most significant to the least
skipping to change at page 5, line 29 skipping to change at page 5, line 29
A string to be displayed to users so they know which username and A string to be displayed to users so they know which username and
password to use. This string should contain at least the name of password to use. This string should contain at least the name of
the host performing the authentication and might additionally the host performing the authentication and might additionally
indicate the collection of users who might have access. An indicate the collection of users who might have access. An
example might be "registered_users@gotham.news.com". (See example might be "registered_users@gotham.news.com". (See
Section 2.2 of [RFC7235] for more details). Section 2.2 of [RFC7235] for more details).
domain domain
A quoted, space-separated list of URIs, as specified in RFC 3986 A quoted, space-separated list of URIs, as specified in [RFC3986],
[RFC3986], that define the protection space. If a URI is an that define the protection space. If a URI is an abs_path, it is
abs_path, it is relative to the canonical root URL (See relative to the canonical root URL (See Section 2.2 of [RFC7235])
Section 2.2 of [RFC7235]) of the web-origin [RFC6454]. An of the web-origin [RFC6454]. An absolute-URI in this list may
absolute-URI in this list may refer to a different server than the refer to a different server than the web-origin. The client can
web-origin. The client can use this list to determine the set of use this list to determine the set of URIs for which the same
URIs for which the same authentication information may be sent: authentication information may be sent: any URI that has a URI in
any URI that has a URI in this list as a prefix (after both have this list as a prefix (after both have been made absolute) MAY be
been made absolute) MAY be assumed to be in the same protection assumed to be in the same protection space. If this parameter is
space. If this parameter is omitted or its value is empty, the omitted or its value is empty, the client SHOULD assume that the
client SHOULD assume that the protection space consists of all protection space consists of all URIs on the web-origin. All URIs
URIs on the web-origin. All URIs in this list SHOULD use the same in this list SHOULD use the same scheme (https or http); mixing
scheme (https or http); mixing them is a bad idea. them is a bad idea.
This parameter is not meaningful in Proxy-Authenticate header This parameter is not meaningful in Proxy-Authenticate header
fields, for which the protection space is always the entire proxy; fields, for which the protection space is always the entire proxy;
if present it MUST be ignored. if present it MUST be ignored.
nonce nonce
A server-specified data string which should be uniquely generated A server-specified data string which should be uniquely generated
each time a 401 response is made. It is advised that this string each time a 401 response is made. It is advised that this string
be base64 or hexadecimal data. Specifically, since the string is be base64 or hexadecimal data. Specifically, since the string is
skipping to change at page 19, line 12 skipping to change at page 19, line 12
6794697cf8db5856cb6c1", 6794697cf8db5856cb6c1",
opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS" opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
3.9.2. Example with SHA-512-256, Charset, and Userhash 3.9.2. Example with SHA-512-256, Charset, and Userhash
The following example assumes that an access protected document is The following example assumes that an access protected document is
being requested from the server via a GET request. The URI for the being requested from the server via a GET request. The URI for the
request is "http://api.example.org/doe.json". Both client and server request is "http://api.example.org/doe.json". Both client and server
know the userhash of the username, support the UTF-8 character know the userhash of the username, support the UTF-8 character
encoding scheme, and use the SHA-512-256 algorithm. The username for encoding scheme, and use the SHA-512-256 algorithm. The username for
the request is "Jaesoen Doe" and the password is "Secret, or not?". the request is a variation of "Jason Doe" and has the byte sequence
4A C3 A4 73 C3 B8 6E 20 44 6F 65. The password is "Secret, or not?".
The first time the client requests the document, no Authorization The first time the client requests the document, no Authorization
header field is sent, so the server responds with: header field is sent, so the server responds with:
HTTP/1.1 401 Unauthorized HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest WWW-Authenticate: Digest
realm="api@example.org", realm="api@example.org",
qop=auth, qop=auth,
algorithm=SHA-512-256, algorithm=SHA-512-256,
nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK", nonce="5TsQWLVdgBdmrQ0XsxbDODV+57QdFR34I9HAbC/RVvkK",
skipping to change at page 20, line 30 skipping to change at page 20, line 30
In challenges, servers SHOULD use the "charset" authentication In challenges, servers SHOULD use the "charset" authentication
parameter (case-insensitive) to express the character encoding they parameter (case-insensitive) to express the character encoding they
expect the user agent to use when generating A1 (see section 3.4.2) expect the user agent to use when generating A1 (see section 3.4.2)
and username hashing (see section 3.4.4). and username hashing (see section 3.4.4).
The only allowed value is "UTF-8", to be matched case-insensitively The only allowed value is "UTF-8", to be matched case-insensitively
(see [RFC2978], Section 2.3). It indicates that the server expects (see [RFC2978], Section 2.3). It indicates that the server expects
user name and password to be converted to Unicode Normalization Form user name and password to be converted to Unicode Normalization Form
C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets
using the UTF-8 character encoding scheme ([RFC3629]), ), and percent using the UTF-8 character encoding scheme [RFC3629].
escaped in extended notation ([RFC5987]).
For the username, recipients MUST support all characters defined in For the username, recipients MUST support all characters defined in
the "UsernameCasePreserved" profile defined in in Section 3.3 of the "UsernameCasePreserved" profile defined in in Section 3.3 of
[PRECIS], with the exception of the colon (":") character. [PRECIS], with the exception of the colon (":") character.
For the password, recipients MUST support all characters defined in For the password, recipients MUST support all characters defined in
the "OpaqueString" profile defined in in Section 4.2 of [PRECIS]. the "OpaqueString" profile defined in in Section 4.2 of [PRECIS].
If the user agent does not support the encoding indicated by the If the user agent does not support the encoding indicated by the
server, it can fail the request. server, it can fail the request.
 End of changes. 10 change blocks. 
24 lines changed or deleted 24 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/