draft-ietf-httpauth-mutual-04.txt   draft-ietf-httpauth-mutual-05.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: August 23, 2015 RISEC, AIST Expires: January 7, 2016 ITRI, AIST
K. Maeda K. Maeda
T. Hayashi T. Hayashi
Lepidum Lepidum
Y. Ioku Y. Ioku
Individual Individual
February 19, 2015 July 6, 2015
Mutual Authentication Protocol for HTTP Mutual Authentication Protocol for HTTP
draft-ietf-httpauth-mutual-04 draft-ietf-httpauth-mutual-05
Abstract Abstract
This document specifies a mutual authentication method for the Hyper- This document specifies a mutual authentication method for the Hyper-
text Transfer Protocol (HTTP). This method provides a true mutual text Transfer Protocol (HTTP). This method provides a true mutual
authentication between an HTTP client and an HTTP server using authentication between an HTTP client and an HTTP server using
password-based authentication. Unlike the Basic and Digest password-based authentication. Unlike the Basic and Digest
authentication methods, the Mutual authentication method specified in authentication methods, the Mutual authentication method specified in
this document assures the user that the server truly knows the user's this document assures the user that the server truly knows the user's
encrypted password. encrypted password.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 23, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
4.1. 401-INIT and 401-STALE . . . . . . . . . . . . . . . . . . 15 4.1. 401-INIT and 401-STALE . . . . . . . . . . . . . . . . . . 15
4.2. req-KEX-C1 . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. req-KEX-C1 . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. 401-KEX-S1 . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3. 401-KEX-S1 . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4. req-VFY-C . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4. req-VFY-C . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5. 200-VFY-S . . . . . . . . . . . . . . . . . . . . . . . . 20 4.5. 200-VFY-S . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Authentication Realms . . . . . . . . . . . . . . . . . . . . 20 5. Authentication Realms . . . . . . . . . . . . . . . . . . . . 20
5.1. Resolving Ambiguities . . . . . . . . . . . . . . . . . . 22 5.1. Resolving Ambiguities . . . . . . . . . . . . . . . . . . 22
6. Session Management . . . . . . . . . . . . . . . . . . . . . . 22 6. Session Management . . . . . . . . . . . . . . . . . . . . . . 22
7. Host Validation Methods . . . . . . . . . . . . . . . . . . . 24 7. Host Validation Methods . . . . . . . . . . . . . . . . . . . 24
7.1. Applicability notes . . . . . . . . . . . . . . . . . . . 26 7.1. Applicability notes . . . . . . . . . . . . . . . . . . . 26
7.2. Interoperability notes on tls-unique . . . . . . . . . . . 26 7.2. Notes on tls-unique . . . . . . . . . . . . . . . . . . . 26
8. Authentication Extensions . . . . . . . . . . . . . . . . . . 27 8. Authentication Extensions . . . . . . . . . . . . . . . . . . 27
9. String Preparation . . . . . . . . . . . . . . . . . . . . . . 27 9. String Preparation . . . . . . . . . . . . . . . . . . . . . . 27
10. Decision Procedure for Clients . . . . . . . . . . . . . . . . 28 10. Decision Procedure for Clients . . . . . . . . . . . . . . . . 28
10.1. General Principles and Requirements . . . . . . . . . . . 28 10.1. General Principles and Requirements . . . . . . . . . . . 28
10.2. State machine for the client-side . . . . . . . . . . . . 29 10.2. State machine for the client-side (informative) . . . . . 30
11. Decision Procedure for Servers . . . . . . . . . . . . . . . . 34 11. Decision Procedure for Servers . . . . . . . . . . . . . . . . 34
12. Authentication Algorithms . . . . . . . . . . . . . . . . . . 36 12. Authentication Algorithms . . . . . . . . . . . . . . . . . . 36
12.1. Support Functions and Notations . . . . . . . . . . . . . 37 12.1. Support Functions and Notations . . . . . . . . . . . . . 37
12.2. Default Functions for Algorithms . . . . . . . . . . . . . 38 12.2. Default Functions for Algorithms . . . . . . . . . . . . . 38
13. Application Channel Binding . . . . . . . . . . . . . . . . . 39 13. Application Channel Binding . . . . . . . . . . . . . . . . . 39
14. Application for Proxy Authentication . . . . . . . . . . . . . 40 14. Application for Proxy Authentication . . . . . . . . . . . . . 40
15. Methods to Extend This Protocol . . . . . . . . . . . . . . . 40 15. Methods to Extend This Protocol . . . . . . . . . . . . . . . 40
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
17. Security Considerations . . . . . . . . . . . . . . . . . . . 41 16.1. Registry for Authentication Algorithms . . . . . . . . . . 41
17.1. Security Properties . . . . . . . . . . . . . . . . . . . 41 16.2. Registry for Password Hashes . . . . . . . . . . . . . . . 42
17.2. Denial-of-service Attacks to Servers . . . . . . . . . . . 42 16.3. Registry for Validation Methods . . . . . . . . . . . . . 42
17.2.1. On-line Active Password Attacks . . . . . . . . . . . 42 17. Security Considerations . . . . . . . . . . . . . . . . . . . 43
17.1. Security Properties . . . . . . . . . . . . . . . . . . . 43
17.2. Denial-of-service Attacks to Servers . . . . . . . . . . . 44
17.2.1. On-line Active Password Attacks . . . . . . . . . . . 44
17.3. Communicating the status of mutual authentication with 17.3. Communicating the status of mutual authentication with
users . . . . . . . . . . . . . . . . . . . . . . . . . . 43 users . . . . . . . . . . . . . . . . . . . . . . . . . . 44
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 Remarks from Authors . . . . . . 47 Appendix A. (Informative) Draft Remarks from Authors . . . . . . 49
Appendix B. (Informative) Draft Change Log . . . . . . . . . . . 47 Appendix B. (Informative) Draft Change Log . . . . . . . . . . . 49
B.1. Changes in Httpauth WG Revision 04 . . . . . . . . . . . . 47 B.1. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 50
B.2. Changes in Httpauth WG Revision 03 . . . . . . . . . . . . 48 B.2. Changes in Httpauth WG Revision 04 . . . . . . . . . . . . 50
B.3. Changes in Httpauth WG Revision 02 . . . . . . . . . . . . 48 B.3. Changes in Httpauth WG Revision 03 . . . . . . . . . . . . 50
B.4. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 48 B.4. Changes in Httpauth WG Revision 02 . . . . . . . . . . . . 50
B.5. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 48 B.5. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 50
B.6. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 49 B.6. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 51
B.7. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 49 B.7. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 51
B.8. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 49 B.8. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 51
B.9. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 49 B.9. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 51
B.10. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 50 B.10. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 51
B.11. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 50 B.11. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 52
B.12. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 50 B.12. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 53
B.13. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 51 B.13. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 53
B.14. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 51 B.14. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 53
B.15. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 51 B.15. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 54
B.16. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 52 B.16. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 54
B.17. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 52 B.17. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 54
B.18. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 52 B.18. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 B.19. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
This document specifies a mutual authentication method for Hyper-Text This document specifies a mutual authentication method for Hyper-Text
Transfer Protocol (HTTP). The method, called "Mutual Authentication Transfer Protocol (HTTP). The method, called "Mutual Authentication
Protocol" in this document, provides a true mutual authentication Protocol" in this document, provides a true mutual authentication
between an HTTP client and an HTTP server, using just a simple between an HTTP client and an HTTP server, using just a simple
password as a credential. password as a credential.
The authentication method proposed in this document has the following The authentication method proposed in this document is a general
main characteristics: framework for using password-based authenticated key exchange (PAKE)
and similar stronger cryptographic primitives on the HTTP. It has
the following main characteristics:
o It provides "true" mutual authentication: in addition to assuring o It provides "true" mutual authentication: in addition to assuring
the server that the user knows the password, it also assures the the server that the user knows the password, it also assures the
user that the server truly knows the user's encrypted password at user that the server truly knows the user's encrypted password at
the same time. This makes it impossible for fake website owners the same time. This makes it impossible for fake website owners
to persuade users that they have authenticated with the original to persuade users that they have authenticated with the original
websites. websites.
o It uses only passwords as the user's credential: unlike public- o It uses only passwords as the user's credential: unlike public-
key-based security algorithms, the method does not rely on secret key-based security algorithms, the method does not rely on secret
skipping to change at page 5, line 30 skipping to change at page 5, line 32
o The sections after that contain general normative and informative o The sections after that contain general normative and informative
information about the protocol. information about the protocol.
o The appendices contain some information that may help developers o The appendices contain some information that may help developers
to implement the protocol. to implement the protocol.
In addition, there are two companion documents which are referred In addition, there are two companion documents which are referred
from/related to this specification: from/related to this specification:
o [I-D.ietf-httpauth-mutual-algo]: defines a cryptographic o [I-D.ietf-httpauth-mutual-algo]: defines a cryptographic
primitives which can be used with this protocol framework. [draft primitives which can be used with this protocol framework.
note: it is separated from this document so that it may be
replaced with another crypto in future.]
o [I-D.ietf-httpauth-extension]: defines a small but useful o [I-D.ietf-httpauth-extension]: defines a small but useful
extensions to the current HTTP authentication framework so that it extensions to the current HTTP authentication framework so that it
can support application-level semantics of existing Web systems. can support application-level semantics of existing Web systems.
2. Protocol Overview 2. Protocol Overview
The protocol, as a whole, is designed as a natural extension to the The protocol, as a whole, is designed as a natural extension to the
HTTP protocol [RFC7230] using a framework defined in [RFC7235]. HTTP protocol [RFC7230] using a framework defined in [RFC7235].
Internally, the server and the client will first perform a Internally, the server and the client will first perform a
skipping to change at page 11, line 6 skipping to change at page 11, line 6
3. Message Syntax 3. Message Syntax
Throughout this specification, The syntax is denoted in the extended Throughout this specification, The syntax is denoted in the extended
augmented BNF syntax defined in [RFC7230] and [RFC5234]. The augmented BNF syntax defined in [RFC7230] and [RFC5234]. The
following elements are quoted from [RFC5234], [RFC7230] and following elements are quoted from [RFC5234], [RFC7230] and
[RFC7235]: DIGIT, ALPHA, SP, auth-scheme, quoted-string, auth-param, [RFC7235]: DIGIT, ALPHA, SP, auth-scheme, quoted-string, auth-param,
header-field, token, challenge, and credential. header-field, token, challenge, and credential.
The Mutual authentication protocol uses three headers: The Mutual authentication protocol uses three headers:
WWW-Authenticate (in responses with status code 401), Authorization WWW-Authenticate (usually in responses with status code 401),
(in requests), and Authentication-Info (in responses other than 401 Authorization (in requests), and Authentication-Info (in responses
status). These headers follow a common framework described in other than 401 status). These headers follow a common framework
[RFC7235] and [I-D.ietf-httpbis-auth-info]. The detailed meanings described in [RFC7235] and [I-D.ietf-httpbis-auth-info]. The
for these headers are contained in Section 4. detailed meanings for these headers are contained in Section 4.
The framework in [RFC7235] defines the syntax for the headers The framework in [RFC7235] defines the syntax for the headers
WWW-Authenticate and Authorization as the syntax elements "challenge" WWW-Authenticate and Authorization as the syntax elements "challenge"
and "credentials", respectively. The "auth-scheme" contained in and "credentials", respectively. The "auth-scheme" contained in
those headers MUST be "Mutual" throughout this protocol those headers MUST be "Mutual" throughout this protocol
specification. The syntax for "challenge" and "credentials" to be specification. The syntax for "challenge" and "credentials" to be
used with the "Mutual" auth-scheme SHALL be name-value pairs (#auth- used with the "Mutual" auth-scheme SHALL be name-value pairs (#auth-
param), not the "b64token" defined in [RFC7235]. param), not the "b64token" defined in [RFC7235].
The Authentication-Info: header used in this protocol SHALL follow The Authentication-Info: header used in this protocol SHALL follow
skipping to change at page 14, line 17 skipping to change at page 14, line 17
generates it first, and the same length SHALL be used throughout the generates it first, and the same length SHALL be used throughout the
all communications by both peers. all 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 [RFC4648]
without any spaces and newlines. Implementations decoding base64- without any spaces and newlines. Implementations decoding base64-
fixed-number SHOULD reject any input data with invalid characters, fixed-number SHOULD reject any input data with invalid characters,
excess/insufficient paddings, or non-canonical pad bits (See Sections excess/insufficient padding, or non-canonical pad bits (See Sections
3.1 to 3.5 of [RFC4648]). 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 15, line 22 skipping to change at page 15, line 22
the protocol described in this specification MUST always send a token the protocol described in this specification MUST always send a token
"-wg-draft04", and recipients MUST reject messages which contain any "-wg-draft04", and recipients MUST reject messages which contain any
other value as a version, unless another specification defines a other value as a version, unless another specification defines a
behavior for that version. [[Editorial Note: This token is updated behavior for that version. [[Editorial Note: This token is updated
on every draft revisions which will affect the wire protocol. It on every draft revisions which will affect the wire protocol. It
will (shall) be updated to "1" in the final published RFC.]] will (shall) be updated to "1" in the final published RFC.]]
4.1. 401-INIT and 401-STALE 4.1. 401-INIT and 401-STALE
Every 401-INIT or 401-STALE message SHALL be a valid HTTP 401-status Every 401-INIT or 401-STALE message SHALL be a valid HTTP 401-status
(Authentication Required) message containing one (and only one: (Authentication Required) message (or other 4XX statuses if sensible)
hereafter not explicitly noticed) "WWW-Authenticate" header containing one (and only one: hereafter not explicitly noticed)
containing a "reason" parameter in the challenge. The challenge "WWW-Authenticate" header containing a "reason" parameter in the
SHALL contain all of the parameters marked "mandatory" below, and MAY challenge. The challenge SHALL contain all of the parameters marked
contain those marked "non-mandatory". "mandatory" below, and MAY contain those marked "non-mandatory".
version: (mandatory extensive-token) should be the token "-wg- version: (mandatory extensive-token) should be the token "-wg-
draft04". draft04".
algorithm: (mandatory extensive-token) specifies the algorithm: (mandatory extensive-token) specifies the
authentication algorithm to be used. The value MUST authentication algorithm to be used. The value MUST
be one of the tokens specified in be one of the tokens specified in
[I-D.ietf-httpauth-mutual-algo] or other supplemental [I-D.ietf-httpauth-mutual-algo] or other supplemental
specification documentation. specification documentation.
skipping to change at page 17, line 30 skipping to change at page 17, line 30
security implications, except for special-purpose security implications, except for special-purpose
applications which makes this value sense. applications which makes this value sense.
* invalid-credential: ditto, suggesting that the * invalid-credential: ditto, suggesting that the
provided user-name was valid but authentication was provided user-name was valid but authentication was
failed. The use of this parameter is failed. The use of this parameter is
NOT RECOMMENDED as the same as the above. NOT RECOMMENDED as the same as the above.
* 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 is to the specific authenticated user. (It might be
different from 403 responses which suggest that the used along with either 401 or 403 status to
reason of inaccessibility is other that indicate that the authentication result is one of
authentication.) highly likely reasons for the failed
authorization.)
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.
skipping to change at page 18, line 46 skipping to change at page 18, line 46
have uniqueness of at least 80 bits or the square of have uniqueness of at least 80 bits or the square of
the maximal estimated transactions concurrently the maximal estimated transactions concurrently
available in the session table, whichever is larger. available in the session table, whichever is larger.
See Section 6 for more details. See Section 6 for more details.
ks1: (mandatory, algorithm-determined) is the server-side ks1: (mandatory, algorithm-determined) is the server-side
key exchange value K_s1, which is specified by the key exchange value K_s1, which is specified by the
algorithm. algorithm.
nc-max: (mandatory, integer) is the maximal value of nonce nc-max: (mandatory, integer) is the maximal value of nonce
counts that the server accepts. numbers that the server accepts.
nc-window: (mandatory, integer) the number of available nonce nc-window: (mandatory, integer) the number of available nonce
slots that the server will accept. The value of the number slots that the server will accept. The value
nc-window parameter is RECOMMENDED to be 32 or more. of the nc-window parameter is RECOMMENDED to be 128 or
more.
time: (mandatory, integer) represents the suggested time (in time: (mandatory, integer) represents the suggested time (in
seconds) that the client can reuse the session seconds) that the client can reuse the session
represented by the sid. It is RECOMMENDED to be at represented by the sid. It is RECOMMENDED to be at
least 60. The value of this parameter is not directly least 60. The value of this parameter is not directly
linked to the duration that the server keeps track of linked to the duration that the server keeps track of
the session represented by the sid. the session represented by the sid.
path: (non-mandatory, string) specifies which path in the path: (non-mandatory, string) specifies which path in the
URI space the same authentication is expected to be URI space the same authentication is expected to be
skipping to change at page 19, line 41 skipping to change at page 19, line 41
version: (mandatory, extensive-token) should be the token "-wg- version: (mandatory, extensive-token) should be the token "-wg-
draft04". draft04".
algorithm, validation, auth-domain, realm: MUST be the same value as algorithm, validation, auth-domain, realm: MUST be the same value as
it is when received from the server for the session. it is when received from the server for the session.
sid: (mandatory, hex-fixed-number) MUST be one of the sid sid: (mandatory, hex-fixed-number) MUST be one of the sid
values that was received from the server for the same values that was received from the server for the same
authentication realm. authentication realm.
nc: (mandatory, integer) is a nonce value that is unique nc: (mandatory, integer) is a nonce request number that is
among the requests sharing the same sid. The values unique among the requests sharing the same sid. The
of the nonces SHOULD satisfy the properties outlined values of the nonce numbers SHOULD satisfy the
in Section 6. properties outlined in Section 6.
vkc: (mandatory, algorithm-determined) is the client-side vkc: (mandatory, algorithm-determined) is the client-side
authentication verification value VK_c, which is authentication verification value VK_c, which is
specified by the algorithm. specified by the algorithm.
4.5. 200-VFY-S 4.5. 200-VFY-S
Every 200-VFY-S message SHALL be a valid HTTP message that is not of Every 200-VFY-S message SHALL be a valid HTTP message that is not of
the 401 (Authentication Required) status, containing an the 401 (Authentication Required) status, containing an
"Authentication-Info" header with a "vks" parameter. "Authentication-Info" header with a "vks" parameter.
skipping to change at page 23, line 29 skipping to change at page 23, line 29
The server SHOULD accept at least one req-VFY-C request for each The server SHOULD accept at least one req-VFY-C request for each
session, given that the request reaches the server in a time window session, given that the request reaches the server in a time window
specified by the timeout parameter in the 401-KEX-S1 message, and specified by the timeout parameter in the 401-KEX-S1 message, and
that there are no emergent reasons (such as flooding attacks) to that there are no emergent reasons (such as flooding attacks) to
forget the sessions. After that, the server MAY discard any session forget the sessions. After that, the server MAY discard any session
at any time and MAY send 401-STALE messages for any req-VFY-C at any time and MAY send 401-STALE messages for any req-VFY-C
requests. requests.
The client MAY send two or more requests using a single session The client MAY send two or more requests using a single session
specified by the sid. However, for all such requests, each value of specified by the sid. However, for all such requests, each value of
the nonce (in the nc parameter) MUST satisfy the following the nonce number (in the nc parameter) MUST satisfy the following
conditions: conditions:
o It is a natural number. o It is a natural number.
o The same nonce was not sent within the same session. o The same nonce number was not sent within the same session.
o It is not larger than the nc-max value that was sent from the o It is not larger than the nc-max value that was sent from the
server in the session represented by the sid. server in the session represented by the sid.
o It is larger than (largest-nc - nc-window), where largest-nc is o It is larger than (largest-nc - nc-window), where largest-nc is
the maximal value of nc which was previously sent in the session, the maximal value of nc which was previously sent in the session,
and nc-window is the value of the nc-window parameter which was and nc-window is the value of the nc-window parameter which was
received from the server in the session. received from the server in the session.
The last condition allows servers to reject any nonce values that are The last condition allows servers to reject any nonce numbers that
"significantly" smaller than the "current" value (defined by the are "significantly" smaller than the "current" value (defined by the
value of nc-window) of the nonce used in the session involved. In value of nc-window) of the nonce number used in the session involved.
other words, servers MAY treat such nonces as "already received". In other words, servers MAY treat such nonce numbers as "already
This restriction enables servers to implement duplicated nonce received". This restriction enables servers to implement duplicated
detection in a constant amount of memory (for each session). nonce detection in a constant amount of memory (for each session).
Servers MUST check for duplication of the received nonces, and if any Servers MUST check for duplication of the received nonce numbers, and
duplication is detected, the server MUST discard the session and if any duplication is detected, the server MUST discard the session
respond with a 401-STALE message, as outlined in Section 11. The and respond with a 401-STALE message, as outlined in Section 11. The
server MAY also reject other invalid nonce values (such as ones above server MAY also reject other invalid nonce numbers (such as ones
the nc-max limit) by sending a 401-STALE message. above the nc-max limit) by sending a 401-STALE message.
For example, assume the nc-window value of the current session is 32, For example, assume the nc-window value of the current session is
nc-max is 100, and that the client has already used the following 128, nc-max is 400, and that the client has already used the
nonce values: {1-20, 22, 24, 30-38, 45-60, 63-72}. Then the nonce following nonce numbers: {1-120, 122, 124, 130-238, 255-360, 363-
values that can be used for next request is one of the following set: 372}. Then the nonce number that can be used for next request is one
{41-44, 61-62, 73-100}. The values {0, 21, 23, 25-29, 39-40} MAY be of the following set: {245-254, 361, 362, 373-400}. The values {0,
rejected by the server because they are not above the current "window 121, 123, 125-129, 239-244} MAY be rejected by the server, because
limit" (40 = 72 - 32). they are not above the current "window limit" (244 = 372 - 128).
Typically, clients can ensure the above property by using a Typically, clients can ensure the above property by using a
monotonically-increasing integer counter that counts from zero upto monotonically-increasing integer counter that counts from zero upto
the value of nc-max. the value of nc-max.
The values of the nonces and any nonce-related values MUST always be The values of the nonce numbers and any nonce-related values MUST
treated as natural numbers within an infinite range. Implementations always be treated as natural numbers within an infinite range.
which uses fixed-width integer representations, fixed-precision Implementations which uses fixed-width integer representations,
floating numbers or similar representations SHOULD NOT reject any fixed-precision floating numbers or similar representations
larger values which overflow such representative limits, and MUST NOT SHOULD NOT reject any larger values which overflow such
silently truncate it using any modulus-like rounding operation (e.g. representative limits, and MUST NOT silently truncate it using any
by mod 2^32). Instead, the whole protocol is carefully designed so modulus-like rounding operation (e.g. by mod 2^32). Instead, the
that recipients MAY replace any such overflowed values (e.g. 2^80) whole protocol is carefully designed so that recipients MAY replace
with some reasonably-large maximal representative integer (e.g. 2^31 any such overflowed values (e.g. 2^80) with some reasonably-large
- 1 or others). maximal representative integer (e.g. 2^31 - 1 or others).
7. Host Validation Methods 7. Host Validation Methods
The "validation method" specifies a method to "relate" (or "bind") The "validation method" specifies a method to "relate" (or "bind")
the mutual authentication processed by this protocol with other the mutual authentication processed by this protocol with other
authentications already performed in the underlying layers and to authentications already performed in the underlying layers and to
prevent man-in-the-middle attacks. It decides the value vh that is prevent man-in-the-middle attacks. It decides the value vh that is
an input to the authentication protocols. an input to the authentication protocols.
When HTTPS or other possible secure transport is used, this When HTTPS or other possible secure transport is used, this
skipping to change at page 25, line 27 skipping to change at page 25, line 27
underlying TLS [RFC5246] (or SSL) connection, underlying TLS [RFC5246] (or SSL) connection,
processed as specified in Section 4.1 of [RFC5929]. processed as specified in Section 4.1 of [RFC5929].
[[Pending editorial issue: a small security issue is [[Pending editorial issue: a small security issue is
pending around here, awaiting analysis and WG pending around here, awaiting analysis and WG
discussions for final adoption.]] discussions for final adoption.]]
tls-unique: TLS shared-key validation: The value v will be the tls-unique: TLS shared-key validation: The value v 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].
(Note: see Section 7.2 for some security notices for
using this validation method.)
If the HTTP protocol is used on a non-encrypted channel (TCP and If the HTTP protocol is used on a non-encrypted channel (TCP and
SCTP, for example), the validation type MUST be "host". If HTTP/TLS SCTP, for example), the validation type MUST be "host". If HTTP/TLS
[RFC2818] (HTTPS) protocol is used with the server certificates, the [RFC2818] (HTTPS) protocol is used with the server certificates, the
validation type MUST be "tls-server-end-point". If HTTP/TLS protocol validation type MUST be "tls-server-end-point". If HTTP/TLS protocol
is used with an anonymous Diffie-Hellman key exchange, the validation is used with an anonymous Diffie-Hellman key exchange, the validation
type MUST be "tls-unique" (see the note below). type MUST be "tls-unique" (see the note below).
Implementations supporting a Mutual authentication over the HTTPS Implementations supporting a Mutual authentication over the HTTPS
protocol SHOULD support the "tls-server-end-point" validation. protocol SHOULD support the "tls-server-end-point" validation.
Support for "tls-unique" validation is OPTIONAL for both the servers Support for "tls-unique" validation is OPTIONAL for both the servers
and clients. 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 on TLS connection MUST be verified at least to certificate provided on TLS connection MUST be verified at least to
make sure that the server actually owns the corresponding secret key. make sure that the server actually owns the corresponding secret key.
(Note: this verification is automatic in some RSA-based key exchanges (Note: this verification is automatic in some RSA-based key exchanges
but NOT automatic in Diffie-Hellman-based key exchanges with separate but NOT automatic in Diffie-Hellman-based key exchanges with separate
exchange for server verifications.) exchange for server verification.)
Clients MUST validate this parameter upon reception of the 401-INIT Clients MUST validate this parameter upon reception of the 401-INIT
messages. messages.
Note: The protocol defines two variants for validation on the TLS Note: The protocol defines two variants for validation on the TLS
connections. The "tls-unique" method is more secure. However, there connections. The "tls-unique" method is more secure. However, there
are some situations where tls-server-end-point is more preferable. 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
skipping to change at page 26, line 28 skipping to change at page 26, line 30
identity verification. This means (1) the anonymous Diffie-Hellman identity verification. This means (1) the anonymous Diffie-Hellman
key exchange cipher-suite MUST NOT be used, and (2) the verification key exchange cipher-suite MUST NOT be used, and (2) the verification
of the server certificate provided from the server MUST be performed. of the server certificate provided from the server MUST be performed.
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 the responses are validated using the Mutual
authentication protocol, regardless of the existence of the 401-INIT authentication protocol, regardless of the existence of the 401-INIT
responses. responses.
7.2. Interoperability 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
cryptographic strength) for some specific responses. cryptographic strength) for some specific responses.
If an implementation supports "tls-unique" verification method, the If an implementation supports "tls-unique" verification method, the
following caution SHOULD be taken: following caution SHOULD be taken:
skipping to change at page 27, line 5 skipping to change at page 27, line 6
values MUST be retrieved from underlying TLS libraries each time values MUST be retrieved from underlying TLS libraries each time
it is used. it is used.
o After calculating value vh and vkc to send a req-VFY-C request, o After calculating value vh and vkc to send a req-VFY-C request,
Clients SHOULD NOT initiate TLS renegotiation until the end of the Clients SHOULD NOT initiate TLS renegotiation until the end of the
corresponding response header is received. Exceptionally, Clients corresponding response header is received. Exceptionally, Clients
can and SHOULD perform TLS re-negotiation as a response to can and SHOULD perform TLS re-negotiation as a response to
server's request for TLS renegotiation, occurring before the top server's request for TLS renegotiation, occurring before the top
of response header. of response header.
Also, implementer MUST take care of session resumption attacks
regarding tls-unique channel binding mechanisms and master secrets.
As a mitigation, a TLS extension defined in
[I-D.ietf-tls-session-hash] SHOULD be used when tls-unique host
verification is to be used.
8. Authentication Extensions 8. Authentication Extensions
Interactive clients (e.g. Web browsers) supporting this protocol are Interactive clients (e.g. Web browsers) supporting this protocol are
RECOMMENDED to support non-mandatory authentication and the RECOMMENDED to support non-mandatory authentication and the
Authentication-Control header defined in Authentication-Control header defined in
[I-D.ietf-httpauth-extension], except the "auth-style" parameter. [I-D.ietf-httpauth-extension], except the "auth-style" parameter.
This specification also proposes (however, not mandates) default This specification also proposes (however, not mandates) default
"auth-style" to be "non-modal". Web applications SHOULD however "auth-style" to be "non-modal". Web applications SHOULD however
consider the security impacts of the behaviors of clients that do not consider the security impacts of the behaviors of clients that do not
support these headers. support these headers.
skipping to change at page 28, line 18 skipping to change at page 28, line 27
10.1. General Principles and Requirements 10.1. General Principles and Requirements
To securely implement the protocol, the user client must be careful To securely implement the protocol, the user client must be careful
about accepting the authenticated responses from the server. This about accepting the authenticated responses from the server. This
also holds true for the reception of "normal responses" (responses also holds true for the reception of "normal responses" (responses
which do not contain Mutual-related headers) from HTTP servers. which do not contain Mutual-related headers) from HTTP 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 care MUST be taken by the all clients sequence. The following normative rules MUST be followed by the all
implementing this protocol: clients implementing this protocol:
o Any kinds of "normal responses" MUST only be accepted for the very o Any kinds of "normal responses" MUST only be accepted for the very
first request in the sequence. Any "normal responses" returned first request in the sequence. Any "normal responses" returned
for the second or later request in the sequence SHALL be for the second or later request in the sequence SHALL be
considered invalid. considered invalid.
o In the same principle, any responses which refer to, or request o In the same principle, any responses which refer to, or request
changing to, the authentication realm different from the client's changing to, the authentication realm different from the client's
request MUST only be accepted for the very first request in the request MUST only be accepted for the very first request in the
sequence. Any kind of responses referring to the different realms sequence. Any kind of responses referring to the different realms
skipping to change at page 29, line 46 skipping to change at page 30, line 6
it is still RECOMMENDED, as it may possibly be forged by intermediate it is still RECOMMENDED, as it may possibly be forged by intermediate
attackers,) and the client will be in the "UNAUTHENTICATED" status attackers,) and the client will be in the "UNAUTHENTICATED" status
then. then.
If a request is a sub-request for a resource included in another If a request is a sub-request for a resource included in another
resources (e.g., embedded images, style sheets, frames etc.), clients resources (e.g., embedded images, style sheets, frames etc.), clients
MAY treat an AUTH-REQUESTED status as the same as UNAUTHENTICATED MAY treat an AUTH-REQUESTED status as the same as UNAUTHENTICATED
status. In other words, the client MAY ignore server's request to status. In other words, the client MAY ignore server's request to
start authentication with new credentials via sub-requests. start authentication with new credentials via sub-requests.
10.2. State machine for the client-side 10.2. State machine for the client-side (informative)
The following state machine describes the possible request-response The following state machine describes the possible request-response
sequences derived from the above general rules. If implementors are sequences derived from the above normative rules. If implementer are
not quite sure on the security consequences of the above rules, it is not quite sure on the security consequences of the above rules, it is
strongly RECOMMENDED to follow the decision procedure below. In strongly advised to follow the decision procedure below. In
particular, clients SHOULD NOT accept "normal responses" unless particular, clients SHOULD NOT accept "normal responses" unless
explicitly allowed in the rules. The labels on the steps are for explicitly allowed in the rules. The labels on the steps are for
informational purposes only. Action entries within each step are informational purposes only. Action entries within each step are
checked in top-to-bottom order, and the first clause satisfied SHOULD checked in top-to-bottom order, and the first clause satisfied is to
be taken. be followed.
Step 1 (step_new_request): Step 1 (step_new_request):
If the client software needs to access a new Web resource, check If the client software needs to access a new Web resource, check
whether the resource is expected to be inside some authentication whether the resource is expected to be inside some authentication
realm for which the user has already been authenticated by the realm for which the user has already been authenticated by the
Mutual authentication scheme. If yes, go to Step 2. Otherwise, Mutual authentication scheme. If yes, go to Step 2. Otherwise,
go to Step 5. go to Step 5.
Step 2: Step 2:
Check whether there is an available sid for the authentication Check whether there is an available sid for the authentication
skipping to change at page 32, line 34 skipping to change at page 32, line 40
If the value is unexpected, it is a fatal communication error. If the value is unexpected, it is a fatal communication error.
If a user explicitly requests to log out (via user interfaces), If a user explicitly requests to log out (via user interfaces),
the client MUST forget the user's password, go to step 5 and the client MUST forget the user's password, go to step 5 and
reload the current resource without an authentication header. reload the current resource without an authentication header.
Note 1: These transitions MAY be accepted by clients, but Note 1: These transitions MAY be accepted by clients, but
NOT RECOMMENDED for servers to initiate. NOT RECOMMENDED for servers to initiate.
Figure 5 shows a diagram of the client-side state. Figure 5 shows an informative diagram of the client-side state.
=========== -(11)------------ =========== -(11)------------
NEW REQUEST ( UNAUTHENTICATED ) NEW REQUEST ( UNAUTHENTICATED )
=========== ----------------- =========== -----------------
| ^ normal | ^ normal
v | response v | response
+(1)-------------------+ NO +(5)----------+ +(1)-------------------+ NO +(5)----------+
| The requested URI |--------------------------->| send normal | | The requested URI |--------------------------->| send normal |
| known to be auth'ed? | | request | | known to be auth'ed? | | request |
+----------------------+ +-------------+ +----------------------+ +-------------+
skipping to change at page 37, line 8 skipping to change at page 37, line 8
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 in both server-side and client o Shared secret z, to be computed in both server-side and client
side. side.
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 iteration for password hasing 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 the functions pi, VK_c, and VK_s; or, these will define below for the functions pi, VK_c, and VK_s; or, these will define
their own versions for these functions. their own versions for these functions.
All algorithm used with this protocol SHOULD provide secure mutual All algorithm used with this protocol SHOULD provide secure mutual
authentication between client and servers, and generate a authentication between client and servers, and generate a
cryptographically strong shared secret value z, equivalently strong cryptographically strong shared secret value z, equivalently strong
skipping to change at page 37, line 46 skipping to change at page 37, line 46
The function octet(c) generates a single octet string whose code The function octet(c) generates a single octet string whose code
value is equal to c. The operator |, when applied to octet strings, value is equal to c. The operator |, when applied to octet strings,
denotes the concatenation of two operands. denotes the concatenation of two operands.
The function VI encodes natural numbers into octet strings in the The function VI encodes natural numbers into octet strings in the
following manner: numbers are represented in big-endian radix-128 following manner: numbers are represented in big-endian radix-128
string, where each digit is represented by a octet within 0x80-0xff string, where each digit is represented by a octet within 0x80-0xff
except the last digit represented by a octet within 0x00-0x7f. The except the last digit represented by a octet within 0x00-0x7f. The
first octet MUST NOT be 0x80. For example, VI(i) = octet(i) for i < first octet MUST NOT be 0x80. For example, VI(i) = octet(i) for i <
128, and VI(i) = octet(0x80 + (i >> 7)) | octet(i & 127) for 128 <= i 128, and VI(i) = octet(0x80 + (i >> 7)) | octet(i & 127) for 128 <= i
< 16384. This encoding is the same as the one used for the < 16384. This encoding is the same as the one used for the sub-
subcomponents of object identifiers in the ASN.1 encoding components of object identifiers in the ASN.1 encoding
[ITU.X690.1994], and available as a "w" conversion in the pack [ITU.X690.1994], and available as a "w" conversion in the pack
function of several scripting languages. function of several scripting languages.
The function VS encodes a variable-length octet string into a The function VS encodes a variable-length octet string into a
uniquely-decoded, self-delimited octet string, as in the following uniquely-decoded, self-delimited octet string, as in the following
manner: manner:
VS(s) = VI(length(s)) | s VS(s) = VI(length(s)) | s
where length(s) is a number of octets (not characters) in s. where length(s) is a number of octets (not characters) in s.
skipping to change at page 41, line 28 skipping to change at page 41, line 28
Extension-tokens MAY be freely used for any non-standard, private, Extension-tokens MAY be freely used for any non-standard, private,
and/or experimental uses for those parameters provided that the and/or experimental uses for those parameters provided that the
domain part in the token is appropriately used. domain part in the token is appropriately used.
16. IANA Considerations 16. IANA Considerations
When bare-tokens are used for the authentication-algorithm, pwd-hash, When bare-tokens are used for the authentication-algorithm, pwd-hash,
and validation parameters MUST be allocated by IANA. To acquire and validation parameters MUST be allocated by IANA. To acquire
registered tokens, a specification for the use of such tokens MUST be registered tokens, a specification for the use of such tokens MUST be
available as an RFC, as outlined in [RFC5226]. reviewed by a designated expert, as outlined in [RFC5226].
Note: More formal declarations will be added in the future drafts to 16.1. Registry for Authentication Algorithms
meet the RFC 5226 requirements.
This document establishes a registry for HTTP Mutual authentication
algorithms. The registry manages a case-insensitive ASCII strings.
The string MUST follow the extensive-token syntax defined in
Section 3.
Registrations for authentication algorithms are required to include a
description of the key exchange algorithms. Reviewers assigned by
IESG are advised to examine minimum security requirements and
consistency of the key exchange algorithm descriptions.
New registrations are advised to provide the following information:
o Token: a token used in HTTP headers for identifying the algorithm.
o Description: A brief description of the algorithm.
o Specification: A reference for a specification defining the
algorithm.
The initial content of this registry is empty. [[Editorial Note: A
separate document [I-D.ietf-httpauth-mutual-algo] will effectively
define the initial content of the registry.]]
16.2. Registry for Password Hashes
This document establishes a registry for HTTP Mutual authentication
password hashes. The registry manages a case-insensitive ASCII
strings. The string MUST follow the extensive-token syntax defined
in Section 3.
Registrations for authentication algorithms are required to include a
description of the key exchange algorithms. Reviewers assigned by
IESG are advised to examine its use-case requirements and security
consequence of its introduction.
New registrations are advised to provide the following information:
o Token: a token used in HTTP headers for identifying the algorithm.
o Description: A brief description of the algorithm.
o Specification: A reference for a specification defining the
algorithm.
The initial content of this registry is as follows:
+------------+------------------------------------+---------------+
| Token | Description | Specification |
+------------+------------------------------------+---------------+
| none | No additional hashing, recommended | Section 4.1 |
| md5 | MD5-based preprocessing | Section 4.1 |
| digest-md5 | Digest-compatible preprocessing | Section 4.1 |
| sha1 | SHA1-based preprocessing | Section 4.1 |
+------------+------------------------------------+---------------+
16.3. Registry for Validation Methods
This document establishes a registry for HTTP Mutual authentication
host validations. The registry manages a case-insensitive ASCII
strings. The string MUST follow the extensive-token syntax defined
in Section 3.
Registrations for authentication algorithms are required to include a
description of the key exchange algorithms. Reviewers assigned by
IESG are advised to examine its use-case requirements and security
consequence of its introduction.
New registrations are advised to provide the following information:
o Token: a token used in HTTP headers for identifying the algorithm.
o Description: A brief description of the algorithm.
o Specification: A reference for a specification defining the
algorithm.
The initial content of this registry is as follows:
+----------------------+----------------------------+---------------+
| Token | Description | Specification |
+----------------------+----------------------------+---------------+
| host | Host name verification | Section 7 |
| | only | |
| tls-server-end-point | TLS certificate-based | Section 7 |
| tls-unique | TLS unique key-based | Section 7 |
+----------------------+----------------------------+---------------+
17. Security Considerations 17. Security Considerations
17.1. Security Properties 17.1. Security Properties
o The protocol is secure against passive eavesdropping and replay o The protocol is secure against passive eavesdropping and replay
attacks. However, the protocol relies on transport security attacks. However, the protocol relies on transport security
including DNS integrity for data secrecy and integrity. HTTP/TLS including DNS integrity for data secrecy and integrity. HTTP/TLS
SHOULD be used where transport security is not assured and/or data SHOULD be used where transport security is not assured and/or data
confidentiality is important. confidentiality is important.
skipping to change at page 42, line 13 skipping to change at page 44, line 8
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. 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 of the server resource consumptions. For may become a critical point of the 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
reestablishes a new session then. reestablishes a new session then.
However, if a malicious client sends too many requests of key However, if a malicious client sends too many requests of key
exchanges (req-KEX-C1 messages) only, resource starvation might exchanges (req-KEX-C1 messages) only, resource starvation might
occur. In such critical situations, servers MAY discard any kind of occur. In such critical situations, servers MAY discard any kind of
existing sessions regardless of these statuses. One way to mitigate existing sessions regardless of these statuses. One way to mitigate
skipping to change at page 43, line 44 skipping to change at page 45, line 38
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"
validation method to a URI that is protected by the same realm (so validation method to a URI that is protected by the same realm (so
indicated by the path parameter), if the server certificate has indicated by the path parameter), if the server certificate has
been changed since the pages were received, the peer is been changed since the pages were received, the peer is
RECOMMENDED to be revalidated 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 steal, o For better protection against possible password database steal,
Server-side storages of user passwords are better containing the Server-side storage of user passwords are better containing the
values encrypted by one-way function J(pi), instead of the real values encrypted by one-way function J(pi), instead of the real
passwords, those hashed by ph, or pi. passwords, those hashed by ph, or pi.
17.5. Usage Considerations 17.5. Usage Considerations
o The user-names inputted by a user may be sent automatically to any o The user-names inputted by a user may be sent automatically to any
servers sharing the same auth-domain. This means that when host- servers sharing the same auth-domain. This means that when host-
type auth-domain is used for authentication on an HTTPS site, and type auth-domain 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
skipping to change at page 44, line 37 skipping to change at page 46, line 37
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, those hashed by ph, function J(pi), instead of the real passwords, those hashed by ph,
or pi. or pi.
18. Notice on Intellectual Properties 18. Notice on Intellectual Properties
The National Institute of Advanced Industrial Science and Technology The National Institute of Advanced Industrial Science and Technology
(AIST) and Yahoo! Japan, Inc. has jointly submitted a patent (AIST) and Yahoo! Japan, Inc. has jointly submitted a patent
application on the protocol proposed in this documentation to the application on the protocol proposed in this documentation to the
Patent Office of Japan. The patent is intended to be open to any Patent Office of Japan. The patent is intended to be open to any
implementors of this protocol and its variants under non-exclusive implementer of this protocol and its variants under non-exclusive
royalty-free manner. For the details of the patent application and royalty-free manner. For the details of the patent application and
its status, please contact the author of this document. its status, please contact the author of this document.
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., Hayashi, T., and Y.
Ioku, "HTTP Authentication Extensions for Interactive Ioku, "HTTP Authentication Extensions for Interactive
Clients", draft-ietf-httpauth-extension-03 (work in Clients", draft-ietf-httpauth-extension-04 (work in
progress), February 2015. progress), July 2015.
[I-D.ietf-httpbis-auth-info] [I-D.ietf-httpbis-auth-info]
Reschke, J., "The Hypertext Transfer Protocol (HTTP) Reschke, J., "The Hypertext Transfer Protocol (HTTP)
Authentication-Info and Proxy- Authentication-Info Authentication-Info and Proxy- Authentication-Info
Response Header Fields", draft-ietf-httpbis-auth-info-02 Response Header Fields", draft-ietf-httpbis-auth-info-05
(work in progress), February 2015. (work in progress), April 2015.
[I-D.ietf-precis-saslprepbis] [I-D.ietf-precis-saslprepbis]
Saint-Andre, P. and A. Melnikov, "Preparation, Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", Representing Usernames and Passwords",
draft-ietf-precis-saslprepbis-13 (work in progress), draft-ietf-precis-saslprepbis-18 (work in progress),
December 2014. May 2015.
[I-D.ietf-tls-session-hash]
Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley,
A., and M. Ray, "Transport Layer Security (TLS) Session
Hash and Extended Master Secret Extension",
draft-ietf-tls-session-hash-05 (work in progress),
April 2015.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000. Specification Version 2.0", RFC 2898, September 2000.
skipping to change at page 46, line 16 skipping to change at page 48, line 23
[RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235, June 2014. (HTTP/1.1): Authentication", RFC 7235, June 2014.
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-02 (work in progress), draft-ietf-httpauth-mutual-algo-03 (work in progress),
February 2015. July 2015.
[I-D.ietf-precis-framework]
Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols",
draft-ietf-precis-framework-22 (work in progress),
February 2015.
[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 18 skipping to change at page 49, line 18
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, July 2010. for TLS", RFC 5929, July 2010.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
December 2011. December 2011.
[RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols",
RFC 7564, May 2015.
Appendix A. (Informative) Draft Remarks from Authors Appendix A. (Informative) Draft Remarks from Authors
The following items are currently under consideration for future The following items are currently under consideration for future
revisions by the authors. revisions by the authors.
o Whether to keep TLS-unique validation or not. o Whether to keep TLS-unique validation or not.
o Whether to introduce password strengthening hashes other than o Whether to introduce password strengthening hashes other than
PBKDF2 into the function pi(). This requires standardization of PBKDF2 into the function pi(). This requires standardization of
such other hash algorithms in IETF. such other hash algorithms in IETF.
skipping to change at page 47, line 42 skipping to change at page 50, line 4
parameters as well. parameters as well.
o Whether to keep ph() function for legacy migration or not. o Whether to keep ph() function for legacy migration or not.
o Adding test vectors for ensuring implementation correctness. o Adding test vectors for ensuring implementation correctness.
o Possibly adding a method for servers to detect availability of o Possibly adding a method for servers to detect availability of
Mutual authentication on client-side. Mutual authentication on client-side.
Appendix B. (Informative) Draft Change Log Appendix B. (Informative) Draft Change Log
B.1. Changes in Httpauth WG Revision 05
B.1. Changes in Httpauth WG Revision 04 o Minimum nonce number window has increased to 128. (HTTP 2.0
recommends at least 100 concurrent sessions to exist)
o Reference to TLS session hash extension added for tls-unique
security issues.
o Comments in the previous F2F meeting has been reflected to the
text.
B.2. Changes in Httpauth WG Revision 04
o Merged httpauthprep proposal into general PRECIS Username/Password o Merged httpauthprep proposal into general PRECIS Username/Password
profile. profile.
o Adopting RFC 5987 extended syntax for non-ASCII parameter values. o Adopting RFC 5987 extended syntax for non-ASCII parameter values.
o Refer draft-ietf-httpbis-auth-info for Authentication-Info header. o Refer draft-ietf-httpbis-auth-info for Authentication-Info header.
This results in a different syntax for that header. This results in a different syntax for that header.
B.2. Changes in Httpauth WG Revision 03 B.3. Changes in Httpauth WG Revision 03
o Incompatible change: Single-port type authentication realm label o Incompatible change: Single-port type authentication realm label
has been changed to harmonize with Web Origin. (That is, the has been changed to harmonize with Web Origin. (That is, the
default ports (80 and 443) are to be omitted.) default ports (80 and 443) are to be omitted.)
B.3. Changes in Httpauth WG Revision 02 B.4. Changes in Httpauth WG Revision 02
o Major change: introduction of password-strengtheing function o Major change: introduction of password-strengthening function
PBKDF2. PBKDF2.
o Changed Section 10 to adopt "list of requirements" style. Strict o Changed Section 10 to adopt "list of requirements" style. Strict
definition of state machine is now a derived, informational definition of state machine is now a derived, informational
definition. definition.
B.4. Changes in Httpauth WG Revision 01 B.5. Changes in Httpauth WG Revision 01
o Changed "tls-key" verification to "tls-unique" verification, and o Changed "tls-key" verification to "tls-unique" verification, and
"tls-cert" to "tls-server-end-point", adopting RFC 5929. "tls-cert" to "tls-server-end-point", adopting RFC 5929.
o Adopted [I-D.ietf-precis-framework]. o Adopted PRECIS framework [RFC7564].
o Reverted reservation of "rekey-sid" and "rekey-method" parameters. o Reverted reservation of "rekey-sid" and "rekey-method" parameters.
o Degraded secure UI requirement to application note level, non- o Degraded secure UI requirement to application note level, non-
normative. normative.
o Adjusted levels of several requirements. o Adjusted levels of several requirements.
o Added warning text for handling of exceptional 5XX responses. o Added warning text for handling of exceptional 5XX responses.
o Dropped several references for optional authentications, except o Dropped several references for optional authentications, except
one "Note". one "Note".
o Several textual fixes, improvements and revisions. o Several textual fixes, improvements and revisions.
B.5. Changes in Httpauth Revision 00 B.6. Changes in Httpauth Revision 00
o Changed the version token. o Changed the version token.
o Renamed "verification tokens" to "Host verification tokens" and o Renamed "verification tokens" to "Host verification tokens" and
variables "v" to "vh" for clarification. (Back-ported from variables "v" to "vh" for clarification. (Back-ported from
draft-oiwa-httpauth-multihop-template-00) draft-oiwa-httpauth-multihop-template-00)
B.6. Changes in HttpBis Revision 00 B.7. Changes in HttpBis Revision 00
None. None.
B.7. Changes in Revision 12 B.8. Changes in Revision 12
o Added a reason "authz-failed". o Added a reason "authz-failed".
B.8. Changes in Revision 11 B.9. Changes in Revision 11
o Message syntax definition reverted to pre-07 style as httpbis-p1 o Message syntax definition reverted to pre-07 style as httpbis-p1
and p7 now defines a precise rule for parameter value parsing. and p7 now defines a precise rule for parameter value parsing.
o Replaced "stale" parameter with more infomative/extensive "reason" o Replaced "stale" parameter with more informative/extensive
parameter in 401-INIT and 401-STALE. "reason" parameter in 401-INIT and 401-STALE.
o Reserved "rekey-sid" and "rekey-method" parameters for future o Reserved "rekey-sid" and "rekey-method" parameters for future
extensions. extensions.
o Added descriptions for replacing/non-replacing existing o Added descriptions for replacing/non-replacing existing
technologies. technologies.
B.9. Changes in Revision 10 B.10. 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 50, line 18 skipping to change at page 52, line 36
+------------+----------+-------------------------------------------+ +------------+----------+-------------------------------------------+
| S_c1, S_s1 | s_a, s_b | client/server-side secret randoms | | S_c1, S_s1 | s_a, s_b | client/server-side secret randoms |
| K_c1, K_s1 | w_a, w_b | client/server-side exchanged key | | K_c1, K_s1 | w_a, w_b | client/server-side exchanged key |
| | | components | | | | components |
| kc1, ks1 | wa, wb | parameter names for those | | kc1, ks1 | wa, wb | parameter names for those |
| VK_c, VK_s | o_a, o_b | client/server-side key verifiers | | VK_c, VK_s | o_a, o_b | client/server-side key verifiers |
| vkc, vks | oa, ob | parameter names for those | | vkc, vks | oa, ob | parameter names for those |
| z | z | session secrets | | z | z | session secrets |
+------------+----------+-------------------------------------------+ +------------+----------+-------------------------------------------+
B.10. Changes in Revision 09 B.11. 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 50, line 41 skipping to change at page 53, line 20
| req-KEX-C1 | req-A1 | client->server key exchange | | req-KEX-C1 | req-A1 | client->server key exchange |
| 401-KEX-S1 | 401-B1 | server->client key exchange | | 401-KEX-S1 | 401-B1 | server->client key exchange |
| req-VFY-C | req-A3 | client->server auth. | | req-VFY-C | req-A3 | client->server auth. |
| | | verification | | | | verification |
| 200-VFY-S | 200-B4 | server->client auth. | | 200-VFY-S | 200-B4 | server->client auth. |
| | | verification | | | | verification |
| 200-Optional-INIT | 200-Optional-B0 | initial with non-mandatory | | 200-Optional-INIT | 200-Optional-B0 | initial with non-mandatory |
| | | authentication | | | | authentication |
+-------------------+-----------------+-----------------------------+ +-------------------+-----------------+-----------------------------+
B.11. Changes in Revision 08 B.12. Changes in Revision 08
o The English text has been revised. o The English text has been revised.
B.12. Changes in Revision 07 B.13. Changes in Revision 07
o Adapt to httpbis HTTP/1.1 drafts: o Adapt to httpbis HTTP/1.1 drafts:
* Changed definition of extensive-token. * Changed definition of extensive-token.
* LWSP continuation-line (%0D.0A.20) deprecated. * LWSP continuation-line (%0D.0A.20) deprecated.
o To simplify the whole spec, the type of nonce-counter related o To simplify the whole spec, the type of nonce-counter related
parameters are change from hex-integer to integer. parameters are change from hex-integer to integer.
o Algorithm tokens are renamed to include names of hash algorithms. o Algorithm tokens are renamed to include names of hash algorithms.
o Clarified the session management, added details of server-side o Clarified the session management, added details of server-side
protocol decisions. protocol decisions.
o The whole draft was reorganized; introduction and overview has o The whole draft was reorganized; introduction and overview has
been rewritten. been rewritten.
B.13. Changes in Revision 06 B.14. Changes in Revision 06
o Integrated Optional Mutual Authentication to the main part. o Integrated Optional Mutual Authentication to the main part.
o Clarified the decision procedure for message recognitions. o Clarified the decision procedure for message recognitions.
o Clarified that a new authentication request for any sub-requests o Clarified that a new authentication request for any sub-requests
in interactive clients may be silently discarded. in interactive clients may be silently discarded.
o Typos and confusing phrases are fixed. o Typos and confusing phrases are fixed.
o Several "future considerations" are added. o Several "future considerations" are added.
B.14. Changes in Revision 05 B.15. Changes in Revision 05
o A new parameter called "version" is added for supporting future o A new parameter called "version" is added for supporting future
incompatible changes with a single implementation. In the (first) incompatible changes with a single implementation. In the (first)
final specification its value will be changed to 1. final specification its value will be changed to 1.
o A new header "Authentication-Control" is added for precise control o A new header "Authentication-Control" is added for precise control
of application-level authentication behavior. of application-level authentication behavior.
B.15. Changes in Revision 04 B.16. Changes in Revision 04
o Changed text of patent licenses: the phrase "once the protocol is o Changed text of patent licenses: the phrase "once the protocol is
accepted as an Internet standard" is removed so that the sentence accepted as an Internet standard" is removed so that the sentence
also covers the draft versions of this protocol. also covers the draft versions of this protocol.
o The "tls-key" verification is now OPTIONAL. o The "tls-key" verification is now OPTIONAL.
o Several description fixes and clarifications. o Several description fixes and clarifications.
B.16. Changes in Revision 03 B.17. Changes in Revision 03
o Wildcard domain specifications (e.g. "*.example.com") are allowed o Wildcard domain specifications (e.g. "*.example.com") are allowed
for auth-domain parameters (Section 4.1). for auth-domain parameters (Section 4.1).
o Specification of the tls-cert verification is updated o Specification of the tls-cert verification is updated
(incompatible change). (incompatible change).
o State transitions fixed. o State transitions fixed.
o Requirements for servers concerning w_a values are clarified. o Requirements for servers concerning w_a values are clarified.
o RFC references are updated. o RFC references are updated.
B.17. Changes in Revision 02 B.18. Changes in Revision 02
o Auth-realm is extended to allow full-scheme type. o Auth-realm is extended to allow full-scheme type.
o A decision diagram for clients and decision procedures for servers o A decision diagram for clients and decision procedures for servers
are added. are added.
o 401-B1 and req-A3 messages are changed to contain authentication o 401-B1 and req-A3 messages are changed to contain authentication
realm information. realm information.
o Bugs on equations for o_A and o_B are fixed. o Bugs on equations for o_A and o_B are fixed.
o Detailed equations for the entire algorithm are included. o Detailed equations for the entire algorithm are included.
o Elliptic-curve algorithms are updated. o Elliptic-curve algorithms are updated.
o Several clarifications and other minor updates. o Several clarifications and other minor updates.
B.18. Changes in Revision 01 B.19. Changes in Revision 01
o Several texts are rewritten for clarification. o Several texts are rewritten for clarification.
o Added several security consideration clauses. o Added several security consideration clauses.
Authors' Addresses Authors' Addresses
Yutaka Oiwa Yutaka Oiwa
National Institute of Advanced Industrial Science and Technology National Institute of Advanced Industrial Science and Technology
Research Institute for Secure Systems Information Technology Research Institute
3-11-46 Nakouji
Tsukuba Central 2 Tsukuba Central 2
1-1-1 Umezono 1-1-1 Umezono
Tsukuba-shi, Ibaraki Tsukuba-shi, Ibaraki
JP JP
Email: mutual-auth-contact-ml@aist.go.jp Email: mutual-auth-contact-ml@aist.go.jp
Hajime Watanabe Hajime Watanabe
National Institute of Advanced Industrial Science and Technology National Institute of Advanced Industrial Science and Technology
Research Institute for Secure Systems Information Technology Research Institute
Tsukuba Central 2 Tsukuba Central 2
1-1-1 Umezono 1-1-1 Umezono
Tsukuba-shi, Ibaraki Tsukuba-shi, Ibaraki
JP JP
Hiromitsu Takagi Hiromitsu Takagi
National Institute of Advanced Industrial Science and Technology National Institute of Advanced Industrial Science and Technology
Research Institute for Secure Systems Information Technology Research Institute
Tsukuba Central 2 Tsukuba Central 2
1-1-1 Umezono 1-1-1 Umezono
Tsukuba-shi, Ibaraki Tsukuba-shi, Ibaraki
JP JP
Kaoru Maeda Kaoru Maeda
Lepidum Co. Ltd. Lepidum Co. Ltd.
Village Sasazuka 3, Suite #602 Village Sasazuka 3, Suite #602
1-30-3 Sasazuka 1-30-3 Sasazuka
Shibuya-ku, Tokyo Shibuya-ku, Tokyo
JP JP
Tatsuya Hayashi Tatsuya Hayashi
Lepidum Co. Ltd. Lepidum Co. Ltd.
Village Sasazuka 3, Suite #602 Village Sasazuka 3, Suite #602
 End of changes. 72 change blocks. 
157 lines changed or deleted 270 lines changed or added

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