draft-ietf-httpauth-mutual-10.txt   draft-ietf-httpauth-mutual-11.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: March 26, 2017 ITRI, AIST Expires: May 18, 2017 ITRI, AIST
K. Maeda K. Maeda
T. Hayashi T. Hayashi
Lepidum Lepidum
Y. Ioku Y. Ioku
Individual Individual
September 22, 2016 November 14, 2016
Mutual Authentication Protocol for HTTP Mutual Authentication Protocol for HTTP
draft-ietf-httpauth-mutual-10 draft-ietf-httpauth-mutual-11
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 March 26, 2017. This Internet-Draft will expire on May 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 . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Document Structure and Related Documents . . . . . . . . . 6 1.2. Document Structure and Related Documents . . . . . . . . . 6
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Messages Overview . . . . . . . . . . . . . . . . . . . . 7 2.1. Messages Overview . . . . . . . . . . . . . . . . . . . . 7
2.2. Typical Flows of the Protocol . . . . . . . . . . . . . . 8 2.2. Typical Flows of the Protocol . . . . . . . . . . . . . . 8
2.3. Alternative Flows . . . . . . . . . . . . . . . . . . . . 10 2.3. Alternative Flows . . . . . . . . . . . . . . . . . . . . 10
3. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Non-ASCII extended header parameters . . . . . . . . . . . 12 3.1. Non-ASCII extended header parameters . . . . . . . . . . . 12
3.2. Values . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Values . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2. Strings . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.2. Strings . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.3. Numbers . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.3. Numbers . . . . . . . . . . . . . . . . . . . . . . . 14
4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 3, line 8 skipping to change at page 3, line 8
11. Decision Procedure for Servers . . . . . . . . . . . . . . . . 35 11. Decision Procedure for Servers . . . . . . . . . . . . . . . . 35
12. Authentication Algorithms . . . . . . . . . . . . . . . . . . 37 12. Authentication Algorithms . . . . . . . . . . . . . . . . . . 37
12.1. Support Functions and Notations . . . . . . . . . . . . . 38 12.1. Support Functions and Notations . . . . . . . . . . . . . 38
12.2. Default Functions for Algorithms . . . . . . . . . . . . . 39 12.2. Default Functions for Algorithms . . . . . . . . . . . . . 39
13. Application Channel Binding . . . . . . . . . . . . . . . . . 40 13. Application Channel Binding . . . . . . . . . . . . . . . . . 40
14. Application for Proxy Authentication . . . . . . . . . . . . . 41 14. Application for Proxy Authentication . . . . . . . . . . . . . 41
15. Methods to Extend This Protocol . . . . . . . . . . . . . . . 42 15. Methods to Extend This Protocol . . . . . . . . . . . . . . . 42
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
16.1. Registry for Authentication Algorithms . . . . . . . . . . 42 16.1. Registry for Authentication Algorithms . . . . . . . . . . 42
16.2. Registry for Validation Methods . . . . . . . . . . . . . 43 16.2. Registry for Validation Methods . . . . . . . . . . . . . 43
17. Security Considerations . . . . . . . . . . . . . . . . . . . 43 17. Security Considerations . . . . . . . . . . . . . . . . . . . 44
17.1. Security Properties . . . . . . . . . . . . . . . . . . . 43 17.1. Security Properties . . . . . . . . . . . . . . . . . . . 44
17.2. Denial-of-service Attacks to Servers . . . . . . . . . . . 44 17.2. Secrecy of Credentials . . . . . . . . . . . . . . . . . . 44
17.2.1. On-line Active Password Attacks . . . . . . . . . . . 45 17.3. Denial-of-service Attacks to Servers . . . . . . . . . . . 45
17.3. Communicating the status of mutual authentication with 17.3.1. On-line Active Password Attacks . . . . . . . . . . . 45
17.4. Communicating the status of mutual authentication with
users . . . . . . . . . . . . . . . . . . . . . . . . . . 45 users . . . . . . . . . . . . . . . . . . . . . . . . . . 45
17.4. Implementation Considerations . . . . . . . . . . . . . . 45 17.5. Implementation Considerations . . . . . . . . . . . . . . 46
17.5. Usage Considerations . . . . . . . . . . . . . . . . . . . 46 17.6. Usage Considerations . . . . . . . . . . . . . . . . . . . 47
18. Notice on Intellectual Properties . . . . . . . . . . . . . . 46 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 18.1. Normative References . . . . . . . . . . . . . . . . . . . 47
19.1. Normative References . . . . . . . . . . . . . . . . . . . 47 18.2. Informative References . . . . . . . . . . . . . . . . . . 48
19.2. Informative References . . . . . . . . . . . . . . . . . . 48
Appendix A. (Informative) Draft Change Log . . . . . . . . . . . 50 Appendix A. (Informative) Draft Change Log . . . . . . . . . . . 50
A.1. Changes in Httpauth WG Revision 10 . . . . . . . . . . . . 50 A.1. Changes in Httpauth WG Revision 11 . . . . . . . . . . . . 50
A.2. Changes in Httpauth WG Revision 09 . . . . . . . . . . . . 50 A.2. Changes in Httpauth WG Revision 10 . . . . . . . . . . . . 50
A.3. Changes in Httpauth WG Revision 08 . . . . . . . . . . . . 50 A.3. Changes in Httpauth WG Revision 09 . . . . . . . . . . . . 50
A.4. Changes in Httpauth WG Revision 07 . . . . . . . . . . . . 50 A.4. Changes in Httpauth WG Revision 08 . . . . . . . . . . . . 50
A.5. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 50 A.5. Changes in Httpauth WG Revision 07 . . . . . . . . . . . . 51
A.6. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 51 A.6. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 51
A.7. Changes in Httpauth WG Revision 04 . . . . . . . . . . . . 51 A.7. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 51
A.8. Changes in Httpauth WG Revision 03 . . . . . . . . . . . . 51 A.8. Changes in Httpauth WG Revision 04 . . . . . . . . . . . . 51
A.9. Changes in Httpauth WG Revision 02 . . . . . . . . . . . . 51 A.9. Changes in Httpauth WG Revision 03 . . . . . . . . . . . . 51
A.10. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 51 A.10. Changes in Httpauth WG Revision 02 . . . . . . . . . . . . 51
A.11. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 52 A.11. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 52
A.12. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 52 A.12. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 52
A.13. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 52 A.13. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 52
A.14. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 52 A.14. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 52
A.15. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 52 A.15. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 52
A.16. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 53 A.16. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 53
A.17. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 54 A.17. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 54
A.18. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 54 A.18. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 54
A.19. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 54 A.19. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 54
A.20. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 55 A.20. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 55
A.21. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 55 A.21. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 55
A.22. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 55 A.22. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 55
A.23. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 55 A.23. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 55
A.24. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 56 A.24. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 56
A.25. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 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.
Password-stealing attacks are a one of most critical threats in the Password-stealing attacks are one of most critical threats for Web
Web systems. For a long time, plain-text password authentications systems. For a long time, plain-text password authentications (Basic
(Basic and Web form-based) are widely used (and is in use now). When and Web form-based) are widely used (and are in use now). When these
it is used with plain HTTP protocols, it is trivially easy for are used with plain HTTP protocols, it is trivially easy for
attackers to sniff the password credentials. Digest authentication attackers to sniff the password credentials on the wire.
scheme [RFC7616] uses a SHA-2 (formally SHA-1 and MD5) hash
algorithms to hide the raw user password from the sniffing. However, Digest authentication scheme [RFC7616] uses a SHA-2 (formerly SHA-1
if the number of possible candidates of users' password is not and MD5) hash algorithms to hide the raw user password from the
enough, Digest scheme suffers from so-called "offline password sniffing. However, if the number of possible candidates of users'
dictionary attacks": recent powerful computers can compute possible password is not enough, recent powerful computers can compute
hash values for billions of password candidates, and compare these possible hash values for billions of password candidates, and compare
with the sniffed values to find out the correct password. Recently, these with the sniffed values to find out the correct password. This
the size of possible search space by computers is quite competing kind of attack is called "offline password dictionary attacks";
with possibility of user's memorable password space, threatening the recently, the size of possible search space by computers is quite
effectiveness of such hash-based password protections. competing with possibility of user's memorable passwords, threatening
the effectiveness of such hash-based password protections.
TLS [RFC5246] provides a strong cryptographic protection against the TLS [RFC5246] provides a strong cryptographic protection against the
network-based sniffing of passwords and other communication contents. network-based sniffing of passwords and other communication contents.
If TLS is correctly used by both server operators and client users, If TLS is correctly used by both server operators and client users,
passwords and other credentials will not be available for any outside passwords and other credentials will not be available for any outside
attackers. However, there is a pit-hole in the TLS deployment on the attackers. However, there is a pit-hole in the TLS deployment on the
Web systems. If the users are forged into a "wrong website" by some Web systems; if the users are forged into a "wrong website" by some
kind of social attacks and performing authentication on that site, kind of social attacks and tridked to perform authentication on that
the credentials will be leaked. Such attacks are called "Phishing", site, the credentials will be sent to the attacker's server and
and becoming a real threats in these days. In the Web system trivially leaked. Such attacks are called "Phishing", and becoming a
deployment, TLS certificates will be issued to almost any users of real threats in these days. In the curent Web system deployment, TLS
Internet (including malicious attackers). Those certificate includes certificates will be issued to almost any users of Internet
(including malicious attackers). Although those certificate includes
several levels of the "validation results" (such as corporate names) several levels of the "validation results" (such as corporate names)
of the issued entities. However, "verification" of validation of the issued entities, task of "checking" those validation results
results are left to the users of Web browsers, leaving the are left to the users of Web browsers, still leaving the possibility
possibility of such social attacks. of such social attacks.
Another direction to avoid such threats is to avoid password-based Another direction to avoid such threats is to avoid password-based
authentication and use some kind of pre-deployed strong secret keys authentication and use some kind of pre-deployed strong secret keys
(either on client side or on server-side) for authentications. (either on client side or on server-side) for authentications.
Several federated authentication framework as well as HOBA [RFC7486] Several federated authentication framework as well as HOBA [RFC7486]
are proposed and deployed on the real Web systems to satisfy those are proposed and deployed on the real Web systems to satisfy those
needs. However, a kind of authentication based on "human-memorable needs. However, a kind of authentication based on "human-memorable
secret" is still required on several situations within those systems, secret" (i.e. passwords) is still required on several situations
such is initialization, key deployment to new clients, or secret within those systems, such is initialization, key deployment to new
account recoveries. clients, or recovery of secret accounts with lost cryptographic keys.
The Mutual authentication protocol proposed in this document is a The Mutual authentication protocol proposed in this document is a
strong cryptographic solution for password authentications. It strong cryptographic solution for password authentications. It
mainly provides the two key features: mainly provides the two key features:
o No password information, at all, is exchanged in the o No password information, at all, is exchanged in the
communications. When the server and the user fails to communications. When the server and the user fails to
authenticate with each other, the protocol will not reveal the authenticate with each other, the protocol will not reveal the
tiniest bit of information about the user's password. This tiniest bit of information about the user's password. This
prevents any kind of off-line password dictionary attacks, even prevents any kind of off-line password dictionary attacks, even
skipping to change at page 5, line 30 skipping to change at page 5, line 32
authentication. For example, servers for Basic authentications authentication. For example, servers for Basic authentications
can answer "YES" to any clients, without actually checking can answer "YES" to any clients, without actually checking
authentication at all.) This means that phishing attackers cannot authentication at all.) This means that phishing attackers cannot
forge users that they are the "authentic" servers. Client users forge users that they are the "authentic" servers. Client users
can assert whether the communicating peer is "the server" who have can assert whether the communicating peer is "the server" who have
registered their account beforehand. In other words, it provides registered their account beforehand. In other words, it provides
"true" mutual authentication between servers and clients. "true" mutual authentication between servers and clients.
Given these, the proposed protocol can serve as a strong alternative Given these, the proposed protocol can serve as a strong alternative
to the Basic, Digest, and web-form-based authentications, and also as to the Basic, Digest, and web-form-based authentications, and also as
a strong companion to the non-password-based authentication framework a strong companion to the non-password-based authentication
systems. frameworks.
The Mutual authentication protocol proposed in this document is a The proposed protocol will serve in the same way as existing Basic/
strong cryptographic solution for password authentications. It Digest authentication: it meets the requirement for new
mainly provides the two key features: authentication scheme for HTTP as described in Section 5.1.2 of
[RFC7235]. Additionally, to communiate authentication results more
reliably between the server and the client user, it suggests for Web
browsers to have some "secure" way of displaying the authentication
results. Having such an user interface in future browser will
greatly reduce the risk of impersonation by kinds of social attacks,
similarly in the manner of the "green padlock" for extended
verification TLS certificates.
Technically, the authentication scheme proposed in this document is a Technically, the authentication scheme proposed in this document is a
general framework for using password-based authenticated key exchange general framework for using password-based authenticated key exchange
(PAKE) and similar stronger cryptographic primitives with HTTP. The (PAKE) and similar stronger cryptographic primitives with HTTP. The
two key features shown above are corresponding to the nature of PAKE. 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
skipping to change at page 6, line 12 skipping to change at page 6, line 23
following way: A "client" is an entity understanding and talking HTTP following way: A "client" is an entity understanding and talking HTTP
and the specified authentication protocol, usually computer software; and the specified authentication protocol, usually computer software;
a "user" is a (usually natural) person who wants to access data a "user" is a (usually natural) person who wants to access data
resources using a "client". resources using a "client".
The term "natural numbers" refers to the non-negative integers The term "natural numbers" refers to the non-negative integers
(including zero) throughout this document. (including zero) throughout this document.
This document treats both the input (domain) and the output This document treats both the input (domain) and the output
(codomain) of hash functions to be octet strings. When a natural (codomain) of hash functions to be octet strings. When a natural
number output is required, the notation INT(H(s)) is used. number output for a hash function is required, it will be written as
INT(H(s)).
1.2. Document Structure and Related Documents 1.2. Document Structure and Related Documents
The entire document is organized as follows: The entire document is organized as follows:
o Section 2 presents an overview of the protocol design. o Section 2 presents an overview of the protocol design.
o Sections 3 to 11 define a general framework of the Mutual o Sections 3 to 11 define a general framework of the Mutual
authentication protocol. This framework is independent of authentication protocol. This framework is independent of
specific cryptographic primitives. specific cryptographic primitives.
o Section 12 describes properties needed for cryptographic o Section 12 describes properties needed for cryptographic
algorithms used with this protocol framework, and defines a few algorithms used with this protocol framework, and defines a few
functions which will be shared among such cryptographic functions which will be shared among such cryptographic
algorithms. algorithms.
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
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.ietf-httpauth-mutual-algo]: defines cryptographic primitives o [I-D.ietf-httpauth-mutual-algo]: defines cryptographic primitives
which can be used with this protocol framework. which can be used with this protocol framework.
o [I-D.ietf-httpauth-extension]: defines small but useful extensions o [I-D.ietf-httpauth-extension]: defines small but useful extensions
to the current HTTP authentication framework so that it can to the current HTTP authentication framework so that it can
support application-level semantics of existing Web systems. support application-level semantics of existing Web systems.
skipping to change at page 13, line 16 skipping to change at page 13, line 16
The parameter values contained in challenge/credentials MUST be The parameter values contained in challenge/credentials MUST be
parsed strictly conforming to the HTTP semantics (especially un- parsed strictly conforming to the HTTP semantics (especially un-
quoting of the string parameter values). In this protocol, those quoting of the string parameter values). In this protocol, those
values are further categorized into the following value types: tokens values are further categorized into the following value types: tokens
(bare-token and extensive-token), string, integer, hex-fixed-number, (bare-token and extensive-token), string, integer, hex-fixed-number,
and base64-fixed-number. and base64-fixed-number.
For clarity, implementations are RECOMMENDED to use the canonical For clarity, implementations are RECOMMENDED to use the canonical
representations specified in the following subsections for sending representations specified in the following subsections for sending
values. Recipients SHOULD accept both quoted and unquoted values. However, recipients MUST accept both quoted and unquoted
representations interchangeably as specified in HTTP. representations interchangeably as specified in HTTP.
3.2.1. Tokens 3.2.1. Tokens
For sustaining both security and extensibility at the same time, this For sustaining both security and extensibility at the same time, this
protocol defines a stricter sub-syntax for the "token" to be used. protocol defines a stricter sub-syntax for the "token" to be used.
Extensive-token values SHOULD use the following syntax (after HTTP Extensive-token values SHOULD use the following syntax (after HTTP
value parsing): value parsing):
bare-token = bare-token-lead-char *bare-token-char bare-token = bare-token-lead-char *bare-token-char
skipping to change at page 14, line 9 skipping to change at page 14, line 9
Bare-tokens and extensive-tokens are also used for parameter names, Bare-tokens and extensive-tokens are also used for parameter names,
in the unquoted form. Requirements for using the extension-token for in the unquoted form. Requirements for using the extension-token for
the parameter names are the same as the previous paragraph. the parameter names are the same as the previous paragraph.
The canonical format for bare-tokens and extensive-tokens is the The canonical format for bare-tokens and extensive-tokens is the
unquoted representation. unquoted representation.
3.2.2. Strings 3.2.2. Strings
All character strings MUST be encoded to octet strings using the All character strings MUST be encoded to octet strings using the
UTF-8 encoding [RFC3629] for the ISO 10646-1 character set UTF-8 encoding [RFC3629] for the Unicode character set [Unicode].
[ISO.10646-1.1993]. Such strings MUST NOT contain any leading BOM Such strings MUST NOT contain any leading BOM markers (also known as
characters (ZERO WIDTH NO-BREAK SPACE, U+FEFF or EF BB BF). Both ZERO WIDTH NO-BREAK SPACE, U+FEFF or EF BB BF). Both peers are
peers are RECOMMENDED to reject any invalid UTF-8 sequences that RECOMMENDED to reject any invalid UTF-8 sequences that might cause
might cause decoding ambiguities (e.g., containing <"> in the second decoding ambiguities (e.g., containing <"> in the second or later
or later bytes of the UTF-8 encoded characters). bytes of the UTF-8 encoded characters).
If strings are representing a domain name or URI that contains non- If strings are representing a domain name or URI that contains non-
ASCII characters, the host parts SHOULD be encoded as it is used in ASCII characters, the host parts SHOULD be encoded as it is used in
the HTTP protocol layer (e.g., in a Host: header); under current the HTTP protocol layer (e.g., in a Host: header); under current
standards it will be the one defined in [RFC5890]. It SHOULD use standards it will be the one defined in [RFC5890]. It SHOULD use
lower-case ASCII characters. lower-case ASCII characters.
The canonical format for strings is quoted-string (as it may contain The canonical format for strings is quoted-string (as it may contain
equal signs, plus signs and slashes), unless the parameter containing equal signs, plus signs and slashes), unless the parameter containing
the string value will use extended syntax defined in [RFC5987]. (An the string value will use extended syntax defined in [RFC5987]. (An
skipping to change at page 14, line 44 skipping to change at page 14, line 44
base64-fixed-number = 1*( ALPHA / DIGIT / "+" / "/" ) 0*2"=" base64-fixed-number = 1*( ALPHA / DIGIT / "+" / "/" ) 0*2"="
Figure 4: BNF syntax for numbers Figure 4: BNF syntax for numbers
The syntax definition of the integers only allows representations The syntax definition of the integers only allows representations
that do not contain leading zeros. that do not contain leading zeros.
A number represented as a hex-fixed-number MUST include an even A number represented as a hex-fixed-number MUST include an even
number of hexadecimal digits (i.e., multiples of eight bits). Those number of hexadecimal digits (i.e., multiples of eight bits). Those
values are case-insensitive, and SHOULD be sent in lower case. When values are case-insensitive, and SHOULD be sent in lower case. When
these values are generated from any cryptographic values, they SHOULD these values are generated from any cryptographic values, they MUST
have their "natural length"; if these are generated from a hash have their "natural length"; if these values are generated from a
function, these lengths SHOULD correspond to the hash size; if these hash function, these lengths correspond to the hash size; if these
are representing elements of a mathematical set (or group), its are representing elements of a mathematical set (or group), these
lengths SHOULD be the shortest for representing all the elements in lengths SHALL be the shortest for representing all the elements in
the set. For example, the results of the SHA-256 hash function will the set. For example, the results of the SHA-256 hash function will
be represented by 64 digits, and any elements in a 2048-bit prime be represented by 64 digits, and any elements in a 2048-bit prime
field (modulo a 2048-bit integer) will be represented by 512 digits, field (modulo a 2048-bit integer) will be represented by 512 digits,
regardless of how much zeros appear in front of such representations. regardless of how much zeros appear in front of such representations.
Session-identifiers and other non-cryptographically generated values Session-identifiers and other non-cryptographically generated values
are represented in any (even) length determined by the side that are represented in any (even) length determined by the side that
generates it first, and the same length SHALL be used throughout all generates it first, and the same length MUST be used throughout all
communications by both peers. communications by both peers.
The numbers represented as base64-fixed-number SHALL be generated as The numbers represented as base64-fixed-number SHALL be generated as
follows: first, the number is converted to a big-endian radix-256 follows: first, the number is converted to a big-endian radix-256
binary representation as an octet string. The length of the binary representation as an octet string. The length of the
representation is determined in the same way as mentioned above. representation is determined in the same way as mentioned above.
Then, the string is encoded using the Base 64 encoding [RFC4648] Then, the string is encoded using the Base 64 encoding (described in
without any spaces and newlines. Implementations decoding base64- Section 4 of [RFC4648]) without any spaces and newlines.
fixed-number SHOULD reject any input data with invalid characters, Implementations decoding base64-fixed-number SHOULD reject any input
excess/insufficient padding, or non-canonical pad bits (See Sections data with invalid characters, excess/insufficient padding, or non-
3.1 to 3.5 of [RFC4648]). canonical pad bits (See Sections 3.1 to 3.5 of [RFC4648]).
The canonical format for integer and hex-fixed-number are unquoted The canonical format for integer and hex-fixed-number are unquoted
tokens, and that for base64-fixed-number is quoted-string. tokens, and that for base64-fixed-number is quoted-string.
4. Messages 4. Messages
In this section we define the seven kinds of messages used in the In this section we define the seven kinds of messages used in the
authentication protocol along with the formats and requirements of authentication protocol along with the formats and requirements of
the headers for each message. the headers for each message.
skipping to change at page 18, 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 It is RECOMMENDED to record the reasons to a kind of
diagnostic log, for an example, or shown to the client diagnostic log, for an example, or shown to the client
user immediately. It will be helpful to find out user immediately. It will be helpful to find out
later that the reason of the failed authentication is later that the reason of the failed authentication is
either technical reasons of user errors. 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
skipping to change at page 26, line 10 skipping to change at page 26, line 10
(Note: see Section 7.2 for some security notices when (Note: see Section 7.2 for some security notices when
using this validation method.) using this validation method.)
If HTTP is used on a non-encrypted channel (TCP and SCTP, for If HTTP is used on a non-encrypted channel (TCP and SCTP, for
example), the validation type MUST be "host". If HTTP/TLS [RFC2818] example), the validation type MUST be "host". If HTTP/TLS [RFC2818]
(HTTPS) is used with a server certificate, the validation type MUST (HTTPS) is used with a server certificate, the validation type MUST
be "tls-server-end-point". If HTTP/TLS is used with an anonymous be "tls-server-end-point". If HTTP/TLS is used with an anonymous
Diffie-Hellman key exchange, the validation type MUST be "tls-unique" Diffie-Hellman key exchange, the validation type MUST be "tls-unique"
(see the note below). (see the note below).
Implementations supporting Mutual authentication over HTTPS SHOULD
support the "tls-server-end-point" validation. Support for
"tls-unique" validation is OPTIONAL for both servers and clients.
If the validation type "tls-server-end-point" is used, the server If the validation type "tls-server-end-point" is used, the server
certificate provided in the TLS connection MUST be verified at least certificate provided in the TLS connection MUST be verified at least
to make sure that the server actually owns the corresponding private to make sure that the server actually owns the corresponding private
key. (Note: this verification is automatic in some RSA-based key key. (Note: this verification is automatic in some RSA-based key
exchanges but NOT automatic in Diffie-Hellman-based key exchanges exchanges but NOT automatic in Diffie-Hellman-based key exchanges
with separate exchange for server verification.) with separate exchange for server verification.)
Clients MUST validate this parameter upon receipt of 401-INIT Clients MUST validate this parameter upon receipt of 401-INIT
messages. messages.
Note: The protocol defines two variants of validation on the TLS Note: The protocol defines two variants of validation on the TLS
connections. The "tls-unique" method is more secure. However, there connections. The "tls-unique" method is technically more secure.
are some situations where tls-server-end-point is more preferable. However, there are some situations where tls-server-end-point is more
preferable.
o When TLS accelerating proxies are used, it is difficult for the o When TLS accelerating proxies are used, it is difficult for the
authenticating server to acquire the TLS key information that is authenticating server to acquire the TLS key information that is
used between the client and the proxy. This is not the case for used between the client and the proxy. This is not the case for
client-side "tunneling" proxies using the HTTP CONNECT method. client-side "tunneling" proxies using the HTTP CONNECT method.
o When a black-box implementation of the TLS protocol is used on o When a black-box implementation of the TLS protocol is used on
either peer. either peer.
7.1. Applicability notes 7.1. Applicability notes
When the client is a Web browser with any scripting capabilities, the When the client is a Web browser with any scripting capabilities
underlying TLS channel used with HTTP/TLS MUST provide server (dynamic contents support), the underlying TLS channel used with
identity verification. This means (1) anonymous Diffie-Hellman key HTTP/TLS MUST provide server identity verification. This means (1)
exchange cipher suites MUST NOT be used, and (2) verification of the anonymous Diffie-Hellman key exchange cipher suites MUST NOT be used,
server certificate provided by the server MUST be performed. and (2) verification of the server certificate provided by the server
MUST be performed. This is to prevent loading identity-
unauthenticated scripts or dynamic contents, which are referenced
from the authenticated page.
For other systems, when the underlying TLS channel used with HTTP/TLS For other systems, when the underlying TLS channel used with HTTP/TLS
does not perform server identity verification, the client SHOULD does not perform server identity verification, the client SHOULD
ensure that all the responses are validated using the Mutual ensure that all responses are validated using the Mutual
authentication protocol, regardless of the existence of 401-INIT authentication protocol, regardless of the existence of 401-INIT
responses. responses.
7.2. Notes on tls-unique 7.2. Notes on tls-unique
As described in the interoperability note in the above channel As described in the interoperability note in the above channel
binding specification, the tls-unique verification value will be binding specification, the tls-unique verification value will be
changed by possible TLS renegotiation, causing an interoperability changed by possible TLS renegotiation, causing an interoperability
problem. TLS re-negotiations are used in several HTTPS server problem. TLS re-negotiations are used in several HTTPS server
implementations for enforcing some security properties (such as implementations for enforcing some security properties (such as
skipping to change at page 28, line 20 skipping to change at page 28, line 20
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
[RFC7613]. [RFC7613].
o Passwords received from users SHOULD be prepared using the o Passwords received from users SHOULD be prepared using the
"OpaqueString" profile defined in Section 4.2 of [RFC7613]. "OpaqueString" profile defined in Section 4.2 of [RFC7613].
In both cases, it is the sender's duty to correctly prepare the In both cases, it is the sender's duty to correctly prepare the
character strings. If any non-normalized character string is character strings. If any non-prepared character string is received
received from the other peer of the communication, recipients MAY from the other peer of the communication, the behavior of its
either use it as a bare UTF-8 string without any preparation, perform recipient is not defined; the recipient MAY either accept or reject
any appropriate preparations (which may cause authentication such input.
failure), or reject any ill-prepared inputs from the sender and
respond as a communication error.
Server applications SHOULD also prepare user names and passwords Server applications SHOULD also prepare user names and passwords
accordingly upon registration of user credentials. accordingly upon registration of user credentials.
In addition, binary-based "interfaces" of implementations MAY require In addition, binary-based "interfaces" of implementations MAY require
and assume that the string is already prepared accordingly; when a and assume that the string is already prepared accordingly; when a
string is already stored as a binary Unicode string form, string is already stored as a binary Unicode string form,
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.
skipping to change at page 29, line 24 skipping to change at page 29, line 21
request in the sequence. Such a response returned for a second or request in the sequence. Such a response returned for a second or
later request in the 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 secret
shared between the client and the server, established by shared between the client and the server, established by
req-KEX-C1 and 401-KEX-S1. If any response with 401 status is req-KEX-C1 and 401-KEX-S1. If any response with 401 status is
returned for such a message, the corresponding session key SHOULD returned for such a message, the corresponding session secret
be discarded as unusable. SHOULD be discarded as unusable.
Especially, upon the reception of a 401-STALE response, the client Especially, upon the reception of a 401-STALE response, the client
SHOULD try establishing a new session by sending req-KEX-C1, but SHOULD try establishing a new session by sending req-KEX-C1, but
only once within the request/response sequence. only once within the request/response sequence.
o A 200-VFY-S message MUST be accepted only as a response to o A 200-VFY-S message MUST be accepted only as a response to
req-VFY-C and nothing else. The VK_s values of such response req-VFY-C and nothing else. The VK_s values of such response
messages MUST always be checked against the correct value, and if messages MUST always be checked against the correct value, and if
it is incorrect, the whole response SHOULD be considered invalid. it is incorrect, the whole response SHOULD be considered invalid.
The final status of the client request following the message exchange The final status of the client request following the message exchange
skipping to change at page 36, line 49 skipping to change at page 36, line 49
found, or it is in the "inactive" state, send a 401-STALE found, or it is in the "inactive" state, send a 401-STALE
response. response.
* If the session is in the "rejected" state, send either a * If the session is in the "rejected" state, send either a
401-INIT (+) or a 401-STALE message. 401-INIT (+) or a 401-STALE message.
* If the nc value in the request is larger than the nc-max * If the nc value in the request is larger than the nc-max
parameter sent from the server, or if it is not larger then parameter sent from the server, or if it is not larger then
(largest-nc - nc-window) (when in "authenticated" status), the (largest-nc - nc-window) (when in "authenticated" status), the
server MAY (but is not REQUIRED to; See Note 3) send a server MAY (but is not REQUIRED to; See Note 3) send a
401-STALE message. The session SHOULD be changed to the 401-STALE message. The session is changed to the "inactive"
"inactive" state if so. state if so did.
* If the session is in the "authenticated" state, and the request * If the session is in the "authenticated" state, and the request
has an nc value that was previously received from the client, has an nc value that was previously received from the client,
send a 401-STALE message. The session SHOULD be changed to the send a 401-STALE message. The session it changed to the
"inactive" state. "inactive" state.
* If the session is a "fake" session, or if the received vkc is * If the session is a "fake" session, or if the received vkc is
incorrect, then send a 401-INIT (+) response. If the session incorrect, then send a 401-INIT (+) response. If the session
is in the "key exchanging" state, it SHOULD be changed to the is in the "key exchanging" state, it MUST be changed to the
"rejected" state; otherwise, it MAY either be changed to the "rejected" state; otherwise, it MAY either be changed to the
"rejected" state or kept in the previous state. "rejected" state or kept in the previous state.
* Otherwise, send a 200-VFY-S response. If the session was in * Otherwise, send a 200-VFY-S response. If the session was in
the "key exchanging" state, the session SHOULD be changed to an the "key exchanging" state, the session SHOULD be changed to an
"authenticated" state. The maximum nc and nc flags of the "authenticated" state. The maximum nc and nc flags of the
state SHOULD be updated appropriate. state MUST be updated appropriately.
At any time, the server MAY change any state entries with both the At any time, the server MAY change any state entries with both the
"rejected" and "authenticated" states to the "inactive" status, and "rejected" and "authenticated" states to the "inactive" status, and
MAY discard any "inactive" states from the table. Entries with the MAY discard any "inactive" states from the table. Entries with the
"key exchanging" state SHOULD be kept unless there is an emergency "key exchanging" state SHOULD be kept unless there is an emergency
situation such as a server reboot or a table capacity overflow. situation such as a server reboot or a table capacity overflow.
Note 1: In relation with and following the specification of the Note 1: In relation with and following the specification of the
optional authentication defined in [I-D.ietf-httpauth-extension], the optional authentication defined in [I-D.ietf-httpauth-extension], the
401-INIT messages marked with the pluses cannot be replaced with a 401-INIT messages marked with the pluses cannot be replaced with a
successful responses with an Optional-WWW-Authenticate header. Every successful responses with an Optional-WWW-Authenticate header. Every
other 401-INIT can be a response with an Optional-WWW-Authenticate. other 401-INIT can be a response with an Optional-WWW-Authenticate.
Note 2: the server SHOULD NOT send a 401-INIT response in this case, Note 2: the server SHOULD NOT send a 401-INIT response in this case,
because it will leak the information to the client that the specified because it will leak the information to the client that the specified
user name will not be accepted. Instead, postpone it to the response user name will not be accepted. Instead, postpone it to the response
for the next req-VFY-C request. for the next req-VFY-C request.
Note 3: The next case implies that, when the request is not rejected Note 3: The next case implies that, when the request is not rejected
under this clause, the server MUST be decidable whether the same nc in this clause, the server must be able to determine whether the same
value was previously received from the client. If the server does nc value was previously received from the client. If the server does
not remember a whole history of the nc values received from the not remember a whole history of the nc values received from the
client, the server MUST send a 401-STALE message in this clause. client, the server MUST send a 401-STALE message on this clause.
12. Authentication Algorithms 12. Authentication Algorithms
Cryptographic authentication algorithms which are used with this Cryptographic authentication algorithms which are used with this
protocol will be defined separately. The algorithm definition MUST protocol will be defined separately. The algorithm definition MUST
at least provide definitions for the following functions: at least provide definitions for the following functions:
o The server-side authentication credential J, derived from client- o The server-side authentication credential J, derived from client-
side authentication credential pi. side authentication credential pi.
o Key exchange values K_c1, K_s1 (exchanged on wire) and S_c1, S_s1 o Key exchange values K_c1, K_s1 (exchanged on wire) and S_c1, S_s1
(kept secret in each peer). (kept secret in each peer).
o Shared secret z, to be computed by both server and client. o Shared session secret z, to be computed by both server and client.
o A hash function H to be used with the protocol, along with its o A hash function H to be used with the protocol, along with its
output size hSize. output size hSize.
o The number of iterations for password hashing nIterPi, if it uses o The number of iterations for password hashing nIterPi, if it uses
the default password hashing function defined below. the default password hashing function defined below.
Specifications for cryptographic algorithms used with this framework Specifications for cryptographic algorithms used with this framework
MUST specify whether these will use the default functions defined MUST specify whether these will use the default functions defined
below for values pi, VK_c, and VK_s; or, these will define their own below for values pi, VK_c, and VK_s; or, these will define their own
skipping to change at page 42, line 31 skipping to change at page 42, line 31
specifications use names other than those mentioned above, it is specifications use names other than those mentioned above, it is
RECOMMENDED to use extension-tokens to avoid any parameter name RECOMMENDED to use extension-tokens to avoid any parameter name
conflict with future extensions to this protocol. conflict with future extensions to 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 used in the manner defined in Section 3. domain part in the token is used in the manner defined in Section 3.
16. IANA Considerations 16. IANA Considerations
When bare-tokens are used for the authentication-algorithm, pwd-hash, This document requires an additional entry to the "Hypertext Transfer
and validation parameters, these MUST be allocated by IANA. To Protocol (HTTP) Authentication Scheme Registry" as follows:
acquire registered tokens, a specification for the use of such tokens
MUST be reviewed by a designated expert, as outlined in [RFC5226]. o Authentication Scheme Name: "Mutual"
o Pointer to specification text: (this document)
When bare-tokens are used for the authentication-algorithm and
validation parameters, these MUST be allocated by IANA. To acquire
registered tokens, the usage of such tokens MUST be reviewed by a
designated expert, as outlined in [RFC5226].
16.1. Registry for Authentication Algorithms 16.1. Registry for Authentication Algorithms
This document establishes a registry for HTTP Mutual authentication This document establishes a registry for HTTP Mutual authentication
algorithms. The registry manages case-insensitive ASCII strings. algorithms. The registry manages case-insensitive ASCII strings.
The strings MUST follow the extensive-token syntax defined in The strings MUST follow the extensive-token syntax defined in
Section 3. Section 3.
Registrations for an authentication algorithm are required to include Registrations for an authentication algorithm are required to include
a description of the authentication algorithms. Reviewers assigned a description of the authentication algorithms. Reviewers assigned
skipping to change at page 44, line 23 skipping to change at page 44, line 28
o Even if the server certificate is not used or is unreliable, the o Even if the server certificate is not used or is unreliable, the
protocol provides protection against active man-in-the-middle protocol provides protection against active man-in-the-middle
attacks for each HTTP request/response pair. However, in such attacks for each HTTP request/response pair. However, in such
cases, JavaScript or similar scripting facilities can be used to cases, JavaScript or similar scripting facilities can be used to
affect the Mutually-authenticated contents from other contents not affect the Mutually-authenticated contents from other contents not
protected by this authentication mechanism. This is the reason protected by this authentication mechanism. This is the reason
why this protocol requires that valid TLS server certificates MUST why this protocol requires that valid TLS server certificates MUST
be presented (Section 7). be presented (Section 7).
17.2. Denial-of-service Attacks to Servers 17.2. Secrecy of Credentials
The client-side password credential MUST be kept secret all the time,
and SHOULD NOT be used with any other (possibly insecure)
authentication purpose. Loss of control of the credential will
directly affect the control of corresponding server-side account.
Use of client-side credential with THIS authentication scheme is
always safe, even if the connected server peer is not trustful
(condition of Phishing). However, if it is used with other
authentication schemes (such as Web forms), and if the recipient is
rogue, the result will be obvious.
The server-side password credential (J) is also important to be kept
secret. If it is stolen, and if the client's choice of password is
not strong, the person aware of server-side password credential can
employ a off-line dictionary attack to search for the client
password. However, if the client has chosen a strong password, so
that the attacker cannot guess the client's password from dictionary
candidate, the client is still well protected from any attacks.
The shared session secret (z) MUST be kept secret inside the server/
client software; if it is lost, and if the session is still active,
it will lead to session hijacking. After the session is expired, the
key is valueless for attackers.
17.3. Denial-of-service Attacks to Servers
The protocol requires a server-side table of active sessions, which The protocol requires a server-side table of active sessions, which
may become a critical point for server resource consumption. For may become a critical point for server resource consumption. For
proper operation, the protocol requires that at least one key proper operation, the protocol requires that at least one key
verification request is processed for each session identifier. After verification request is processed for each session identifier. After
that, servers MAY discard sessions internally at any time, without that, servers MAY discard sessions internally at any time, without
causing any operational problems to clients. Clients will silently causing any operational problems to clients. Clients will silently
reestablish a new session then. reestablish a new session then.
However, if a malicious client sends too many requests for key However, if a malicious client sends too many requests for key
skipping to change at page 45, line 5 skipping to change at page 45, line 34
kind of negotiations or states, including Digest authentication kind of negotiations or states, including Digest authentication
scheme and most Cookie-based authentication implementations. scheme and most Cookie-based authentication implementations.
However, regarding the resource consumption, the situation for the However, regarding the resource consumption, the situation for the
mutual authentication scheme is a slightly better than for Digest, mutual authentication scheme is a slightly better than for Digest,
because HTTP requests without any kind of authentication requests because HTTP requests without any kind of authentication requests
will not generate any kind of sessions. Session identifiers are only will not generate any kind of sessions. Session identifiers are only
generated after a client starts a key negotiation. It means that generated after a client starts a key negotiation. It means that
simple clients such as Web crawlers will not accidentally consume simple clients such as Web crawlers will not accidentally consume
server-side resources for session managements. server-side resources for session managements.
17.2.1. On-line Active Password Attacks 17.3.1. On-line Active Password Attacks
Although the protocol provides very strong protection against off- Although the protocol provides very strong protection against off-
line dictionary attacks from eavesdropped traffic, the protocol, by line dictionary attacks from eavesdropped traffic, the protocol, by
its nature, cannot prevent active password attacks in which the its nature, cannot prevent active password attacks in which the
attackers sends so many authentication trial requests for every attackers sends so many authentication trial requests for every
possible password. possible password.
Possible countermeasures for preventing such attacks may be rate- Possible countermeasures for preventing such attacks may be rate-
limiting of password authentication trials, statistics-based limiting of password authentication trials, statistics-based
intrusion detection measures, or similar protection schemes. If the intrusion detection measures, or similar protection schemes. If the
server operators assume that the passwords of users are not strong server operators assume that the passwords of users are not strong
enough, it may be desirable to introduce such ad-hoc countermeasures. enough, it may be desirable to introduce such ad-hoc countermeasures.
17.3. Communicating the status of mutual authentication with users 17.4. Communicating the status of mutual authentication with users
This protocol is designed for two goals. The first goal is just This protocol is designed for two goals. The first goal is just
providing a secure alternative for existing Basic and Digest providing a secure alternative for existing Basic and Digest
authentication. The second goal is to provide users a way to detect authentication. The second goal is to provide users a way to detect
forged rogue servers imitating a user's registered account on a forged rogue servers imitating a user's registered account on a
server, commonly known as (a part or kind of) Phishing attacks. server, commonly known as (a part or kind of) Phishing attacks.
For this protocol to effectively work as some countermeasure to such For this protocol to effectively work as some countermeasure to such
attacks, it is very important that end users of clients be notified attacks, it is very important that end users of clients be notified
of the result of the mutual authentication performed by this of the result of the mutual authentication performed by this
skipping to change at page 45, line 43 skipping to change at page 46, line 23
out of the scope of this document, but if possible, having some kind out of the scope of this document, but if possible, having some kind
of UI indication for the three states above will be desirable for the of UI indication for the three states above will be desirable for the
user's security benefit. user's security benefit.
Of course, in such cases, the user interfaces for asking passwords Of course, in such cases, the user interfaces for asking passwords
for this authentication shall be clearly identifiable against for this authentication shall be clearly identifiable against
imitation by other insecure password input fields (such as forms). imitation by other insecure password input fields (such as forms).
If the passwords are known to malicious attackers outside of the If the passwords are known to malicious attackers outside of the
protocol, the protocol cannot work as an effective security measures. protocol, the protocol cannot work as an effective security measures.
17.4. Implementation Considerations 17.5. Implementation Considerations
o To securely implement the protocol, the Authentication-Info o To securely implement the protocol, the Authentication-Info
headers in the 200-VFY-S messages MUST always be validated by the headers in the 200-VFY-S messages MUST always be validated by the
client. If the validation fails, the client MUST NOT process any client. If the validation fails, the client MUST NOT process any
content sent with the message, including other headers and the content sent with the message, including other headers and the
body part. Non-compliance to this requirement will allow phishing body part. Non-compliance to this requirement will allow phishing
attacks. attacks.
o For HTTP/TLS communications, when a web form is submitted from o For HTTP/TLS communications, when a web form is submitted from
Mutually-authenticated pages with the "tls-server-end-point" Mutually-authenticated pages with the "tls-server-end-point"
skipping to change at page 46, line 23 skipping to change at page 47, line 5
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, o If the TLS 1.2 is used for underlying HTTP/TLS communications,
follow best practices in [RFC7525]. follow best practices in [RFC7525].
17.5. Usage Considerations 17.6. 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
exposed to eavesdroppers even on HTTP requests. exposed to eavesdroppers even on HTTP requests.
o If the server provides several ways for storing server-side o If the server provides several ways for storing server-side
password secrets in the password database, it is desirable for password secrets in the password database, it is desirable for
better security to store the values encrypted by using the one-way better security to store the values encrypted by using the one-way
function J(pi), instead of the real passwords or those hashed by function J(pi), instead of the real passwords or those hashed by
pi. pi.
18. Notice on Intellectual Properties 18. References
The National Institute of Advanced Industrial Science and Technology
(AIST) and Yahoo! Japan, Inc. have jointly submitted a patent
application to the Patent Office of Japan for the protocol proposed
in this documentation. The patent is intended to be open to any
implementer of this protocol and its variants under non-exclusive
royalty-free terms. For the details of the patent application and
its status, please contact the authors of this document.
The elliptic-curve based authentication algorithms might involve
several existing third-party patents. The authors of the document
take no position regarding the validity or scope of such patents and
other patents as well.
19. References
19.1. Normative References 18.1. Normative References
[I-D.ietf-httpauth-extension] [I-D.ietf-httpauth-extension]
Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi,
T., and Y. Ioku, "HTTP Authentication Extensions for T., and Y. Ioku, "HTTP Authentication Extensions for
Interactive Clients", draft-ietf-httpauth-extension-09 Interactive Clients", draft-ietf-httpauth-extension-09
(work in progress), August 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,
skipping to change at page 48, line 31 skipping to change at page 48, line 45
Enforcement, and Comparison of Internationalized Strings Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", RFC 7613, Representing Usernames and Passwords", RFC 7613,
DOI 10.17487/RFC7613, August 2015, DOI 10.17487/RFC7613, August 2015,
<http://www.rfc-editor.org/info/rfc7613>. <http://www.rfc-editor.org/info/rfc7613>.
[RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy- [RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy-
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 [Unicode] The Unicode Consortium, "The Unicode Standard",
<http://www.unicode.org/versions/latest/>.
18.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",
draft-ietf-httpauth-mutual-algo-06 (work in progress),
August 2016.
[ISO.10646-1.1993] KAM3-based Cryptographic Algorithms",
International Organization for Standardization, draft-ietf-httpauth-mutual-algo-07 (work in progress),
"Information Technology - Universal Multiple-octet coded November 2016.
Character Set (UCS) - Part 1: Architecture and Basic
Multilingual Plane", ISO Standard 10646-1, May 1993.
[ITU.X690.1994] [ITU.X690.1994]
International Telecommunications Union, "Information International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, 1994. X.690, 1994.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
skipping to change at page 50, line 18 skipping to change at page 50, line 29
[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 10 A.1. Changes in Httpauth WG Revision 11
o Reflecting IESG comments.
A.2. Changes in Httpauth WG Revision 10
o Small rephrasing and a typo fix. o Small rephrasing and a typo fix.
A.2. Changes in Httpauth WG Revision 09 A.3. Changes in Httpauth WG Revision 09
o Reflected AD review comments. o Reflected AD review comments.
o Authors' addresses updated. o Authors' addresses updated.
A.3. Changes in Httpauth WG Revision 08 A.4. 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.4. Changes in Httpauth WG Revision 07 A.5. 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.5. Changes in Httpauth WG Revision 06 A.6. 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.6. Changes in Httpauth WG Revision 05 A.7. 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.7. Changes in Httpauth WG Revision 04 A.8. 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.8. Changes in Httpauth WG Revision 03 A.9. 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.9. Changes in Httpauth WG Revision 02 A.10. 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.10. Changes in Httpauth WG Revision 01 A.11. 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.11. Changes in Httpauth Revision 00 A.12. 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.12. Changes in HttpBis Revision 00 A.13. Changes in HttpBis Revision 00
None. None.
A.13. Changes in Revision 12 A.14. Changes in Revision 12
o Added a reason "authz-failed". o Added a reason "authz-failed".
A.14. Changes in Revision 11 A.15. 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.15. Changes in Revision 10 A.16. 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 53, line 36 skipping to change at page 54, line 5
+------------+----------+-------------------------------------------+ +------------+----------+-------------------------------------------+
| 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.16. Changes in Revision 09 A.17. 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 |
+-------------------+-----------------+-----------------------------+ +-------------------+-----------------+-----------------------------+
| 401-INIT | 401-B0 | initial response | | 401-INIT | 401-B0 | initial response |
| 401-STALE | 401-B0-stale | session key expired | | 401-STALE | 401-B0-stale | session shared secret |
| | | expired |
| 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.17. Changes in Revision 08 A.18. Changes in Revision 08
o The English text has been revised. o The English text has been revised.
A.18. Changes in Revision 07 A.19. 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.19. Changes in Revision 06 A.20. 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.20. Changes in Revision 05 A.21. 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.21. Changes in Revision 04 A.22. 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.22. Changes in Revision 03 A.23. 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.23. Changes in Revision 02 A.24. 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.24. Changes in Revision 01 A.25. 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
 End of changes. 73 change blocks. 
186 lines changed or deleted 213 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/