draft-ietf-httpauth-mutual-02.txt   draft-ietf-httpauth-mutual-03.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: October 26, 2014 RISEC, AIST Expires: February 20, 2015 RISEC, AIST
K. Maeda K. Maeda
T. Hayashi T. Hayashi
Lepidum Lepidum
Y. Ioku Y. Ioku
Individual Individual
April 24, 2014 August 19, 2014
Mutual Authentication Protocol for HTTP Mutual Authentication Protocol for HTTP
draft-ietf-httpauth-mutual-02 draft-ietf-httpauth-mutual-03
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 October 26, 2014. This Internet-Draft will expire on February 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 15 skipping to change at page 3, line 15
16.1. Security Properties . . . . . . . . . . . . . . . . . . . 40 16.1. Security Properties . . . . . . . . . . . . . . . . . . . 40
16.2. Denial-of-service Attacks to Servers . . . . . . . . . . . 41 16.2. Denial-of-service Attacks to Servers . . . . . . . . . . . 41
16.2.1. On-line Active Password Attacks . . . . . . . . . . . 41 16.2.1. On-line Active Password Attacks . . . . . . . . . . . 41
16.3. Communicating the status of mutual authentication with 16.3. Communicating the status of mutual authentication with
users . . . . . . . . . . . . . . . . . . . . . . . . . . 42 users . . . . . . . . . . . . . . . . . . . . . . . . . . 42
16.4. Implementation Considerations . . . . . . . . . . . . . . 42 16.4. Implementation Considerations . . . . . . . . . . . . . . 42
16.5. Usage Considerations . . . . . . . . . . . . . . . . . . . 43 16.5. Usage Considerations . . . . . . . . . . . . . . . . . . . 43
17. Notice on Intellectual Properties . . . . . . . . . . . . . . 43 17. Notice on Intellectual Properties . . . . . . . . . . . . . . 43
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
18.1. Normative References . . . . . . . . . . . . . . . . . . . 44 18.1. Normative References . . . . . . . . . . . . . . . . . . . 44
18.2. Informative References . . . . . . . . . . . . . . . . . . 45 18.2. Informative References . . . . . . . . . . . . . . . . . . 44
Appendix A. (Informative) Draft Remarks from Authors . . . . . . 46 Appendix A. (Informative) Draft Remarks from Authors . . . . . . 46
Appendix B. (Informative) Draft Change Log . . . . . . . . . . . 46 Appendix B. (Informative) Draft Change Log . . . . . . . . . . . 46
B.1. Changes in Httpauth WG Revision 02 . . . . . . . . . . . . 46 B.1. Changes in Httpauth WG Revision 03 . . . . . . . . . . . . 46
B.2. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 46 B.2. Changes in Httpauth WG Revision 02 . . . . . . . . . . . . 46
B.3. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 47 B.3. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 47
B.4. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 47 B.4. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 47
B.5. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 47 B.5. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 47
B.6. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 47 B.6. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 47
B.7. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 47 B.7. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 47
B.8. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 48 B.8. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 48
B.9. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 49 B.9. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 48
B.10. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 49 B.10. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 49
B.11. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 49 B.11. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 49
B.12. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 50 B.12. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 49
B.13. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 50 B.13. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 50
B.14. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 50 B.14. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 50
B.15. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 50 B.15. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 50
B.16. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 51 B.16. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 50
B.17. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
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 5, line 29 skipping to change at page 5, line 29
o The sections after that contain general normative and informative o The sections after that contain general normative and informative
information about the protocol. information about the protocol.
o The appendices contain some information that may help developers o The appendices contain some information that may help developers
to implement the protocol. to implement the protocol.
In addition, there are two companion documents which are referred In addition, there are two companion documents which are referred
from/related to this specification: from/related to this specification:
o [I-D.oiwa-httpauth-mutual-algo]: defines a cryptographic o [I-D.ietf-httpauth-mutual-algo]: defines a cryptographic
primitives which can be used with this protocol framework. [draft primitives which can be used with this protocol framework. [draft
note: it is separated from this document so that it may be note: it is separated from this document so that it may be
replaced with another crypto in future.] replaced with another crypto in future.]
o [I-D.ietf-httpauth-extension]: defines a small but useful o [I-D.ietf-httpauth-extension]: defines a small but useful
extensions to the current HTTP authentication framework so that it extensions to the current HTTP authentication framework so that it
can support application-level semantics of existing Web systems. can support application-level semantics of existing Web systems.
2. Protocol Overview 2. Protocol Overview
The protocol, as a whole, is designed as a natural extension to the The protocol, as a whole, is designed as a natural extension to the
HTTP protocol [I-D.ietf-httpbis-p1-messaging] using a framework HTTP protocol [RFC7230] using a framework defined in [RFC7235].
defined in [I-D.ietf-httpbis-p7-auth]. Internally, the server and Internally, the server and the client will first perform a
the client will first perform a cryptographic key exchange, using the cryptographic key exchange, using the secret password as a "tweak" to
secret password as a "tweak" to the exchange. The key-exchange will the exchange. The key-exchange will only succeed when the secrets
only succeed when the secrets used by the both peers are correctly used by the both peers are correctly related (i.e. generated from the
related (i.e. generated from the same password). Then, both peers same password). Then, both peers will verify the authentication
will verify the authentication results by confirming the sharing of results by confirming the sharing of the exchanged key. This section
the exchanged key. This section describes a brief image of the describes a brief image of the protocol and the exchanged messages.
protocol and the exchanged messages.
2.1. Messages Overview 2.1. Messages Overview
The authentication protocol uses seven kinds of messages to perform The authentication protocol uses seven kinds of messages to perform
mutual authentication. These messages have specific names within mutual authentication. These messages have specific names within
this specification. this specification.
o Authentication request messages: used by the servers to request o Authentication request messages: used by the servers to request
clients to start mutual authentication. clients to start mutual authentication.
skipping to change at page 10, line 46 skipping to change at page 10, line 46
| <------- 200-VFY-S --- | | <------- 200-VFY-S --- |
| | | |
Figure 2: Several alternative flows on protocol Figure 2: Several alternative flows on protocol
For more details, see Sections 9 and 10. For more details, see Sections 9 and 10.
3. Message Syntax 3. Message Syntax
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 [I-D.ietf-httpbis-p1-messaging] and augmented BNF syntax defined in [RFC7230] and [RFC5234]. The
[RFC5234]. The following elements are quoted from [RFC5234], following elements are quoted from [RFC5234], [RFC7230] and
[I-D.ietf-httpbis-p1-messaging] and [I-D.ietf-httpbis-p7-auth]: [RFC7235]: DIGIT, ALPHA, SP, auth-scheme, quoted-string, auth-param,
DIGIT, ALPHA, SP, auth-scheme, quoted-string, auth-param, header- header-field, token, challenge, and credential.
field, token, challenge, and credential.
The Mutual authentication protocol uses three headers: The Mutual authentication protocol uses three headers:
WWW-Authenticate (in responses with status code 401), Authorization WWW-Authenticate (in responses with status code 401), Authorization
(in requests), and Authentication-Info (in responses other than 401 (in requests), and Authentication-Info (in responses other than 401
status). These headers follow a common framework described in status). These headers follow a common framework described in
[I-D.ietf-httpbis-p7-auth]. The detailed meanings for these headers [RFC7235]. The detailed meanings for these headers are contained in
are contained in Section 4. Section 4.
The framework in [I-D.ietf-httpbis-p7-auth] defines the syntax for The framework in [RFC7235] defines the syntax for the headers
the headers WWW-Authenticate and Authorization as the syntax elements WWW-Authenticate and Authorization as the syntax elements "challenge"
"challenge" and "credentials", respectively. The "auth-scheme" and "credentials", respectively. The "auth-scheme" contained in
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 [I-D.ietf-httpbis-p7-auth]. param), not the "b64token" defined in [RFC7235].
The Authentication-Info: header used in this protocol SHALL contain The Authentication-Info: header used in this protocol SHALL contain
the value in same syntax as those the "WWW-Authenticate" header, i.e. the value in same syntax as those the "WWW-Authenticate" header, i.e.
the "challenge" syntax element. the "challenge" syntax element.
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. Values 3.1. Values
skipping to change at page 14, line 33 skipping to change at page 14, line 33
They MUST NOT contain any "kc*" and "vkc" parameters. They MUST NOT contain any "kc*" and "vkc" parameters.
o For requests, the parameters "kc*" (where * stands for any decimal o For requests, the parameters "kc*" (where * stands for any decimal
integers), and "vkc" are mutually exclusive and any challenge integers), and "vkc" are mutually exclusive and any challenge
MUST NOT contain two or more parameters among them. They MUST NOT MUST NOT contain two or more parameters among them. They MUST NOT
contain any "ks*" and "vks" parameters. contain any "ks*" and "vks" parameters.
Every message in this section contains a "version" field, to detect Every message in this section contains a "version" field, to detect
future incompatible revisions of the protocol. Implementations of future incompatible revisions of the protocol. Implementations of
the protocol described in this specification MUST always send a token the protocol described in this specification MUST always send a token
"-wg-draft02", and recipients MUST reject messages which contain any "-wg-draft03", and recipients MUST reject messages which contain any
other value as a version, unless another specification defines a other value as a version, unless another specification defines a
behavior for that version. [[Editorial Note: This token is updated behavior for that version. [[Editorial Note: This token is updated
on every draft revisions which will affect the wire protocol. It on every draft revisions which will affect the wire protocol. It
will (shall) be updated to "1" in the final published RFC.]] will (shall) be updated to "1" in the final published RFC.]]
4.1. 401-INIT and 401-STALE 4.1. 401-INIT and 401-STALE
Every 401-INIT or 401-STALE message SHALL be a valid HTTP 401-status Every 401-INIT or 401-STALE message SHALL be a valid HTTP 401-status
(Authentication Required) message containing one (and only one: (Authentication Required) message containing one (and only one:
hereafter not explicitly noticed) "WWW-Authenticate" header hereafter not explicitly noticed) "WWW-Authenticate" header
containing a "reason" parameter in the challenge. The challenge containing a "reason" parameter in the challenge. The challenge
SHALL contain all of the parameters marked "mandatory" below, and MAY SHALL contain all of the parameters marked "mandatory" below, and MAY
contain those marked "non-mandatory". contain those marked "non-mandatory".
version: (mandatory extensive-token) should be the token "-wg- version: (mandatory extensive-token) should be the token "-wg-
draft02". draft03".
algorithm: (mandatory extensive-token) specifies the algorithm: (mandatory extensive-token) specifies the
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.oiwa-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-domain: (non-mandatory string) specifies the authentication
domain, the set of hosts for which the authentication domain, 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 UTF-8 encoded string realm: (mandatory string) is a UTF-8 encoded string
representing the name of the authentication realm representing the name of the authentication realm
inside the authentication domain. As specified in inside the authentication domain. As specified in
[I-D.ietf-httpbis-p7-auth], this value MUST always be [RFC7235], this value MUST always be sent in the
sent in the quoted-string form. quoted-string form.
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)
skipping to change at page 17, line 21 skipping to change at page 17, line 21
4.2. req-KEX-C1 4.2. req-KEX-C1
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-
draft02". draft03".
algorithm, validation, auth-domain, realm: MUST be the same value as algorithm, validation, auth-domain, 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. If this name comes from a user input, client user. If this name comes from a user input, client
software SHOULD prepare the string using HTTPAUTHprep software SHOULD prepare the string using HTTPAUTHprep
[I-D.oiwa-precis-httpauthprep] before encoding it to [I-D.oiwa-precis-httpauthprep] before encoding it to
UTF-8. [[Editorial: merger with new SASLprep is being UTF-8. [[Editorial: merger with new SASLprep is being
considered and discussed in precis WG. Replace the considered and discussed in precis WG. Replace the
skipping to change at page 17, line 48 skipping to change at page 17, line 48
4.3. 401-KEX-S1 4.3. 401-KEX-S1
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-
draft02". draft03".
algorithm, validation, auth-domain, realm: MUST be the same value as algorithm, validation, auth-domain, 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.
skipping to change at page 19, line 6 skipping to change at page 19, line 6
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-
draft02". draft03".
algorithm, validation, auth-domain, realm: MUST be the same value as algorithm, validation, auth-domain, 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 value that is unique nc: (mandatory, integer) is a nonce value that is unique
among the requests sharing the same sid. The values among the requests sharing the same sid. The values
skipping to change at page 19, line 33 skipping to change at page 19, line 33
4.5. 200-VFY-S 4.5. 200-VFY-S
Every 200-VFY-S message SHALL be a valid HTTP message that is not of Every 200-VFY-S message SHALL be a valid HTTP message that is not of
the 401 (Authentication Required) status, containing an the 401 (Authentication Required) status, containing an
"Authentication-Info" header with a "vks" parameter. "Authentication-Info" header with a "vks" 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-
draft02". draft03".
sid: (mandatory, hex-fixed-number) MUST be the value sid: (mandatory, hex-fixed-number) MUST be the value
received from the client. received from the client.
vks: (mandatory, algorithm-determined) is the server-side vks: (mandatory, algorithm-determined) is the server-side
authentication verification value VK_s, which is authentication verification value VK_s, which is
specified by the algorithm. specified by the algorithm.
The header MUST be sent before the content body: it MUST NOT be sent The header MUST be sent before the content body: it MUST NOT be sent
in the trailer of a chunked-encoded response. If a "100 Continue" in the trailer of a chunked-encoded response. If a "100 Continue"
skipping to change at page 20, line 30 skipping to change at page 20, line 30
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 domains are described in the remainder of this
section. section.
An authentication domain specifies the range of hosts that the An authentication domain 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 strings.
o Single-server type: The string in format 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. Even if the the corresponding URI parts of the request URI. If the default
request-URI does not have a port part, the string will include one port (i.e. 80 for http and 443 for https) is used for the
(i.e. 80 for http and 443 for https). The port part MUST NOT underlying HTTP communications, the port part MUST be omitted,
contain leading zeros. Use this when authentication is only valid regardless of whether it was present in the request-URI. In other
for specific protocol (such as https). cases, the port part MUST be present, and it MUST NOT contain
leading zeros. Use this when authentication is only valid for
specific protocol (such as https). This format is equivalent to
the ASCII serialization of a Web Origin, presented in Section 6.2
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 domain 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
skipping to change at page 40, line 11 skipping to change at page 40, line 11
If a private extension to this protocol is implemented, it MUST use If a private extension to this protocol is implemented, it MUST use
the extension-tokens defined in Section 3 to avoid conflicts with the extension-tokens defined in Section 3 to avoid conflicts with
this protocol and other extensions. (standardized or being- this protocol and other extensions. (standardized or being-
standardizing extensions MAY use either bare-tokens or extension- standardizing extensions MAY use either bare-tokens or extension-
tokens.) tokens.)
Specifications defining authentication algorithms MAY use other Specifications defining authentication algorithms MAY use other
representations for the parameters "kc1", "ks1", "vkc", and "vks", representations for the parameters "kc1", "ks1", "vkc", and "vks",
replace those parameter names, and/or add parameters to the messages replace those parameter names, and/or add parameters to the messages
containing those parameters in supplemental specifications, provided containing those parameters in supplemental specifications, provided
that syntactic and semantic requirements in Section 3, that syntactic and semantic requirements in Section 3, [RFC7230] and
[I-D.ietf-httpbis-p1-messaging] and [I-D.ietf-httpbis-p7-auth] are [RFC7235] are satisfied. Any parameters starting with "kc", "ks",
satisfied. Any parameters starting with "kc", "ks", "vkc" or "vks" "vkc" or "vks" and followed by decimal natural numbers (e.g. kc2,
and followed by decimal natural numbers (e.g. kc2, ks0, vkc1, vks3 ks0, vkc1, vks3 etc.) are reserved for this purpose. If those
etc.) are reserved for this purpose. If those specifications use specifications use names other than those mentioned above, it is
names other than those mentioned above, it is RECOMMENDED to use RECOMMENDED to use extension-tokens to avoid any parameter name
extension-tokens to avoid any parameter name conflict with the future conflict with the future extension of this protocol.
extension of this protocol.
Extension-tokens MAY be freely used for any non-standard, private, Extension-tokens MAY be freely used for any non-standard, private,
and/or experimental uses for those parameters provided that the and/or experimental uses for those parameters provided that the
domain part in the token is appropriately used. domain part in the token is appropriately used.
15. IANA Considerations 15. IANA Considerations
When bare-tokens are used for the authentication-algorithm, pwd-hash, When bare-tokens are used for the authentication-algorithm, pwd-hash,
and validation parameters MUST be allocated by IANA. To acquire and validation parameters MUST be allocated by IANA. To acquire
registered tokens, a specification for the use of such tokens MUST be registered tokens, a specification for the use of such tokens MUST be
skipping to change at page 44, line 9 skipping to change at page 44, 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.
18. References 18. References
18.1. Normative References 18.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-01 (work in Clients", draft-ietf-httpauth-extension-02 (work in
progress), October 2013. progress), August 2014.
[I-D.ietf-httpbis-p1-messaging]
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-26 (work in progress),
February 2014.
[I-D.ietf-httpbis-p7-auth]
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-26
(work in progress), February 2014.
[I-D.oiwa-precis-httpauthprep] [I-D.oiwa-precis-httpauthprep]
Oiwa, Y., Nemoto, T., and B. Kihara, "HTTPAuthPrep: PRECIS Oiwa, Y., Nemoto, T., and B. Kihara, "HTTPAuthPrep: PRECIS
profile for HTTP Authentication", profile for HTTP Authentication",
draft-oiwa-precis-httpauthprep-00 (work in progress), draft-oiwa-precis-httpauthprep-00 (work in progress),
July 2013. July 2013.
[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. February 1997.
skipping to change at page 45, line 5 skipping to change at page 44, line 40
[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, October 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[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, August 2008.
18.2. Informative References [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230,
June 2014.
[I-D.ietf-precis-framework] [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
Saint-Andre, P. and M. Blanchet, "PRECIS Framework: (HTTP/1.1): Authentication", RFC 7235, June 2014.
Preparation and Comparison of Internationalized Strings in
Application Protocols", draft-ietf-precis-framework-16
(work in progress), April 2014.
[I-D.oiwa-httpauth-mutual-algo] 18.2. Informative References
[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-oiwa-httpauth-mutual-algo-02 (work in progress), draft-ietf-httpauth-mutual-algo-01 (work in progress),
April 2014. August 2014.
[I-D.ietf-precis-framework]
Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation and Comparison of Internationalized Strings in
Application Protocols", draft-ietf-precis-framework-17
(work in progress), May 2014.
[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
skipping to change at page 46, line 8 skipping to change at page 45, line 52
[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, August 2010.
[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, July 2010.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
December 2011.
Appendix A. (Informative) Draft Remarks from Authors Appendix A. (Informative) Draft Remarks from Authors
The following items are currently under consideration for future The following items are currently under consideration for future
revisions by the authors. revisions by the authors.
o Whether to keep TLS-unique validation or not. o Whether to keep TLS-unique validation or not.
o Whether to introduce password strengthening hashes other than o Whether to introduce password strengthening hashes other than
PBKDF2 into the function pi(). This requires standardization of PBKDF2 into the function pi(). This requires standardization of
such other hash algorithms in IETF. such other hash algorithms in IETF.
skipping to change at page 46, line 33 skipping to change at page 46, line 31
o Whether to keep ph() function for legacy migration or not. o Whether to keep ph() function for legacy migration or not.
o Adding test vectors for ensuring implementation correctness. o Adding test vectors for ensuring implementation correctness.
o Possibly adding a method for servers to detect availability of o Possibly adding a method for servers to detect availability of
Mutual authentication on client-side. Mutual authentication on client-side.
Appendix B. (Informative) Draft Change Log Appendix B. (Informative) Draft Change Log
B.1. Changes in Httpauth WG Revision 02 B.1. Changes in Httpauth WG Revision 03
o Incompatible change: Single-port type authentication realm label
has been changed to harmonize with Web Origin. (That is, the
default ports (80 and 443) are to be omitted.)
B.2. Changes in Httpauth WG Revision 02
o Major change: introduction of password-strengtheing function o Major change: introduction of password-strengtheing function
PBKDF2. PBKDF2.
o Changed Section 9 to adopt "list of requirements" style. Strict o Changed Section 9 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.2. Changes in Httpauth WG Revision 01 B.3. 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 [I-D.ietf-precis-framework]. o Adopted [I-D.ietf-precis-framework].
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.3. Changes in Httpauth Revision 00 B.4. 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.4. Changes in HttpBis Revision 00 B.5. Changes in HttpBis Revision 00
None. None.
B.5. Changes in Revision 12 B.6. Changes in Revision 12
o Added a reason "authz-failed". o Added a reason "authz-failed".
B.6. Changes in Revision 11 B.7. 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 infomative/extensive "reason" o Replaced "stale" parameter with more infomative/extensive "reason"
parameter in 401-INIT and 401-STALE. 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.7. Changes in Revision 10 B.8. 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 48, line 40 skipping to change at page 48, line 48
+------------+----------+-------------------------------------------+ +------------+----------+-------------------------------------------+
| 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.8. Changes in Revision 09 B.9. 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 49, line 20 skipping to change at page 49, line 23
| 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.9. Changes in Revision 08 B.10. Changes in Revision 08
o The English text has been revised. o The English text has been revised.
B.10. Changes in Revision 07 B.11. 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.11. Changes in Revision 06 B.12. 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.12. Changes in Revision 05 B.13. 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.13. Changes in Revision 04 B.14. 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.14. Changes in Revision 03 B.15. 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.15. Changes in Revision 02 B.16. 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.16. Changes in Revision 01 B.17. 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
Research Institute for Secure Systems Research Institute for Secure Systems
 End of changes. 46 change blocks. 
104 lines changed or deleted 112 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/