draft-ietf-httpauth-mutual-08.txt   draft-ietf-httpauth-mutual-09.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 8, 2017 ITRI, AIST Expires: February 18, 2017 ITRI, AIST
K. Maeda K. Maeda
T. Hayashi T. Hayashi
Lepidum Lepidum
Y. Ioku Y. Ioku
Individual Individual
July 7, 2016 August 17, 2016
Mutual Authentication Protocol for HTTP Mutual Authentication Protocol for HTTP
draft-ietf-httpauth-mutual-08 draft-ietf-httpauth-mutual-09
Abstract Abstract
This document specifies a mutual authentication scheme for the This document specifies a mutual authentication scheme for the
Hypertext Transfer Protocol (HTTP). This scheme provides true mutual Hypertext Transfer Protocol (HTTP). This scheme provides 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 schemes, the Mutual authentication scheme specified in authentication schemes, the Mutual authentication scheme 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 8, 2017. This Internet-Draft will expire on February 18, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Document Structure and Related Documents . . . . . . . . . 5 1.2. Document Structure and Related Documents . . . . . . . . . 6
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Messages Overview . . . . . . . . . . . . . . . . . . . . 6 2.1. Messages Overview . . . . . . . . . . . . . . . . . . . . 7
2.2. Typical Flows of the Protocol . . . . . . . . . . . . . . 6 2.2. Typical Flows of the Protocol . . . . . . . . . . . . . . 8
2.3. Alternative Flows . . . . . . . . . . . . . . . . . . . . 9 2.3. Alternative Flows . . . . . . . . . . . . . . . . . . . . 10
3. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Non-ASCII extended header parameters . . . . . . . . . . . 11 3.1. Non-ASCII extended header parameters . . . . . . . . . . . 12
3.2. Values . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Values . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2. Strings . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.2. Strings . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.3. Numbers . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.3. Numbers . . . . . . . . . . . . . . . . . . . . . . . 14
4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. 401-INIT and 401-STALE . . . . . . . . . . . . . . . . . . 15 4.1. 401-INIT and 401-STALE . . . . . . . . . . . . . . . . . . 16
4.2. req-KEX-C1 . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. req-KEX-C1 . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3. 401-KEX-S1 . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. 401-KEX-S1 . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4. req-VFY-C . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4. req-VFY-C . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5. 200-VFY-S . . . . . . . . . . . . . . . . . . . . . . . . 19 4.5. 200-VFY-S . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Authentication Realms . . . . . . . . . . . . . . . . . . . . 19 5. Authentication Realms . . . . . . . . . . . . . . . . . . . . 21
5.1. Resolving Ambiguities . . . . . . . . . . . . . . . . . . 21 5.1. Resolving Ambiguities . . . . . . . . . . . . . . . . . . 22
6. Session Management . . . . . . . . . . . . . . . . . . . . . . 22 6. Session Management . . . . . . . . . . . . . . . . . . . . . . 23
7. Host Validation Methods . . . . . . . . . . . . . . . . . . . 23 7. Host Validation Methods . . . . . . . . . . . . . . . . . . . 25
7.1. Applicability notes . . . . . . . . . . . . . . . . . . . 25 7.1. Applicability notes . . . . . . . . . . . . . . . . . . . 26
7.2. Notes on tls-unique . . . . . . . . . . . . . . . . . . . 25 7.2. Notes on tls-unique . . . . . . . . . . . . . . . . . . . 27
8. Authentication Extensions . . . . . . . . . . . . . . . . . . 26 8. Authentication Extensions . . . . . . . . . . . . . . . . . . 27
9. String Preparation . . . . . . . . . . . . . . . . . . . . . . 26 9. String Preparation . . . . . . . . . . . . . . . . . . . . . . 28
10. Decision Procedure for Clients . . . . . . . . . . . . . . . . 27 10. Decision Procedure for Clients . . . . . . . . . . . . . . . . 28
10.1. General Principles and Requirements . . . . . . . . . . . 27 10.1. General Principles and Requirements . . . . . . . . . . . 28
10.2. State machine for the client (informative) . . . . . . . . 29 10.2. State machine for the client (informative) . . . . . . . . 30
11. Decision Procedure for Servers . . . . . . . . . . . . . . . . 33 11. Decision Procedure for Servers . . . . . . . . . . . . . . . . 35
12. Authentication Algorithms . . . . . . . . . . . . . . . . . . 35 12. Authentication Algorithms . . . . . . . . . . . . . . . . . . 37
12.1. Support Functions and Notations . . . . . . . . . . . . . 36 12.1. Support Functions and Notations . . . . . . . . . . . . . 38
12.2. Default Functions for Algorithms . . . . . . . . . . . . . 37 12.2. Default Functions for Algorithms . . . . . . . . . . . . . 39
13. Application Channel Binding . . . . . . . . . . . . . . . . . 38 13. Application Channel Binding . . . . . . . . . . . . . . . . . 40
14. Application for Proxy Authentication . . . . . . . . . . . . . 39 14. Application for Proxy Authentication . . . . . . . . . . . . . 41
15. Methods to Extend This Protocol . . . . . . . . . . . . . . . 40 15. Methods to Extend This Protocol . . . . . . . . . . . . . . . 42
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
16.1. Registry for Authentication Algorithms . . . . . . . . . . 40 16.1. Registry for Authentication Algorithms . . . . . . . . . . 42
16.2. Registry for Validation Methods . . . . . . . . . . . . . 41 16.2. Registry for Validation Methods . . . . . . . . . . . . . 43
17. Security Considerations . . . . . . . . . . . . . . . . . . . 41 17. Security Considerations . . . . . . . . . . . . . . . . . . . 43
17.1. Security Properties . . . . . . . . . . . . . . . . . . . 41 17.1. Security Properties . . . . . . . . . . . . . . . . . . . 43
17.2. Denial-of-service Attacks to Servers . . . . . . . . . . . 42 17.2. Denial-of-service Attacks to Servers . . . . . . . . . . . 44
17.2.1. On-line Active Password Attacks . . . . . . . . . . . 43 17.2.1. On-line Active Password Attacks . . . . . . . . . . . 45
17.3. Communicating the status of mutual authentication with 17.3. Communicating the status of mutual authentication with
users . . . . . . . . . . . . . . . . . . . . . . . . . . 43 users . . . . . . . . . . . . . . . . . . . . . . . . . . 45
17.4. Implementation Considerations . . . . . . . . . . . . . . 43 17.4. Implementation Considerations . . . . . . . . . . . . . . 45
17.5. Usage Considerations . . . . . . . . . . . . . . . . . . . 44 17.5. Usage Considerations . . . . . . . . . . . . . . . . . . . 46
18. Notice on Intellectual Properties . . . . . . . . . . . . . . 44 18. Notice on Intellectual Properties . . . . . . . . . . . . . . 46
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
19.1. Normative References . . . . . . . . . . . . . . . . . . . 45 19.1. Normative References . . . . . . . . . . . . . . . . . . . 47
19.2. Informative References . . . . . . . . . . . . . . . . . . 46 19.2. Informative References . . . . . . . . . . . . . . . . . . 48
Appendix A. (Informative) Draft Change Log . . . . . . . . . . . 47 Appendix A. (Informative) Draft Change Log . . . . . . . . . . . 50
A.1. Changes in Httpauth WG Revision 08 . . . . . . . . . . . . 48 A.1. Changes in Httpauth WG Revision 09 . . . . . . . . . . . . 50
A.2. Changes in Httpauth WG Revision 07 . . . . . . . . . . . . 48 A.2. Changes in Httpauth WG Revision 08 . . . . . . . . . . . . 50
A.3. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 48 A.3. Changes in Httpauth WG Revision 07 . . . . . . . . . . . . 50
A.4. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 48 A.4. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 50
A.5. Changes in Httpauth WG Revision 04 . . . . . . . . . . . . 48 A.5. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 50
A.6. Changes in Httpauth WG Revision 03 . . . . . . . . . . . . 48 A.6. Changes in Httpauth WG Revision 04 . . . . . . . . . . . . 51
A.7. Changes in Httpauth WG Revision 02 . . . . . . . . . . . . 49 A.7. Changes in Httpauth WG Revision 03 . . . . . . . . . . . . 51
A.8. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 49 A.8. Changes in Httpauth WG Revision 02 . . . . . . . . . . . . 51
A.9. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 49 A.9. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 51
A.10. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 49 A.10. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 52
A.11. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 49 A.11. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 52
A.12. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 50 A.12. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 52
A.13. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 50 A.13. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 52
A.14. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 51 A.14. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 52
A.15. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 51 A.15. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 53
A.16. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 51 A.16. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 54
A.17. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 52 A.17. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 54
A.18. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 52 A.18. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 54
A.19. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 52 A.19. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 54
A.20. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 52 A.20. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 55
A.21. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 53 A.21. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 55
A.22. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 53 A.22. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 A.23. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
This document specifies a mutual authentication scheme for Hypertext This document specifies a mutual authentication scheme for Hypertext
Transfer Protocol (HTTP). The scheme, called "Mutual Authentication Transfer Protocol (HTTP). The scheme, called "Mutual Authentication
Protocol" in this document, provides true mutual authentication Protocol" in this document, provides 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.
The authentication scheme proposed in this document is a general Password-stealing attacks are a one of most critical threats in the
framework for using password-based authenticated key exchange (PAKE) Web systems. For a long time, plain-text password authentications
and similar stronger cryptographic primitives with HTTP. It has the (Basic and Web form-based) are widely used (and is in use now). When
following main characteristics: it is used with plain HTTP protocols, it is trivially easy for
attackers to sniff the password credentials. Digest authentication
scheme [RFC7616] uses a SHA-2 (formally SHA-1 and MD5) hash
algorithms to hide the raw user password from the sniffing. However,
if the number of possible candidates of users' password is not
enough, Digest scheme suffers from so-called "offline password
dictionary attacks": recent powerful computers can compute possible
hash values for billions of password candidates, and compare these
with the sniffed values to find out the correct password. Recently,
the size of possible search space by computers is quite competing
with possibility of user's memorable password space, threatening the
effectiveness of such hash-based password protections.
o It provides "true" mutual authentication: in addition to assuring TLS [RFC5246] provides a strong cryptographic protection against the
the server that the user knows the password, it also assures the network-based sniffing of passwords and other communication contents.
user that the server truly knows the user's encrypted password at If TLS is correctly used by both server operators and client users,
the same time. This makes it impossible for fake website owners passwords and other credentials will not be available for any outside
to persuade users that they have authenticated with the original attackers. However, there is a pit-hole in the TLS deployment on the
websites. Web systems. If the users are forged into a "wrong website" by some
kind of social attacks and performing authentication on that site,
the credentials will be leaked. Such attacks are called "Phishing",
and becoming a real threats in these days. In the Web system
deployment, TLS certificates will be issued to almost any users of
Internet (including malicious attackers). Those certificate includes
several levels of the "validation results" (such as corporate names)
of the issued entities. However, "verification" of validation
results are left to the users of Web browsers, leaving the
possibility of such social attacks.
o It uses only passwords as the user's credential: unlike public- Another direction to avoid such threats is to avoid password-based
key-based security algorithms, the scheme does not rely on secret authentication and use some kind of pre-deployed strong secret keys
keys or other cryptographic data that have to be stored inside the (either on client side or on server-side) for authentications.
users' computers. The proposed scheme can be used as a drop-in Several federated authentication framework as well as HOBA [RFC7486]
replacement to the current authentication schemes like Basic or are proposed and deployed on the real Web systems to satisfy those
Digest, while ensuring a much stronger level of security. needs. However, a kind of authentication based on "human-memorable
secret" is still required on several situations within those systems,
such is initialization, key deployment to new clients, or secret
account recoveries.
o It is secure: when the server fails to authenticate with a user, The Mutual authentication protocol proposed in this document is a
the protocol will not reveal the tiniest bit of information about strong cryptographic solution for password authentications. It
the user's password. mainly provides the two key features:
o No password information, at all, is exchanged in the
communications. When the server and the user fails to
authenticate with each other, the protocol will not reveal the
tiniest bit of information about the user's password. This
prevents any kind of off-line password dictionary attacks, even
with the existence of Phishing attacks.
o To successfully authenticate, the server must own the valid
registered credentials (authentication secret), as well as client
users. (Non-intuitively, this is not true for Basic and Digest
authentication. For example, servers for Basic authentications
can answer "YES" to any clients, without actually checking
authentication at all.) This means that phishing attackers cannot
forge users that they are the "authentic" servers. Client users
can assert whether the communicating peer is "the server" who have
registered their account beforehand. In other words, it provides
"true" mutual authentication between servers and clients.
Given these, the proposed protocol can serve as a strong alternative
to the Basic, Digest, and web-form-based authentications, and also as
a strong companion to the non-password-based authentication framework
systems.
The Mutual authentication protocol proposed in this document is a
strong cryptographic solution for password authentications. It
mainly provides the two key features:
Technically, the authentication scheme proposed in this document is a
general framework for using password-based authenticated key exchange
(PAKE) and similar stronger cryptographic primitives with HTTP. The
two key features shown above are corresponding to the nature of PAKE.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
This document distinguishes the terms "client" and "user" in the This document distinguishes the terms "client" and "user" in the
following way: A "client" is an entity understanding and talking HTTP following way: A "client" is an entity understanding and talking HTTP
skipping to change at page 6, line 26 skipping to change at page 7, line 31
authentication failure. authentication failure.
* 401-STALE message: a message indicating that client has to * 401-STALE message: a message indicating that client has to
start a new key exchange. start a new key exchange.
o Authenticated key exchange messages: used by both peers to perform o Authenticated key exchange messages: used by both peers to perform
authentication and the sharing of a cryptographic secret. authentication and the sharing of a cryptographic secret.
* req-KEX-C1 message: a message sent from the client. * req-KEX-C1 message: a message sent from the client.
* 401-KEX-S1 message: a message sent from the server in response * 401-KEX-S1 message: an intermediate response to a req-KEX-C1
to a req-KEX-C1 message. message from the server.
o Authentication verification messages: used by both peers to verify o Authentication verification messages: used by both peers to verify
the authentication results. the authentication results.
* req-VFY-C message: a message used by the client, requesting the * req-VFY-C message: a message used by the client, requesting the
server authenticate and authorize the client. server authenticate and authorize the client.
* 200-VFY-S message: a client-authentication successful response * 200-VFY-S message: a response used by the server to indicate
used by the server, which also simultaneously asserts to the the successful client-authentication. It also contains
client that the server is authentic. information necessary for the client to check the authenticity
of the server.
In addition to the above, either a request or a response without any In addition to the above, either a request or a response without any
HTTP headers related to this specification will be hereafter called a HTTP headers related to this specification will be hereafter called a
"normal request" or a "normal response", respectively. "normal request" or a "normal response", respectively.
2.2. Typical Flows of the Protocol 2.2. Typical Flows of the Protocol
In typical cases, the client access to a resource protected by the In typical cases, the client access to a resource protected by the
Mutual authentication scheme will use the following protocol Mutual authentication scheme will use the following protocol
sequence. sequence.
skipping to change at page 8, line 17 skipping to change at page 9, line 23
Then the server creates a new session identifier (sid) that will Then the server creates a new session identifier (sid) that will
be used to identify sets of the messages that follow it and be used to identify sets of the messages that follow it and
responds back with a message containing a server-side responds back with a message containing a server-side
authenticated key exchange value (401-KEX-S1) (4). authenticated key exchange value (401-KEX-S1) (4).
o At this point (5), both peers calculate a shared "session secret" o At this point (5), both peers calculate a shared "session secret"
using the exchanged values in the key exchange messages. Only using the exchanged values in the key exchange messages. Only
when both the server and the client have used secret credentials when both the server and the client have used secret credentials
generated from the same password will the session secret values generated from the same password will the session secret values
match. This session secret will be used for access authentication match. This session secret will be used for access authentication
of every individual normal after this point. of every individual request/response pair after this point.
o The client will send a request with a client-side authentication o The client will send a request with a client-side authentication
verification value (req-VFY-C) (6), calculated from the client- verification value (req-VFY-C) (6), calculated from the client-
generated session secret. The server will check the validity of generated session secret. The server will check the validity of
the verification value using its own version of the session the verification value using its own version of the session
secret. secret.
o If the authentication verification value from the client was o If the authentication verification value from the client was
correct, it means that the client definitely owns the credential correct, it means that the client definitely owns the credential
based on the expected password (i.e., the client authentication based on the expected password (i.e., the client authentication
skipping to change at page 17, line 13 skipping to change at page 18, line 13
still failed. The use of this parameter is still failed. The use of this parameter is
NOT RECOMMENDED for security reasons. NOT RECOMMENDED for security reasons.
* authz-failed: authentication was successful, but * authz-failed: authentication was successful, but
access to the specified resource is not authorized access to the specified resource is not authorized
to the specific authenticated user. (It might be to the specific authenticated user. (It might be
used along with either a 401 or 403 status to used along with either a 401 or 403 status to
indicate that the authentication result is one of indicate that the authentication result is one of
the existing reasons for the failed authorization.) the existing reasons for the failed authorization.)
It is &RECOMMENDED to record the reasons to a kind of
diagnostic log, for an example, or shown to the client
user immediately. It will be helpful to find out
later that the reason of the failed authentication is
either technical reasons of user errors.
The algorithm specified in this header will determine the types The algorithm specified in this header will determine the types
(among those defined in Section 3) and the values for K_c1, K_s1, (among those defined in Section 3) and the values for K_c1, K_s1,
VK_c and VK_s. VK_c and VK_s.
Among these messages, those with the reason parameter of value Among these messages, those with the reason parameter of value
"stale-session" will be called "401-STALE" messages hereafter, "stale-session" will be called "401-STALE" messages hereafter,
because these have a special meaning in the protocol flow. Messages because these have a special meaning in the protocol flow. Messages
with any other reason parameters will be called "401-INIT" messages. with any other reason parameters will be called "401-INIT" messages.
4.2. req-KEX-C1 4.2. req-KEX-C1
skipping to change at page 24, line 23 skipping to change at page 25, line 31
itself to another server as a valid user by forwarding the received itself to another server as a valid user by forwarding the received
credentials. credentials.
The valid tokens for the validation parameter and corresponding The valid tokens for the validation parameter and corresponding
values of vh are as follows: values of vh are as follows:
host: host-name validation: The value vh will be the ASCII host: host-name validation: The value vh will be the ASCII
string in the following format: string in the following format:
"<scheme>://<host>:<port>", where <scheme>, <host>, "<scheme>://<host>:<port>", where <scheme>, <host>,
and <port> are the URI components corresponding to the and <port> are the URI components corresponding to the
currently accessing resource. The scheme and host are currently accessing server-side resource. The scheme
in lower case, and the port is in a shortest decimal and host are in lower case, and the port is in a
representation. Even if the request-URI does not have shortest decimal representation. Even if the request-
a port part, v will include the default port number. URI does not have a port part, v will include the
default port number.
tls-server-end-point: TLS endpoint (certificate) validation: The tls-server-end-point: TLS endpoint (certificate) validation: The
value vh will be the octet string of the hash value of value vh will be the octet string of the hash value of
the server's public key certificate used in the the server's public key certificate used in the
underlying TLS [RFC5246] connection, processed as underlying TLS [RFC5246] connection, processed as
specified in Section 4.1 of [RFC5929]. specified in Section 4.1 of [RFC5929].
tls-unique: TLS shared-key validation: The value vh will be the tls-unique: TLS shared-key validation: The value vh will be the
channel binding material derived from the Finished channel binding material derived from the Finished
messages, as defined in Section 3.1 of [RFC5929]. messages, as defined in Section 3.1 of [RFC5929].
skipping to change at page 26, line 37 skipping to change at page 27, line 49
Authentication-Control header defined in Authentication-Control header defined in
[I-D.ietf-httpauth-extension], except for the "auth-style" parameter. [I-D.ietf-httpauth-extension], except for the "auth-style" parameter.
This specification also proposes (however, does not mandate) the This specification also proposes (however, does not mandate) the
default "auth-style" be "non-modal". Web applications SHOULD however default "auth-style" 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
support these headers. support these headers.
Authentication-initializing messages with the Authentication-initializing messages with the
Optional-WWW-Authenticate header are used only where the 401-INIT Optional-WWW-Authenticate header are used only where the 401-INIT
response is valid. It will not replace other 401-type messages such response is valid. It will not replace other 401-type messages such
as 401-STALE and 401-KEX-S1. as 401-STALE and 401-KEX-S1. That is, the reason field of such a
message &MUST be "initial" (or any extensive-tokens NOT defined in
Section 4.1).
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 are binary-comparable regardless of the user's used in this protocol are 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
skipping to change at page 27, line 32 skipping to change at page 28, line 43
implementations MAY omit preparation and Unicode normalization implementations MAY omit preparation and Unicode normalization
(performing UTF-8 encoding only) before using it. When a string is (performing UTF-8 encoding only) before using it. When a string is
already stored as an octet blob, implementations MAY send it as is. already stored as an octet blob, implementations MAY send it as is.
10. Decision Procedure for Clients 10. Decision Procedure for Clients
10.1. General Principles and Requirements 10.1. General Principles and Requirements
To securely implement the protocol, the client must be careful about To securely implement the protocol, the client must be careful about
accepting the authenticated responses from the server. This also accepting the authenticated responses from the server. This also
holds true for the reception of "normal responses" (responses which holds true for the reception of a "normal response" (a response which
do not contain Mutual authentication-related headers) from HTTP does not contain Mutual authentication-related headers) from HTTP
servers. servers.
As usual in the HTTP authentication, a single user-level request may As usual in the HTTP authentication, a single user-level request may
result in exchange of two-or-more HTTP requests and responses in result in exchange of two-or-more HTTP requests and responses in
sequence. The following normative rules MUST be followed by the sequence. The following normative rules MUST be followed by the
clients implementing this protocol: clients implementing this protocol:
o Any kinds of "normal responses" MUST only be accepted for the very o Any kind of a "normal response" MUST only be accepted for the very
first request in the sequence. Any "normal responses" returned first request in the sequence. Any "normal response" returned for
for the second or later requests in the sequence SHALL be the second or later requests in the sequence SHALL be considered
considered invalid. invalid.
o In the same principle, any responses which refer to or request o In the same principle, if any response is related to an
changing to an authentication realm different from the client's authentication realm which is different from that of the client's
request MUST only be accepted for the very first request in the request (for example, a 401-INIT message requesting authentication
sequence. Any kind of responses referring to different realms on another realm), it MUST only be accepted for the very first
which are returned for the second or later requests in the request in the sequence. Such a response returned for a second or
sequence SHALL be considered invalid. later request in the sequence SHALL be considered invalid.
o A req-KEX-C1 message MAY be sent either as a initial request or as o A req-KEX-C1 message MAY be sent either as a initial request or as
a response to 401-INIT or 401-STALE. However, it SHOULD NOT be a response to 401-INIT or 401-STALE. However, it SHOULD NOT be
sent more than once in the sequence for a single authentication sent more than once in the sequence for a single authentication
realm, to avoid infinite loops of messages. A 401-KEX-S1 response realm, to avoid infinite loops of messages. A 401-KEX-S1 response
MUST be accepted only when the corresponding request is MUST be accepted only when the corresponding request is
req-KEX-C1. req-KEX-C1.
o A req-VFY-C message MAY be sent if there is a valid session key o A req-VFY-C message MAY be sent if there is a valid session key
shared between the client and the server, established by shared between the client and the server, established by
skipping to change at page 44, line 20 skipping to change at page 46, line 20
RECOMMENDED to be re-validated using a req-KEX-C1 message with an RECOMMENDED to be re-validated using a req-KEX-C1 message with an
"Expect: 100-continue" header. The same applies when the page is "Expect: 100-continue" header. The same applies when the page is
received with the "tls-unique" validation method, and when the TLS received with the "tls-unique" validation method, and when the TLS
session has expired. session has expired.
o For better protection against possible password database stealing, o For better protection against possible password database stealing,
server-side storage of user passwords should contain the values server-side storage of user passwords should contain the values
encrypted by the one-way function J(pi), instead of the real encrypted by the one-way function J(pi), instead of the real
passwords or those hashed by pi. passwords or those hashed by pi.
o If the TLS 1.2 is used for underlying HTTP/TLS communications,
follow best practices in [RFC7525].
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-scope. This means that when a host- servers sharing the same auth-scope. This means that when a host-
type auth-scope 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 clear text. If user names have to be kept secret user name in clear text. If user names have to be kept secret
against eavesdropping, the server must use the full-scheme-type against eavesdropping, the server must use the full-scheme-type
auth-scope parameter and HTTPS. Contrarily, passwords are not auth-scope parameter and HTTPS. Contrarily, passwords are not
skipping to change at page 45, line 10 skipping to change at page 47, line 13
The elliptic-curve based authentication algorithms might involve The elliptic-curve based authentication algorithms might involve
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., Maeda, K., Hayashi,
Ioku, "HTTP Authentication Extensions for Interactive T., and Y. Ioku, "HTTP Authentication Extensions for
Clients", draft-ietf-httpauth-extension-07 (work in Interactive Clients", draft-ietf-httpauth-extension-08
progress), July 2016. (work in progress), August 2016.
[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,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>. <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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 46, line 32 skipping to change at page 48, line 37
Authentication-Info Response Header Fields", RFC 7615, Authentication-Info Response Header Fields", RFC 7615,
DOI 10.17487/RFC7615, September 2015, DOI 10.17487/RFC7615, September 2015,
<http://www.rfc-editor.org/info/rfc7615>. <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-05 (work in progress), draft-ietf-httpauth-mutual-algo-06 (work in progress),
January 2016. August 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
skipping to change at page 47, line 29 skipping to change at page 49, line 35
<http://www.rfc-editor.org/info/rfc5929>. <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,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<http://www.rfc-editor.org/info/rfc6265>. <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,
DOI 10.17487/RFC6454, December 2011, DOI 10.17487/RFC6454, December 2011,
<http://www.rfc-editor.org/info/rfc6454>. <http://www.rfc-editor.org/info/rfc6454>.
[RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin-
Bound Authentication (HOBA)", RFC 7486, DOI 10.17487/
RFC7486, March 2015,
<http://www.rfc-editor.org/info/rfc7486>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525,
May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[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, DOI 10.17487/RFC7564, May 2015, RFC 7564, DOI 10.17487/RFC7564, May 2015,
<http://www.rfc-editor.org/info/rfc7564>. <http://www.rfc-editor.org/info/rfc7564>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616, DOI 10.17487/ Digest Access Authentication", RFC 7616, DOI 10.17487/
RFC7616, September 2015, RFC7616, September 2015,
<http://www.rfc-editor.org/info/rfc7616>. <http://www.rfc-editor.org/info/rfc7616>.
skipping to change at page 48, line 5 skipping to change at page 50, line 18
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS) Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension", Session Hash and Extended Master Secret Extension",
RFC 7627, DOI 10.17487/RFC7627, September 2015, RFC 7627, DOI 10.17487/RFC7627, September 2015,
<http://www.rfc-editor.org/info/rfc7627>. <http://www.rfc-editor.org/info/rfc7627>.
Appendix A. (Informative) Draft Change Log Appendix A. (Informative) Draft Change Log
[To be removed on final publication] [To be removed on final publication]
A.1. Changes in Httpauth WG Revision 08 A.1. Changes in Httpauth WG Revision 09
o Reflected AD review comments.
o Authors' addresses updated.
A.2. Changes in Httpauth WG Revision 08
o Minor text update, in sync with httpauth-extension. o Minor text update, in sync with httpauth-extension.
o The version token is raised to "1". o The version token is raised to "1".
A.2. Changes in Httpauth WG Revision 07 A.3. Changes in Httpauth WG Revision 07
o Several comments from reviewers are reflected to the text. o Several comments from reviewers are reflected to the text.
o The password-hash has been completely dropped. o The password-hash has been completely dropped.
o The version token is raised to "1". o The version token is raised to "1".
A.3. Changes in Httpauth WG Revision 06 A.4. Changes in Httpauth WG Revision 06
o The auth-domain parameter has been renamed to auth-scope, o The auth-domain parameter has been renamed to auth-scope,
following suggestions on the mailing list. following suggestions on the mailing list.
o The digest-md5 password-hash has been dropped, as Digest with MD5 o The digest-md5 password-hash has been dropped, as Digest with MD5
hash is now obsoleted. hash is now obsoleted.
A.4. Changes in Httpauth WG Revision 05 A.5. 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.
A.5. Changes in Httpauth WG Revision 04 A.6. 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.
A.6. Changes in Httpauth WG Revision 03 A.7. 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.)
A.7. Changes in Httpauth WG Revision 02 A.8. 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.
A.8. Changes in Httpauth WG Revision 01 A.9. 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.
A.9. Changes in Httpauth Revision 00 A.10. 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)
A.10. Changes in HttpBis Revision 00 A.11. Changes in HttpBis Revision 00
None. None.
A.11. Changes in Revision 12 A.12. Changes in Revision 12
o Added a reason "authz-failed". o Added a reason "authz-failed".
A.12. Changes in Revision 11 A.13. 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.
A.13. Changes in Revision 10 A.14. 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 51, line 17 skipping to change at page 53, line 32
+------------+----------+-------------------------------------------+ +------------+----------+-------------------------------------------+
| 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 |
+------------+----------+-------------------------------------------+ +------------+----------+-------------------------------------------+
A.14. Changes in Revision 09 A.15. 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 51, line 40 skipping to change at page 54, line 8
| 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 |
+-------------------+-----------------+-----------------------------+ +-------------------+-----------------+-----------------------------+
A.15. Changes in Revision 08 A.16. Changes in Revision 08
o The English text has been revised. o The English text has been revised.
A.16. Changes in Revision 07 A.17. 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.
A.17. Changes in Revision 06 A.18. 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.
A.18. Changes in Revision 05 A.19. 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.
A.19. Changes in Revision 04 A.20. 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.
A.20. Changes in Revision 03 A.21. 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.
A.21. Changes in Revision 02 A.22. 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.
A.22. Changes in Revision 01 A.23. 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 1 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: y.oiwa@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 1 Tsukuba Central 1
1-1-1 Umezono 1-1-1 Umezono
Tsukuba-shi, Ibaraki Tsukuba-shi, Ibaraki
JP JP
Email: h-watanabe@aist.go.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 1 Tsukuba Central 1
1-1-1 Umezono 1-1-1 Umezono
Tsukuba-shi, Ibaraki Tsukuba-shi, Ibaraki
JP JP
Email: takagi.hiromitsu@aist.go.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
Email: maeda@lepidum.co.jp
Tatsuya Hayashi Tatsuya Hayashi
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
Email: hayashi@lepidum.co.jp
Yuichi Ioku Yuichi Ioku
Individual Individual
Email: mutual-work@ioku.org
 End of changes. 51 change blocks. 
149 lines changed or deleted 243 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/