draft-ietf-httpauth-mutual-05.txt   draft-ietf-httpauth-mutual-06.txt 
HTTPAUTH Working Group Y. Oiwa HTTPAUTH Working Group Y. Oiwa
Internet-Draft H. Watanabe Internet-Draft H. Watanabe
Intended status: Experimental H. Takagi Intended status: Experimental H. Takagi
Expires: January 7, 2016 ITRI, AIST Expires: July 10, 2016 ITRI, AIST
K. Maeda K. Maeda
T. Hayashi T. Hayashi
Lepidum Lepidum
Y. Ioku Y. Ioku
Individual Individual
July 6, 2015 January 7, 2016
Mutual Authentication Protocol for HTTP Mutual Authentication Protocol for HTTP
draft-ietf-httpauth-mutual-05 draft-ietf-httpauth-mutual-06
Abstract Abstract
This document specifies a mutual authentication method for the Hyper- This document specifies a mutual authentication method for the Hyper-
text Transfer Protocol (HTTP). This method provides a true mutual text Transfer Protocol (HTTP). This method provides a true mutual
authentication between an HTTP client and an HTTP server using authentication between an HTTP client and an HTTP server using
password-based authentication. Unlike the Basic and Digest password-based authentication. Unlike the Basic and Digest
authentication methods, the Mutual authentication method specified in authentication methods, the Mutual authentication method specified in
this document assures the user that the server truly knows the user's this document assures the user that the server truly knows the user's
encrypted password. encrypted password.
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 January 7, 2016. This Internet-Draft will expire on July 10, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 21 skipping to change at page 3, line 21
17.2. Denial-of-service Attacks to Servers . . . . . . . . . . . 44 17.2. Denial-of-service Attacks to Servers . . . . . . . . . . . 44
17.2.1. On-line Active Password Attacks . . . . . . . . . . . 44 17.2.1. On-line Active Password Attacks . . . . . . . . . . . 44
17.3. Communicating the status of mutual authentication with 17.3. Communicating the status of mutual authentication with
users . . . . . . . . . . . . . . . . . . . . . . . . . . 44 users . . . . . . . . . . . . . . . . . . . . . . . . . . 44
17.4. Implementation Considerations . . . . . . . . . . . . . . 45 17.4. Implementation Considerations . . . . . . . . . . . . . . 45
17.5. Usage Considerations . . . . . . . . . . . . . . . . . . . 46 17.5. Usage Considerations . . . . . . . . . . . . . . . . . . . 46
18. Notice on Intellectual Properties . . . . . . . . . . . . . . 46 18. Notice on Intellectual Properties . . . . . . . . . . . . . . 46
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
19.1. Normative References . . . . . . . . . . . . . . . . . . . 47 19.1. Normative References . . . . . . . . . . . . . . . . . . . 47
19.2. Informative References . . . . . . . . . . . . . . . . . . 48 19.2. Informative References . . . . . . . . . . . . . . . . . . 48
Appendix A. (Informative) Draft Remarks from Authors . . . . . . 49 Appendix A. (Informative) Draft Change Log . . . . . . . . . . . 49
Appendix B. (Informative) Draft Change Log . . . . . . . . . . . 49 A.1. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 49
B.1. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 50 A.2. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 50
B.2. Changes in Httpauth WG Revision 04 . . . . . . . . . . . . 50 A.3. Changes in Httpauth WG Revision 04 . . . . . . . . . . . . 50
B.3. Changes in Httpauth WG Revision 03 . . . . . . . . . . . . 50 A.4. Changes in Httpauth WG Revision 03 . . . . . . . . . . . . 50
B.4. Changes in Httpauth WG Revision 02 . . . . . . . . . . . . 50 A.5. Changes in Httpauth WG Revision 02 . . . . . . . . . . . . 50
B.5. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 50 A.6. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 50
B.6. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 51 A.7. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 51
B.7. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 51 A.8. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 51
B.8. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 51 A.9. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 51
B.9. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 51 A.10. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 51
B.10. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 51 A.11. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 51
B.11. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 52 A.12. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 52
B.12. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 53 A.13. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 53
B.13. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 53 A.14. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 53
B.14. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 53 A.15. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 53
B.15. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 54 A.16. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 54
B.16. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 54 A.17. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 54
B.17. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 54 A.18. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 54
B.18. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 54 A.19. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 54
B.19. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 55 A.20. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
This document specifies a mutual authentication method for Hyper-Text This document specifies a mutual authentication method for Hyper-Text
Transfer Protocol (HTTP). The method, called "Mutual Authentication Transfer Protocol (HTTP). The method, called "Mutual Authentication
Protocol" in this document, provides a true mutual authentication Protocol" in this document, provides a true mutual authentication
between an HTTP client and an HTTP server, using just a simple between an HTTP client and an HTTP server, using just a simple
password as a credential. password as a credential.
skipping to change at page 11, line 9 skipping to change at page 11, line 9
Throughout this specification, The syntax is denoted in the extended Throughout this specification, The syntax is denoted in the extended
augmented BNF syntax defined in [RFC7230] and [RFC5234]. The augmented BNF syntax defined in [RFC7230] and [RFC5234]. The
following elements are quoted from [RFC5234], [RFC7230] and following elements are quoted from [RFC5234], [RFC7230] and
[RFC7235]: DIGIT, ALPHA, SP, auth-scheme, quoted-string, auth-param, [RFC7235]: DIGIT, ALPHA, SP, auth-scheme, quoted-string, auth-param,
header-field, token, challenge, and credential. header-field, token, challenge, and credential.
The Mutual authentication protocol uses three headers: The Mutual authentication protocol uses three headers:
WWW-Authenticate (usually in responses with status code 401), WWW-Authenticate (usually in responses with status code 401),
Authorization (in requests), and Authentication-Info (in responses Authorization (in requests), and Authentication-Info (in responses
other than 401 status). These headers follow a common framework other than 401 status). These headers follow a common framework
described in [RFC7235] and [I-D.ietf-httpbis-auth-info]. The described in [RFC7235] and [RFC7615]. The detailed meanings for
detailed meanings for these headers are contained in Section 4. these headers are contained in Section 4.
The framework in [RFC7235] defines the syntax for the headers The framework in [RFC7235] defines the syntax for the headers
WWW-Authenticate and Authorization as the syntax elements "challenge" WWW-Authenticate and Authorization as the syntax elements "challenge"
and "credentials", respectively. The "auth-scheme" contained in and "credentials", respectively. The "auth-scheme" contained in
those headers MUST be "Mutual" throughout this protocol those headers MUST be "Mutual" throughout this protocol
specification. The syntax for "challenge" and "credentials" to be specification. The syntax for "challenge" and "credentials" to be
used with the "Mutual" auth-scheme SHALL be name-value pairs (#auth- used with the "Mutual" auth-scheme SHALL be name-value pairs (#auth-
param), not the "b64token" defined in [RFC7235]. param), not the "b64token" defined in [RFC7235].
The Authentication-Info: header used in this protocol SHALL follow The Authentication-Info: header used in this protocol SHALL follow
the syntax defined in [I-D.ietf-httpbis-auth-info]. the syntax defined in [RFC7615].
In HTTP, the WWW-Authenticate header may contain more than one In HTTP, the WWW-Authenticate header may contain more than one
challenges. Client implementations SHOULD be aware of and be capable challenges. Client implementations SHOULD be aware of and be capable
of handle those cases correctly. of handle those cases correctly.
3.1. Non-ASCII extended header parameters 3.1. Non-ASCII extended header parameters
All of parameters contained in the above three headers, except the All of parameters contained in the above three headers, except the
"realm" field, MAY be extended to ISO 10646-1 values using the "realm" field, MAY be extended to ISO 10646-1 values using the
framework described in [RFC5987]. All servers and clients MUST be framework described in [RFC5987]. All servers and clients MUST be
skipping to change at page 15, line 42 skipping to change at page 15, line 42
authentication algorithm to be used. The value MUST authentication algorithm to be used. The value MUST
be one of the tokens specified in be one of the tokens specified in
[I-D.ietf-httpauth-mutual-algo] or other supplemental [I-D.ietf-httpauth-mutual-algo] or other supplemental
specification documentation. specification documentation.
validation: (mandatory extensive-token) specifies the method of validation: (mandatory extensive-token) specifies the method of
host validation. The value MUST be one of the tokens host validation. The value MUST be one of the tokens
described in Section 7, or the tokens specified in described in Section 7, or the tokens specified in
other supplemental specification documentation. other supplemental specification documentation.
auth-domain: (non-mandatory string) specifies the authentication auth-scope: (non-mandatory string) specifies the authentication
domain, the set of hosts for which the authentication scope, the set of hosts for which the authentication
credentials are valid. It MUST be one of the strings credentials are valid. It MUST be one of the strings
described in Section 5. If the value is omitted, it described in Section 5. If the value is omitted, it
is assumed to be the "single-server" type domain in is assumed to be the "single-server" type domain in
Section 5. Section 5.
realm: (mandatory string) is a string representing the name realm: (mandatory string) is a string representing the name
of the authentication realm inside the authentication of the authentication realm inside the authentication
domain. As specified in [RFC7235], this value MUST scope. As specified in [RFC7235], this value MUST
always be sent in the quoted-string form, and an always be sent in the quoted-string form, and an
[RFC5987] encoding MUST NOT be used. [RFC5987] encoding MUST NOT be used.
The realm value sent from the server SHOULD be an The realm value sent from the server SHOULD be an
ASCII string. Clients MAY treat any non-ASCII value ASCII string. Clients MAY treat any non-ASCII value
received in this field as one of a binary blob, an received in this field as one of a binary blob, an
NFC-normalized UTF-8 string, or an error. NFC-normalized UTF-8 string, or an error.
pwd-hash: (non-mandatory extensive-token) specifies the hash pwd-hash: (non-mandatory extensive-token) specifies the hash
algorithm (hereafter referred to by ph) used for algorithm (hereafter referred to by ph) used for
additionally hashing the password. The valid tokens additionally hashing the password. The valid tokens
are are
* none: ph(p) = p * none: ph(p) = p
* md5: ph(p) = MD5(p) * md5: ph(p) = MD5(p)
* digest-md5: ph(p) = MD5(username | ":" | realm |
":" | p), the same value as MD5(A1) for "MD5"
algorithm in [RFC2617].
* sha1: ph(p) = SHA1(p) * sha1: ph(p) = SHA1(p)
If omitted, the value "none" is assumed. The use of If omitted, the value "none" is assumed. The use of
"none" is desirable. "none" is desirable.
reason: (mandatory extensive-token) SHALL be an extensive- reason: (mandatory extensive-token) SHALL be an extensive-
token which describes the possible reason of the token which describes the possible reason of the
failed authentication/authorization. Both servers and failed authentication/authorization. Both servers and
clients SHALL understand and support the following clients SHALL understand and support the following
three tokens: three tokens:
skipping to change at page 18, line 8 skipping to change at page 18, line 8
Every req-KEX-C1 message SHALL be a valid HTTP request message Every req-KEX-C1 message SHALL be a valid HTTP request message
containing an "Authorization" header with a credential containing a containing an "Authorization" header with a credential containing a
"kc1" parameter. "kc1" parameter.
The credential SHALL contain the parameters with the following names: The credential SHALL contain the parameters with the following names:
version: (mandatory, extensive-token) should be the token "-wg- version: (mandatory, extensive-token) should be the token "-wg-
draft04". draft04".
algorithm, validation, auth-domain, realm: MUST be the same value as algorithm, validation, auth-scope, realm: MUST be the same value as
it is when received from the server. it is when received from the server.
user: (mandatory, string) is the UTF-8 encoded name of the user: (mandatory, string) is the UTF-8 encoded name of the
user. The string SHOULD be prepared according to the user. The string SHOULD be prepared according to the
method presented in Section 9. method presented in Section 9.
kc1: (mandatory, algorithm-determined) is the client-side kc1: (mandatory, algorithm-determined) is the client-side
key exchange value K_c1, which is specified by the key exchange value K_c1, which is specified by the
algorithm that is used. algorithm that is used.
skipping to change at page 18, line 31 skipping to change at page 18, line 31
Every 401-KEX-S1 message SHALL be a valid HTTP 401-status Every 401-KEX-S1 message SHALL be a valid HTTP 401-status
(Authentication Required) response message containing a (Authentication Required) response message containing a
"WWW-Authenticate" header with a challenge containing a "ks1" "WWW-Authenticate" header with a challenge containing a "ks1"
parameter. parameter.
The challenge SHALL contain the parameters with the following names: The challenge SHALL contain the parameters with the following names:
version: (mandatory, extensive-token) should be the token "-wg- version: (mandatory, extensive-token) should be the token "-wg-
draft04". draft04".
algorithm, validation, auth-domain, realm: MUST be the same value as algorithm, validation, auth-scope, realm: MUST be the same value as
it is when received from the client. it is when received from the client.
sid: (mandatory, hex-fixed-number) MUST be a session sid: (mandatory, hex-fixed-number) MUST be a session
identifier, which is a random integer. The sid SHOULD identifier, which is a random integer. The sid SHOULD
have uniqueness of at least 80 bits or the square of have uniqueness of at least 80 bits or the square of
the maximal estimated transactions concurrently the maximal estimated transactions concurrently
available in the session table, whichever is larger. available in the session table, whichever is larger.
See Section 6 for more details. See Section 6 for more details.
ks1: (mandatory, algorithm-determined) is the server-side ks1: (mandatory, algorithm-determined) is the server-side
skipping to change at page 19, line 16 skipping to change at page 19, line 16
seconds) that the client can reuse the session seconds) that the client can reuse the session
represented by the sid. It is RECOMMENDED to be at represented by the sid. It is RECOMMENDED to be at
least 60. The value of this parameter is not directly least 60. The value of this parameter is not directly
linked to the duration that the server keeps track of linked to the duration that the server keeps track of
the session represented by the sid. the session represented by the sid.
path: (non-mandatory, string) specifies which path in the path: (non-mandatory, string) specifies which path in the
URI space the same authentication is expected to be URI space the same authentication is expected to be
applied. The value is a space-separated list of URIs, applied. The value is a space-separated list of URIs,
in the same format as it was specified in domain in the same format as it was specified in domain
parameter [RFC2617] for the Digest authentications. parameter [RFC7616] for the Digest authentications.
The all path elements contained in the parameter MUST The all path elements contained in the parameter MUST
be inside the specified auth-domain; if not, clients be inside the specified auth-scope; if not, clients
SHOULD ignore such elements. For better performance, SHOULD ignore such elements. For better performance,
recognition of this parameter by clients are recognition of this parameter by clients are
significantly important. significantly important.
4.4. req-VFY-C 4.4. req-VFY-C
Every req-VFY-C message SHALL be a valid HTTP request message Every req-VFY-C message SHALL be a valid HTTP request message
containing an "Authorization" header with a credential containing a containing an "Authorization" header with a credential containing a
"vkc" parameter. "vkc" parameter.
The parameters contained in the header are as follows: The parameters contained in the header are as follows:
version: (mandatory, extensive-token) should be the token "-wg- version: (mandatory, extensive-token) should be the token "-wg-
draft04". draft04".
algorithm, validation, auth-domain, realm: MUST be the same value as algorithm, validation, auth-scope, realm: MUST be the same value as
it is when received from the server for the session. it is when received from the server for the session.
sid: (mandatory, hex-fixed-number) MUST be one of the sid sid: (mandatory, hex-fixed-number) MUST be one of the sid
values that was received from the server for the same values that was received from the server for the same
authentication realm. authentication realm.
nc: (mandatory, integer) is a nonce request number that is nc: (mandatory, integer) is a nonce request number that is
unique among the requests sharing the same sid. The unique among the requests sharing the same sid. The
values of the nonce numbers SHOULD satisfy the values of the nonce numbers SHOULD satisfy the
properties outlined in Section 6. properties outlined in Section 6.
skipping to change at page 20, line 46 skipping to change at page 20, line 46
realms, the clients MUST NOT automatically reuse the user names and realms, the clients MUST NOT automatically reuse the user names and
passwords for another realm. passwords for another realm.
Just like in Basic and Digest access authentication protocols, Mutual Just like in Basic and Digest access authentication protocols, Mutual
authentication protocol supports multiple, separate protection spaces authentication protocol supports multiple, separate protection spaces
to be set up inside each host. Furthermore, the protocol supports to be set up inside each host. Furthermore, the protocol supports
that a single authentication realm spans over several hosts within that a single authentication realm spans over several hosts within
the same Internet domain. the same Internet domain.
Each authentication realm is defined and distinguished by the triple Each authentication realm is defined and distinguished by the triple
of an "authentication algorithm", an "authentication domain", and a of an "authentication algorithm", an "authentication scope", and a
"realm" parameter. However, server operators are NOT RECOMMENDED to "realm" parameter. However, server operators are NOT RECOMMENDED to
use the same pair of an authentication domain and a realm for use the same pair of an authentication scope and a realm for
different authentication algorithms. different authentication algorithms.
The realm parameter is a string as defined in Section 4. The realm parameter is a string as defined in Section 4.
Authentication domains are described in the remainder of this Authentication scopes are described in the remainder of this section.
section.
An authentication domain specifies the range of hosts that the An authentication scope specifies the range of hosts that the
authentication realm spans over. In this protocol, it MUST be one of authentication realm spans over. In this protocol, it MUST be one of
the following strings. the following kinds of strings.
o Single-server type: The string in format "<scheme>://<host>" or o Single-server type: The string in format "<scheme>://<host>" or
"<scheme>://<host>:<port>", where <scheme>, <host>, and <port> are "<scheme>://<host>:<port>", where <scheme>, <host>, and <port> are
the corresponding URI parts of the request URI. If the default the corresponding URI parts of the request URI. If the default
port (i.e. 80 for http and 443 for https) is used for the port (i.e. 80 for http and 443 for https) is used for the
underlying HTTP communications, the port part MUST be omitted, underlying HTTP communications, the port part MUST be omitted,
regardless of whether it was present in the request-URI. In other regardless of whether it was present in the request-URI. In other
cases, the port part MUST be present, and it MUST NOT contain cases, the port part MUST be present, and it MUST NOT contain
leading zeros. Use this when authentication is only valid for leading zeros. Use this when authentication is only valid for
specific protocol (such as https). This format is equivalent to specific protocol (such as https). This format is equivalent to
the ASCII serialization of a Web Origin, presented in Section 6.2 the ASCII serialization of a Web Origin, presented in Section 6.2
of [RFC6454]. of [RFC6454].
o Single-host type: The "host" part of the requested URI. This is o Single-host type: The "host" part of the requested URI. This is
the default value. Authentication realms within this kind of the default value. Authentication realms within this kind of
authentication domain will span over several protocols (i.e. http authentication scope will span over several protocols (i.e. http
and https) and ports, but not over different hosts. and https) and ports, but not over different hosts.
o Wildcard-domain type: The string in format "*.<domain-postfix>", o Wildcard-domain type: The string in format "*.<domain-postfix>",
where <domain-postfix> is either the host part of the requested where <domain-postfix> is either the host part of the requested
URI or any domain in which the requested host is included (this URI or any domain in which the requested host is included (this
means that the specification "*.example.com" is valid for all of means that the specification "*.example.com" is valid for all of
hosts "www.example.com", "web.example.com", hosts "www.example.com", "web.example.com",
"www.sales.example.com" and "example.com"). The domain-postfix "www.sales.example.com" and "example.com"). The domain-postfix
sent from the servers MUST be equal to or included in a valid sent from the servers MUST be equal to or included in a valid
Internet domain assigned to a specific organization: if clients Internet domain assigned to a specific organization: if clients
skipping to change at page 22, line 7 skipping to change at page 22, line 7
MUST be in lower-case, and any internationalized domain names beyond MUST be in lower-case, and any internationalized domain names beyond
the ASCII character set SHALL be represented in the way they are sent the ASCII character set SHALL be represented in the way they are sent
in the underlying HTTP protocol, represented in lower-case in the underlying HTTP protocol, represented in lower-case
characters; i.e. these SHALL be in the form of the LDH labels in IDNA characters; i.e. these SHALL be in the form of the LDH labels in IDNA
[RFC5890]. All "port"s MUST be in the shortest, unsigned, decimal [RFC5890]. All "port"s MUST be in the shortest, unsigned, decimal
number notation. Not obeying these requirements will cause failure number notation. Not obeying these requirements will cause failure
of valid authentication attempts. of valid authentication attempts.
5.1. Resolving Ambiguities 5.1. Resolving Ambiguities
In the above definitions of authentication domains, several domains In the above definitions of authentication scopes, several scopes
will overlap each other. If a client has already been authenticated will overlap each other. If a client has already been authenticated
to several realms applicable to the same server, the client may have to several realms applicable to the same server, the client may have
a multiple list of the "path" parameters received with the a multiple list of the "path" parameters received with the
"401-KEX-S1" message (see Section 4). If these path lists have any "401-KEX-S1" message (see Section 4). If these path lists have any
overlap, a single URI may belong to multiple possible candidate of overlap, a single URI may belong to multiple possible candidate of
realms to be authenticated to. In such cases, clients faces an realms to be authenticated to. In such cases, clients faces an
ambiguity on deciding which credentials to be sent for a new request ambiguity on deciding which credentials to be sent for a new request
(in steps 3 and 4 of the decision procedure presented in Section 10). (in steps 3 and 4 of the decision procedure presented in Section 10).
In such cases, clients MAY send requests which belongs to any of In such cases, clients MAY send requests which belongs to any of
skipping to change at page 22, line 33 skipping to change at page 22, line 33
occur. occur.
The following procedure are one of the possible tactics for resolving The following procedure are one of the possible tactics for resolving
ambiguity in such cases. ambiguity in such cases.
o If the client has previously sent a request to the same URI, and o If the client has previously sent a request to the same URI, and
if it remembers the authentication realm requested by 401-INIT if it remembers the authentication realm requested by 401-INIT
messages at that time, use that realm. messages at that time, use that realm.
o In other cases, use one of authentication realms representing the o In other cases, use one of authentication realms representing the
most-specific authentication domains. From the list of possible most-specific authentication scopes. From the list of possible
domain specifications shown above, each one earlier has priority domain specifications shown above, each one earlier has priority
over ones described after that. over ones described after that.
If there are several choices with different domain-postfix If there are several choices with different domain-postfix
specifications, the one that has the longest domain-postfix has specifications, the one that has the longest domain-postfix has
priority over ones with a shorter domain-postfix. priority over ones with a shorter domain-postfix.
o If there are realms with the same authentication domain, there is o If there are realms with the same authentication scope, there is
no defined priority: the client MAY choose any one of the possible no defined priority: the client MAY choose any one of the possible
choices. choices.
6. Session Management 6. Session Management
In the Mutual authentication protocol, a session represented by an In the Mutual authentication protocol, a session represented by an
sid is set up using first four messages (first request, 401-INIT, sid is set up using first four messages (first request, 401-INIT,
req-KEX-C1 and 401-KEX-S1), and a "session secret" (z) associated req-KEX-C1 and 401-KEX-S1), and a "session secret" (z) associated
with the session is established. After sharing a session secret, with the session is established. After sharing a session secret,
this session, along with the secret, can be used for one or more this session, along with the secret, can be used for one or more
requests for resources protected by the same realm in the same requests for resources protected by the same realm in the same
server. Note that session management is only an inside detail of the server. Note that session management is only an inside detail of the
protocol and usually not visible to normal users. If a session protocol and usually not visible to normal users. If a session
expires, the client and server SHOULD automatically re-establish expires, the client and server SHOULD automatically re-establish
another session without informing the users. another session without informing the users.
Sessions and session identifiers are local to each server (defined by Sessions and session identifiers are local to each server (defined by
scheme, host and port), even if an authentication domain covers scheme, host and port), even if an authentication scope covers
multiple servers; the clients MUST establish separate sessions for multiple servers; the clients MUST establish separate sessions for
each port of a host to be accessed. Furthermore, sessions and each port of a host to be accessed. Furthermore, sessions and
identifiers are also local to each authentication realm, even if identifiers are also local to each authentication realm, even if
these are provided from the same server. The same session these are provided from the same server. The same session
identifiers provided either from different servers or for different identifiers provided either from different servers or for different
realms MUST be treated as independent ones. realms MUST be treated as independent ones.
The server SHOULD accept at least one req-VFY-C request for each The server SHOULD accept at least one req-VFY-C request for each
session, given that the request reaches the server in a time window session, given that the request reaches the server in a time window
specified by the timeout parameter in the 401-KEX-S1 message, and specified by the timeout parameter in the 401-KEX-S1 message, and
skipping to change at page 27, line 8 skipping to change at page 27, line 8
o After calculating value vh and vkc to send a req-VFY-C request, o After calculating value vh and vkc to send a req-VFY-C request,
Clients SHOULD NOT initiate TLS renegotiation until the end of the Clients SHOULD NOT initiate TLS renegotiation until the end of the
corresponding response header is received. Exceptionally, Clients corresponding response header is received. Exceptionally, Clients
can and SHOULD perform TLS re-negotiation as a response to can and SHOULD perform TLS re-negotiation as a response to
server's request for TLS renegotiation, occurring before the top server's request for TLS renegotiation, occurring before the top
of response header. of response header.
Also, implementer MUST take care of session resumption attacks Also, implementer MUST take care of session resumption attacks
regarding tls-unique channel binding mechanisms and master secrets. regarding tls-unique channel binding mechanisms and master secrets.
As a mitigation, a TLS extension defined in As a mitigation, a TLS extension defined in [RFC7627] SHOULD be used
[I-D.ietf-tls-session-hash] SHOULD be used when tls-unique host when tls-unique host verification is to be used.
verification is to be used.
8. Authentication Extensions 8. Authentication Extensions
Interactive clients (e.g. Web browsers) supporting this protocol are Interactive clients (e.g. Web browsers) supporting this protocol are
RECOMMENDED to support non-mandatory authentication and the RECOMMENDED to support non-mandatory authentication and the
Authentication-Control header defined in Authentication-Control header defined in
[I-D.ietf-httpauth-extension], except the "auth-style" parameter. [I-D.ietf-httpauth-extension], except the "auth-style" parameter.
This specification also proposes (however, not mandates) default This specification also proposes (however, not mandates) default
"auth-style" to be "non-modal". Web applications SHOULD however "auth-style" to be "non-modal". Web applications SHOULD however
consider the security impacts of the behaviors of clients that do not consider the security impacts of the behaviors of clients that do not
skipping to change at page 27, line 37 skipping to change at page 27, line 36
9. String Preparation 9. String Preparation
It is important for interoperability that user-names and passwords It is important for interoperability that user-names and passwords
used in this protocol is binary-comparable regardless of the user's used in this protocol is binary-comparable regardless of the user's
input methods and/or environments. To ensure this, the following input methods and/or environments. To ensure this, the following
preparation SHOULD be performed: preparation SHOULD be performed:
o User-names received from users SHOULD be prepared using the o User-names received from users SHOULD be prepared using the
"UsernameCasePreserved" profile defined in Section 3.3 of "UsernameCasePreserved" profile defined in Section 3.3 of
[I-D.ietf-precis-saslprepbis]. [RFC7613].
o Passwords received from users SHOULD be prepared using the o Passwords received from users SHOULD be prepared using the
"OpaqueString" profile defined in Section 4.2 of "OpaqueString" profile defined in Section 4.2 of [RFC7613].
[I-D.ietf-precis-saslprepbis].
In both cases, it is the sender's duty to correctly preparing the In both cases, it is the sender's duty to correctly preparing the
character strings. If any non-normalized character string is character strings. If any non-normalized character string is
received from the other peer of the communication, recipients MAY received from the other peer of the communication, recipients MAY
either use it as a bare UTF-8 string without any preparation, perform either use it as a bare UTF-8 string without any preparation, perform
any appropriate preparations (which may cause authentication any appropriate preparations (which may cause authentication
failure), or reject any ill-prepared inputs from the sender and failure), or reject any ill-prepared inputs from the sender and
respond as a communication error. respond as a communication error.
Server applications SHOULD also prepare user-names and passwords Server applications SHOULD also prepare user-names and passwords
skipping to change at page 38, line 50 skipping to change at page 38, line 50
n. n.
12.2. Default Functions for Algorithms 12.2. Default Functions for Algorithms
The functions defined in this section are common default functions The functions defined in this section are common default functions
among authentication algorithms. among authentication algorithms.
The client-side password-based (credential) pi used by this The client-side password-based (credential) pi used by this
authentication is a natural number derived in the following manner: authentication is a natural number derived in the following manner:
pi = INT(PBKDF2(HMAC_H, ph(password), VS(algorithm) | VS(auth-domain) pi = INT(PBKDF2(HMAC_H, ph(password), VS(algorithm) | VS(auth-scope)
| VS(realm) | VS(username), nIterPi, hSize / 8)), | VS(realm) | VS(username), nIterPi, hSize / 8)),
where where
o PBKDF2 is the password-based key derivation function defined in o PBKDF2 is the password-based key derivation function defined in
[RFC2898], [RFC2898],
o HMAC_H is the HMAC function, defined in [RFC2104], composed from o HMAC_H is the HMAC function, defined in [RFC2104], composed from
the hash function H, and the hash function H, and
o hSize is the output size of hash H, counted in bits. o hSize is the output size of hash H, counted in bits.
The values of algorithm, realm, and auth-domain are taken from the The values of algorithm, realm, and auth-scope are taken from the
values contained in the 401-INIT message. The function ph is values contained in the 401-INIT message. The function ph is
determined by the value of the pwd-hash parameter given in a 401-INIT determined by the value of the pwd-hash parameter given in a 401-INIT
message. If the password comes from a user input, it SHOULD first be message. If the password comes from a user input, it SHOULD first be
prepared according to the method presented in Section 9. Then, the prepared according to the method presented in Section 9. Then, the
password SHALL be encoded as a UTF-8 string before passed to ph. password SHALL be encoded as a UTF-8 string before passed to ph.
The values VK_c and VK_s are derived by the following equation. The values VK_c and VK_s are derived by the following equation.
VK_c = INT(H(octet(4) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VK_c = INT(H(octet(4) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) |
VI(nc) | VS(vh))) VI(nc) | VS(vh)))
skipping to change at page 40, line 29 skipping to change at page 40, line 29
o Proxy-Authenticate: header is to be used for places where WWW- o Proxy-Authenticate: header is to be used for places where WWW-
Authenticate: is used, Authenticate: is used,
o Proxy-Authorization: header is to be used for places where o Proxy-Authorization: header is to be used for places where
Authorization: is used, Authorization: is used,
o Proxy-Authentication-Info: header is to be used for places where o Proxy-Authentication-Info: header is to be used for places where
Authentication-Info: is used, Authentication-Info: is used,
o The auth-domain parameter is fixed to the host-name of the proxy, o The auth-scope parameter is fixed to the host-name of the proxy,
which means to cover all requests processed through the specific which means to cover all requests processed through the specific
proxy, proxy,
o The limitation for the paths contained in the path parameter of o The limitation for the paths contained in the path parameter of
401-KEX-S1 messages is disregarded, 401-KEX-S1 messages is disregarded,
o The omission of the path parameter of 401-KEX-S1 messages means o The omission of the path parameter of 401-KEX-S1 messages means
that the authentication realm will potentially cover all requests that the authentication realm will potentially cover all requests
processed by the proxy, processed by the proxy,
skipping to change at page 46, line 8 skipping to change at page 46, line 8
session has expired. session has expired.
o For better protection against possible password database steal, o For better protection against possible password database steal,
Server-side storage of user passwords are better containing the Server-side storage of user passwords are better containing the
values encrypted by one-way function J(pi), instead of the real values encrypted by one-way function J(pi), instead of the real
passwords, those hashed by ph, or pi. passwords, those hashed by ph, or pi.
17.5. Usage Considerations 17.5. Usage Considerations
o The user-names inputted by a user may be sent automatically to any o The user-names inputted by a user may be sent automatically to any
servers sharing the same auth-domain. This means that when host- servers sharing the same auth-scope. This means that when host-
type auth-domain is used for authentication on an HTTPS site, and type auth-scope is used for authentication on an HTTPS site, and
when an HTTP server on the same host requests Mutual when an HTTP server on the same host requests Mutual
authentication within the same realm, the client will send the authentication within the same realm, the client will send the
user-name in a clear text. If user-names have to be kept secret user-name in a clear text. If user-names have to be kept secret
against eavesdropping, the server must use full-scheme-type auth- against eavesdropping, the server must use full-scheme-type auth-
domain parameter and HTTPS. Contrarily, passwords are not exposed scope parameter and HTTPS. Contrarily, passwords are not exposed
to eavesdroppers even on HTTP requests. to eavesdroppers even on HTTP requests.
o The "pwd-hash" parameter is only provided for backward o The "pwd-hash" parameter is only provided for backward
compatibility of password databases. The use of "none" function compatibility of password databases. The use of "none" function
is the most secure choice and is RECOMMENDED. If values other is the most secure choice and is RECOMMENDED. If values other
than "none" are used, you MUST ensure that the hash values of the than "none" are used, you MUST ensure that the hash values of the
passwords were not exposed to the public. Note that hashed passwords were not exposed to the public. Note that hashed
password databases for plain-text authentications are usually not password databases for plain-text authentications are usually not
considered secret. considered secret.
skipping to change at page 47, line 9 skipping to change at page 47, line 9
several existing third-party patents. The authors of the document several existing third-party patents. The authors of the document
take no position regarding the validity or scope of such patents, and take no position regarding the validity or scope of such patents, and
other patents as well. other patents as well.
19. References 19. References
19.1. Normative References 19.1. Normative References
[I-D.ietf-httpauth-extension] [I-D.ietf-httpauth-extension]
Oiwa, Y., Watanabe, H., Takagi, H., Hayashi, T., and Y. Oiwa, Y., Watanabe, H., Takagi, H., Hayashi, T., and Y.
Ioku, "HTTP Authentication Extensions for Interactive Ioku, "HTTP Authentication Extensions for Interactive
Clients", draft-ietf-httpauth-extension-04 (work in Clients", draft-ietf-httpauth-extension-05 (work in
progress), July 2015. progress), January 2016.
[I-D.ietf-httpbis-auth-info]
Reschke, J., "The Hypertext Transfer Protocol (HTTP)
Authentication-Info and Proxy- Authentication-Info
Response Header Fields", draft-ietf-httpbis-auth-info-05
(work in progress), April 2015.
[I-D.ietf-precis-saslprepbis]
Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords",
draft-ietf-precis-saslprepbis-18 (work in progress),
May 2015.
[I-D.ietf-tls-session-hash]
Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley,
A., and M. Ray, "Transport Layer Security (TLS) Session
Hash and Extended Master Secret Extension",
draft-ietf-tls-session-hash-05 (work in progress),
April 2015.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000. Specification Version 2.0", RFC 2898, DOI 10.17487/
RFC2898, September 2000,
<http://www.rfc-editor.org/info/rfc2898>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629,
November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5987] Reschke, J., "Character Set and Language Encoding for [RFC5987] Reschke, J., "Character Set and Language Encoding for
Hypertext Transfer Protocol (HTTP) Header Field Hypertext Transfer Protocol (HTTP) Header Field
Parameters", RFC 5987, August 2010. Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010,
<http://www.rfc-editor.org/info/rfc5987>.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
(HTTP/1.1): Message Syntax and Routing", RFC 7230, Protocol (HTTP/1.1): Message Syntax and Routing",
June 2014. RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
(HTTP/1.1): Authentication", RFC 7235, June 2014. Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<http://www.rfc-editor.org/info/rfc7235>.
[RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", RFC 7613,
DOI 10.17487/RFC7613, August 2015,
<http://www.rfc-editor.org/info/rfc7613>.
[RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy-
Authentication-Info Response Header Fields", RFC 7615,
DOI 10.17487/RFC7615, September 2015,
<http://www.rfc-editor.org/info/rfc7615>.
19.2. Informative References 19.2. Informative References
[I-D.ietf-httpauth-mutual-algo] [I-D.ietf-httpauth-mutual-algo]
Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi,
T., and Y. Ioku, "Mutual Authentication Protocol for HTTP: T., and Y. Ioku, "Mutual Authentication Protocol for HTTP:
KAM3-based Cryptographic Algorithms", KAM3-based Cryptographic Algorithms",
draft-ietf-httpauth-mutual-algo-03 (work in progress), draft-ietf-httpauth-mutual-algo-04 (work in progress),
July 2015. January 2016.
[ISO.10646-1.1993] [ISO.10646-1.1993]
International Organization for Standardization, International Organization for Standardization,
"Information Technology - Universal Multiple-octet coded "Information Technology - Universal Multiple-octet coded
Character Set (UCS) - Part 1: Architecture and Basic Character Set (UCS) - Part 1: Architecture and Basic
Multilingual Plane", ISO Standard 10646-1, May 1993. Multilingual Plane", ISO Standard 10646-1, May 1993.
[ITU.X690.1994] [ITU.X690.1994]
International Telecommunications Union, "Information International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, 1994. X.690, 1994.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996. STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
<http://www.rfc-editor.org/info/rfc1939>.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/
RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, July 2010. for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
<http://www.rfc-editor.org/info/rfc5929>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. DOI 10.17487/RFC6265, April 2011,
<http://www.rfc-editor.org/info/rfc6265>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
December 2011. DOI 10.17487/RFC6454, December 2011,
<http://www.rfc-editor.org/info/rfc6454>.
[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation, Enforcement, and Comparison of Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols", Internationalized Strings in Application Protocols",
RFC 7564, May 2015. RFC 7564, DOI 10.17487/RFC7564, May 2015,
<http://www.rfc-editor.org/info/rfc7564>.
Appendix A. (Informative) Draft Remarks from Authors
The following items are currently under consideration for future
revisions by the authors.
o Whether to keep TLS-unique validation or not. [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616, DOI 10.17487/
RFC7616, September 2015,
<http://www.rfc-editor.org/info/rfc7616>.
o Whether to introduce password strengthening hashes other than [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
PBKDF2 into the function pi(). This requires standardization of Langley, A., and M. Ray, "Transport Layer Security (TLS)
such other hash algorithms in IETF. Session Hash and Extended Master Secret Extension",
RFC 7627, DOI 10.17487/RFC7627, September 2015,
<http://www.rfc-editor.org/info/rfc7627>.
o Whether to modify current definition of nIterPi, which is per- Appendix A. (Informative) Draft Change Log
algorithm defined. To increase this parameter requires defining a
new algorithm, possibly with reconsideration for other security
parameters as well.
o Whether to keep ph() function for legacy migration or not. A.1. Changes in Httpauth WG Revision 06
o Adding test vectors for ensuring implementation correctness. o The auth-domain parameter has been renamed to auth-scope,
following suggestions on the mailing list.
o Possibly adding a method for servers to detect availability of o The digest-md5 password-hash has been dropped, as Digest with MD5
Mutual authentication on client-side. hash is now obsoleted.
Appendix B. (Informative) Draft Change Log A.2. Changes in Httpauth WG Revision 05
B.1. Changes in Httpauth WG Revision 05
o Minimum nonce number window has increased to 128. (HTTP 2.0 o Minimum nonce number window has increased to 128. (HTTP 2.0
recommends at least 100 concurrent sessions to exist) recommends at least 100 concurrent sessions to exist)
o Reference to TLS session hash extension added for tls-unique o Reference to TLS session hash extension added for tls-unique
security issues. security issues.
o Comments in the previous F2F meeting has been reflected to the o Comments in the previous F2F meeting has been reflected to the
text. text.
B.2. Changes in Httpauth WG Revision 04 A.3. Changes in Httpauth WG Revision 04
o Merged httpauthprep proposal into general PRECIS Username/Password o Merged httpauthprep proposal into general PRECIS Username/Password
profile. profile.
o Adopting RFC 5987 extended syntax for non-ASCII parameter values. o Adopting RFC 5987 extended syntax for non-ASCII parameter values.
o Refer draft-ietf-httpbis-auth-info for Authentication-Info header. o Refer draft-ietf-httpbis-auth-info for Authentication-Info header.
This results in a different syntax for that header. This results in a different syntax for that header.
B.3. Changes in Httpauth WG Revision 03 A.4. Changes in Httpauth WG Revision 03
o Incompatible change: Single-port type authentication realm label o Incompatible change: Single-port type authentication realm label
has been changed to harmonize with Web Origin. (That is, the has been changed to harmonize with Web Origin. (That is, the
default ports (80 and 443) are to be omitted.) default ports (80 and 443) are to be omitted.)
B.4. Changes in Httpauth WG Revision 02 A.5. Changes in Httpauth WG Revision 02
o Major change: introduction of password-strengthening function o Major change: introduction of password-strengthening function
PBKDF2. PBKDF2.
o Changed Section 10 to adopt "list of requirements" style. Strict o Changed Section 10 to adopt "list of requirements" style. Strict
definition of state machine is now a derived, informational definition of state machine is now a derived, informational
definition. definition.
B.5. Changes in Httpauth WG Revision 01 A.6. Changes in Httpauth WG Revision 01
o Changed "tls-key" verification to "tls-unique" verification, and o Changed "tls-key" verification to "tls-unique" verification, and
"tls-cert" to "tls-server-end-point", adopting RFC 5929. "tls-cert" to "tls-server-end-point", adopting RFC 5929.
o Adopted PRECIS framework [RFC7564]. o Adopted PRECIS framework [RFC7564].
o Reverted reservation of "rekey-sid" and "rekey-method" parameters. o Reverted reservation of "rekey-sid" and "rekey-method" parameters.
o Degraded secure UI requirement to application note level, non- o Degraded secure UI requirement to application note level, non-
normative. normative.
o Adjusted levels of several requirements. o Adjusted levels of several requirements.
o Added warning text for handling of exceptional 5XX responses. o Added warning text for handling of exceptional 5XX responses.
o Dropped several references for optional authentications, except o Dropped several references for optional authentications, except
one "Note". one "Note".
o Several textual fixes, improvements and revisions. o Several textual fixes, improvements and revisions.
B.6. Changes in Httpauth Revision 00 A.7. Changes in Httpauth Revision 00
o Changed the version token. o Changed the version token.
o Renamed "verification tokens" to "Host verification tokens" and o Renamed "verification tokens" to "Host verification tokens" and
variables "v" to "vh" for clarification. (Back-ported from variables "v" to "vh" for clarification. (Back-ported from
draft-oiwa-httpauth-multihop-template-00) draft-oiwa-httpauth-multihop-template-00)
B.7. Changes in HttpBis Revision 00 A.8. Changes in HttpBis Revision 00
None. None.
B.8. Changes in Revision 12 A.9. Changes in Revision 12
o Added a reason "authz-failed". o Added a reason "authz-failed".
B.9. Changes in Revision 11 A.10. Changes in Revision 11
o Message syntax definition reverted to pre-07 style as httpbis-p1 o Message syntax definition reverted to pre-07 style as httpbis-p1
and p7 now defines a precise rule for parameter value parsing. and p7 now defines a precise rule for parameter value parsing.
o Replaced "stale" parameter with more informative/extensive o Replaced "stale" parameter with more informative/extensive
"reason" parameter in 401-INIT and 401-STALE. "reason" parameter in 401-INIT and 401-STALE.
o Reserved "rekey-sid" and "rekey-method" parameters for future o Reserved "rekey-sid" and "rekey-method" parameters for future
extensions. extensions.
o Added descriptions for replacing/non-replacing existing o Added descriptions for replacing/non-replacing existing
technologies. technologies.
B.10. Changes in Revision 10 A.11. Changes in Revision 10
o The authentication extension parts (non-mandatory authentication o The authentication extension parts (non-mandatory authentication
and authentication controls) are separated to yet another draft. and authentication controls) are separated to yet another draft.
o The default auth-domain parameter is changed to the full scheme- o The default auth-domain parameter is changed to the full scheme-
host-port syntax, which is consistent with usual HTTP host-port syntax, which is consistent with usual HTTP
authentication framework behavior. authentication framework behavior.
o Provision for application channel binding is added. o Provision for application channel binding is added.
skipping to change at page 52, line 36 skipping to change at page 52, line 40
+------------+----------+-------------------------------------------+ +------------+----------+-------------------------------------------+
| S_c1, S_s1 | s_a, s_b | client/server-side secret randoms | | S_c1, S_s1 | s_a, s_b | client/server-side secret randoms |
| K_c1, K_s1 | w_a, w_b | client/server-side exchanged key | | K_c1, K_s1 | w_a, w_b | client/server-side exchanged key |
| | | components | | | | components |
| kc1, ks1 | wa, wb | parameter names for those | | kc1, ks1 | wa, wb | parameter names for those |
| VK_c, VK_s | o_a, o_b | client/server-side key verifiers | | VK_c, VK_s | o_a, o_b | client/server-side key verifiers |
| vkc, vks | oa, ob | parameter names for those | | vkc, vks | oa, ob | parameter names for those |
| z | z | session secrets | | z | z | session secrets |
+------------+----------+-------------------------------------------+ +------------+----------+-------------------------------------------+
B.11. Changes in Revision 09 A.12. Changes in Revision 09
o The (default) cryptographic algorithms are separated to another o The (default) cryptographic algorithms are separated to another
draft. draft.
o Names of the messages are changed to more informative ones than o Names of the messages are changed to more informative ones than
before. The following is the correspondence table of those names: before. The following is the correspondence table of those names:
+-------------------+-----------------+-----------------------------+ +-------------------+-----------------+-----------------------------+
| new name | old name | description | | new name | old name | description |
+-------------------+-----------------+-----------------------------+ +-------------------+-----------------+-----------------------------+
skipping to change at page 53, line 20 skipping to change at page 53, line 20
| req-KEX-C1 | req-A1 | client->server key exchange | | req-KEX-C1 | req-A1 | client->server key exchange |
| 401-KEX-S1 | 401-B1 | server->client key exchange | | 401-KEX-S1 | 401-B1 | server->client key exchange |
| req-VFY-C | req-A3 | client->server auth. | | req-VFY-C | req-A3 | client->server auth. |
| | | verification | | | | verification |
| 200-VFY-S | 200-B4 | server->client auth. | | 200-VFY-S | 200-B4 | server->client auth. |
| | | verification | | | | verification |
| 200-Optional-INIT | 200-Optional-B0 | initial with non-mandatory | | 200-Optional-INIT | 200-Optional-B0 | initial with non-mandatory |
| | | authentication | | | | authentication |
+-------------------+-----------------+-----------------------------+ +-------------------+-----------------+-----------------------------+
B.12. Changes in Revision 08 A.13. Changes in Revision 08
o The English text has been revised. o The English text has been revised.
B.13. Changes in Revision 07 A.14. Changes in Revision 07
o Adapt to httpbis HTTP/1.1 drafts: o Adapt to httpbis HTTP/1.1 drafts:
* Changed definition of extensive-token. * Changed definition of extensive-token.
* LWSP continuation-line (%0D.0A.20) deprecated. * LWSP continuation-line (%0D.0A.20) deprecated.
o To simplify the whole spec, the type of nonce-counter related o To simplify the whole spec, the type of nonce-counter related
parameters are change from hex-integer to integer. parameters are change from hex-integer to integer.
o Algorithm tokens are renamed to include names of hash algorithms. o Algorithm tokens are renamed to include names of hash algorithms.
o Clarified the session management, added details of server-side o Clarified the session management, added details of server-side
protocol decisions. protocol decisions.
o The whole draft was reorganized; introduction and overview has o The whole draft was reorganized; introduction and overview has
been rewritten. been rewritten.
B.14. Changes in Revision 06 A.15. Changes in Revision 06
o Integrated Optional Mutual Authentication to the main part. o Integrated Optional Mutual Authentication to the main part.
o Clarified the decision procedure for message recognitions. o Clarified the decision procedure for message recognitions.
o Clarified that a new authentication request for any sub-requests o Clarified that a new authentication request for any sub-requests
in interactive clients may be silently discarded. in interactive clients may be silently discarded.
o Typos and confusing phrases are fixed. o Typos and confusing phrases are fixed.
o Several "future considerations" are added. o Several "future considerations" are added.
B.15. Changes in Revision 05 A.16. Changes in Revision 05
o A new parameter called "version" is added for supporting future o A new parameter called "version" is added for supporting future
incompatible changes with a single implementation. In the (first) incompatible changes with a single implementation. In the (first)
final specification its value will be changed to 1. final specification its value will be changed to 1.
o A new header "Authentication-Control" is added for precise control o A new header "Authentication-Control" is added for precise control
of application-level authentication behavior. of application-level authentication behavior.
B.16. Changes in Revision 04 A.17. Changes in Revision 04
o Changed text of patent licenses: the phrase "once the protocol is o Changed text of patent licenses: the phrase "once the protocol is
accepted as an Internet standard" is removed so that the sentence accepted as an Internet standard" is removed so that the sentence
also covers the draft versions of this protocol. also covers the draft versions of this protocol.
o The "tls-key" verification is now OPTIONAL. o The "tls-key" verification is now OPTIONAL.
o Several description fixes and clarifications. o Several description fixes and clarifications.
B.17. Changes in Revision 03 A.18. Changes in Revision 03
o Wildcard domain specifications (e.g. "*.example.com") are allowed o Wildcard domain specifications (e.g. "*.example.com") are allowed
for auth-domain parameters (Section 4.1). for auth-domain parameters (Section 4.1).
o Specification of the tls-cert verification is updated o Specification of the tls-cert verification is updated
(incompatible change). (incompatible change).
o State transitions fixed. o State transitions fixed.
o Requirements for servers concerning w_a values are clarified. o Requirements for servers concerning w_a values are clarified.
o RFC references are updated. o RFC references are updated.
B.18. Changes in Revision 02 A.19. Changes in Revision 02
o Auth-realm is extended to allow full-scheme type. o Auth-realm is extended to allow full-scheme type.
o A decision diagram for clients and decision procedures for servers o A decision diagram for clients and decision procedures for servers
are added. are added.
o 401-B1 and req-A3 messages are changed to contain authentication o 401-B1 and req-A3 messages are changed to contain authentication
realm information. realm information.
o Bugs on equations for o_A and o_B are fixed. o Bugs on equations for o_A and o_B are fixed.
o Detailed equations for the entire algorithm are included. o Detailed equations for the entire algorithm are included.
o Elliptic-curve algorithms are updated. o Elliptic-curve algorithms are updated.
o Several clarifications and other minor updates. o Several clarifications and other minor updates.
B.19. Changes in Revision 01 A.20. Changes in Revision 01
o Several texts are rewritten for clarification. o Several texts are rewritten for clarification.
o Added several security consideration clauses. o Added several security consideration clauses.
Authors' Addresses Authors' Addresses
Yutaka Oiwa Yutaka Oiwa
National Institute of Advanced Industrial Science and Technology National Institute of Advanced Industrial Science and Technology
Information Technology Research Institute Information Technology Research Institute
Tsukuba Central 2 Tsukuba Central 1
1-1-1 Umezono 1-1-1 Umezono
Tsukuba-shi, Ibaraki Tsukuba-shi, Ibaraki
JP JP
Email: mutual-auth-contact-ml@aist.go.jp Email: mutual-auth-contact-ml@aist.go.jp
Hajime Watanabe Hajime Watanabe
National Institute of Advanced Industrial Science and Technology National Institute of Advanced Industrial Science and Technology
Information Technology Research Institute Information Technology Research Institute
Tsukuba Central 2 Tsukuba Central 1
1-1-1 Umezono 1-1-1 Umezono
Tsukuba-shi, Ibaraki Tsukuba-shi, Ibaraki
JP JP
Hiromitsu Takagi Hiromitsu Takagi
National Institute of Advanced Industrial Science and Technology National Institute of Advanced Industrial Science and Technology
Information Technology Research Institute Information Technology Research Institute
Tsukuba Central 2 Tsukuba Central 1
1-1-1 Umezono 1-1-1 Umezono
Tsukuba-shi, Ibaraki Tsukuba-shi, Ibaraki
JP JP
Kaoru Maeda Kaoru Maeda
Lepidum Co. Ltd. Lepidum Co. Ltd.
Village Sasazuka 3, Suite #602 Village Sasazuka 3, Suite #602
1-30-3 Sasazuka 1-30-3 Sasazuka
Shibuya-ku, Tokyo Shibuya-ku, Tokyo
JP JP
 End of changes. 82 change blocks. 
155 lines changed or deleted 155 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/