draft-ietf-httpauth-mutual-01.txt   draft-ietf-httpauth-mutual-02.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: April 24, 2014 RISEC, AIST Expires: October 26, 2014 RISEC, AIST
K. Maeda
T. Hayashi T. Hayashi
Lepidum Lepidum
Y. Ioku Y. Ioku
Individual Individual
October 21, 2013 April 24, 2014
Mutual Authentication Protocol for HTTP Mutual Authentication Protocol for HTTP
draft-ietf-httpauth-mutual-01 draft-ietf-httpauth-mutual-02
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 41 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 April 24, 2014. This Internet-Draft will expire on October 26, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 40 skipping to change at page 2, line 41
4.4. req-VFY-C . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4. req-VFY-C . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5. 200-VFY-S . . . . . . . . . . . . . . . . . . . . . . . . 19 4.5. 200-VFY-S . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Authentication Realms . . . . . . . . . . . . . . . . . . . . 19 5. Authentication Realms . . . . . . . . . . . . . . . . . . . . 19
5.1. Resolving Ambiguities . . . . . . . . . . . . . . . . . . 21 5.1. Resolving Ambiguities . . . . . . . . . . . . . . . . . . 21
6. Session Management . . . . . . . . . . . . . . . . . . . . . . 22 6. Session Management . . . . . . . . . . . . . . . . . . . . . . 22
7. Host Validation Methods . . . . . . . . . . . . . . . . . . . 23 7. Host Validation Methods . . . . . . . . . . . . . . . . . . . 23
7.1. Applicability notes . . . . . . . . . . . . . . . . . . . 25 7.1. Applicability notes . . . . . . . . . . . . . . . . . . . 25
7.2. Interoperability notes on tls-unique . . . . . . . . . . . 25 7.2. Interoperability notes on tls-unique . . . . . . . . . . . 25
8. Authentication Extensions . . . . . . . . . . . . . . . . . . 26 8. Authentication Extensions . . . . . . . . . . . . . . . . . . 26
9. Decision Procedure for Clients . . . . . . . . . . . . . . . . 26 9. Decision Procedure for Clients . . . . . . . . . . . . . . . . 26
10. Decision Procedure for Servers . . . . . . . . . . . . . . . . 31 9.1. General Principles and Requirements . . . . . . . . . . . 26
11. Authentication Algorithms . . . . . . . . . . . . . . . . . . 33 9.2. State machine for the client-side . . . . . . . . . . . . 28
11.1. Support Functions and Notations . . . . . . . . . . . . . 34 10. Decision Procedure for Servers . . . . . . . . . . . . . . . . 33
11.2. Default Functions for Algorithms . . . . . . . . . . . . . 35 11. Authentication Algorithms . . . . . . . . . . . . . . . . . . 35
12. Application Channel Binding . . . . . . . . . . . . . . . . . 36 11.1. Support Functions and Notations . . . . . . . . . . . . . 36
13. Application for Proxy Authentication . . . . . . . . . . . . . 36 11.2. Default Functions for Algorithms . . . . . . . . . . . . . 37
14. Methods to Extend This Protocol . . . . . . . . . . . . . . . 37 12. Application Channel Binding . . . . . . . . . . . . . . . . . 38
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 13. Application for Proxy Authentication . . . . . . . . . . . . . 39
16. Security Considerations . . . . . . . . . . . . . . . . . . . 38 14. Methods to Extend This Protocol . . . . . . . . . . . . . . . 39
16.1. Security Properties . . . . . . . . . . . . . . . . . . . 38 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
16.2. Denial-of-service Attacks to Servers . . . . . . . . . . . 39 16. Security Considerations . . . . . . . . . . . . . . . . . . . 40
16.2.1. On-line Active Password Attacks . . . . . . . . . . . 39 16.1. Security Properties . . . . . . . . . . . . . . . . . . . 40
16.2. Denial-of-service Attacks to Servers . . . . . . . . . . . 41
16.2.1. On-line Active Password Attacks . . . . . . . . . . . 41
16.3. Communicating the status of mutual authentication with 16.3. Communicating the status of mutual authentication with
users . . . . . . . . . . . . . . . . . . . . . . . . . . 39 users . . . . . . . . . . . . . . . . . . . . . . . . . . 42
16.4. Implementation Considerations . . . . . . . . . . . . . . 40 16.4. Implementation Considerations . . . . . . . . . . . . . . 42
16.5. Usage Considerations . . . . . . . . . . . . . . . . . . . 41 16.5. Usage Considerations . . . . . . . . . . . . . . . . . . . 43
17. Notice on Intellectual Properties . . . . . . . . . . . . . . 41 17. Notice on Intellectual Properties . . . . . . . . . . . . . . 43
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
18.1. Normative References . . . . . . . . . . . . . . . . . . . 42 18.1. Normative References . . . . . . . . . . . . . . . . . . . 44
18.2. Informative References . . . . . . . . . . . . . . . . . . 42 18.2. Informative References . . . . . . . . . . . . . . . . . . 45
Appendix A. (Informative) Draft Remarks from Authors . . . . . . 44 Appendix A. (Informative) Draft Remarks from Authors . . . . . . 46
Appendix B. (Informative) Draft Change Log . . . . . . . . . . . 44 Appendix B. (Informative) Draft Change Log . . . . . . . . . . . 46
B.1. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 44 B.1. Changes in Httpauth WG Revision 02 . . . . . . . . . . . . 46
B.2. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 44 B.2. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 46
B.3. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 45 B.3. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 47
B.4. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 45 B.4. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 47
B.5. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 45 B.5. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 47
B.6. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 45 B.6. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 47
B.7. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 46 B.7. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 47
B.8. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 46 B.8. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 48
B.9. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 46 B.9. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 49
B.10. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 47 B.10. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 49
B.11. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 47 B.11. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 49
B.12. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 47 B.12. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 50
B.13. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 48 B.13. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 50
B.14. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 48 B.14. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 50
B.15. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 48 B.15. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 B.16. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
This document specifies a mutual authentication method for Hyper-Text This document specifies a mutual authentication method for Hyper-Text
Transfer Protocol (HTTP). The method, called "Mutual Authentication Transfer Protocol (HTTP). The method, called "Mutual Authentication
Protocol" in this document, provides a true mutual authentication Protocol" in this document, provides a true mutual authentication
between an HTTP client and an HTTP server, using just a simple between an HTTP client and an HTTP server, using just a simple
password as a credential. password as a credential.
The authentication method proposed in this document has the following The authentication method proposed in this document has the following
skipping to change at page 14, line 33 skipping to change at page 14, line 33
They MUST NOT contain any "kc*" and "vkc" parameters. They MUST NOT contain any "kc*" and "vkc" parameters.
o For requests, the parameters "kc*" (where * stands for any decimal o For requests, the parameters "kc*" (where * stands for any decimal
integers), and "vkc" are mutually exclusive and any challenge integers), and "vkc" are mutually exclusive and any challenge
MUST NOT contain two or more parameters among them. They MUST NOT MUST NOT contain two or more parameters among them. They MUST NOT
contain any "ks*" and "vks" parameters. contain any "ks*" and "vks" parameters.
Every message in this section contains a "version" field, to detect Every message in this section contains a "version" field, to detect
future incompatible revisions of the protocol. Implementations of future incompatible revisions of the protocol. Implementations of
the protocol described in this specification MUST always send a token the protocol described in this specification MUST always send a token
"-wg-draft01", and recipients MUST reject messages which contain any "-wg-draft02", and recipients MUST reject messages which contain any
other value as a version, unless another specification defines a other value as a version, unless another specification defines a
behavior for that version. [[Editorial Note: This token is updated behavior for that version. [[Editorial Note: This token is updated
on every draft revisions which will affect the wire protocol. It on every draft revisions which will affect the wire protocol. It
will (shall) be updated to "1" in the final published RFC.]] will (shall) be updated to "1" in the final published RFC.]]
4.1. 401-INIT and 401-STALE 4.1. 401-INIT and 401-STALE
Every 401-INIT or 401-STALE message SHALL be a valid HTTP 401-status Every 401-INIT or 401-STALE message SHALL be a valid HTTP 401-status
(Authentication Required) message containing one (and only one: (Authentication Required) message containing one (and only one:
hereafter not explicitly noticed) "WWW-Authenticate" header hereafter not explicitly noticed) "WWW-Authenticate" header
containing a "reason" parameter in the challenge. The challenge containing a "reason" parameter in the challenge. The challenge
SHALL contain all of the parameters marked "mandatory" below, and MAY SHALL contain all of the parameters marked "mandatory" below, and MAY
contain those marked "non-mandatory". contain those marked "non-mandatory".
version: (mandatory extensive-token) should be the token "-wg- version: (mandatory extensive-token) should be the token "-wg-
draft01". draft02".
algorithm: (mandatory extensive-token) specifies the algorithm: (mandatory extensive-token) specifies the
authentication algorithm to be used. The value MUST authentication algorithm to be used. The value MUST
be one of the tokens specified in be one of the tokens specified in
[I-D.oiwa-httpauth-mutual-algo] or other supplemental [I-D.oiwa-httpauth-mutual-algo] or other supplemental
specification documentation. specification documentation.
validation: (mandatory extensive-token) specifies the method of validation: (mandatory extensive-token) specifies the method of
host validation. The value MUST be one of the tokens host validation. The value MUST be one of the tokens
described in Section 7, or the tokens specified in described in Section 7, or the tokens specified in
skipping to change at page 17, line 21 skipping to change at page 17, line 21
4.2. req-KEX-C1 4.2. req-KEX-C1
Every req-KEX-C1 message SHALL be a valid HTTP request message Every req-KEX-C1 message SHALL be a valid HTTP request message
containing an "Authorization" header with a credential containing a containing an "Authorization" header with a credential containing a
"kc1" parameter. "kc1" parameter.
The credential SHALL contain the parameters with the following names: The credential SHALL contain the parameters with the following names:
version: (mandatory, extensive-token) should be the token "-wg- version: (mandatory, extensive-token) should be the token "-wg-
draft01". draft02".
algorithm, validation, auth-domain, realm: MUST be the same value as algorithm, validation, auth-domain, realm: MUST be the same value as
it is when received from the server. it is when received from the server.
user: (mandatory, string) is the UTF-8 encoded name of the user: (mandatory, string) is the UTF-8 encoded name of the
user. If this name comes from a user input, client user. If this name comes from a user input, client
software SHOULD prepare the string using HTTPAUTHprep software SHOULD prepare the string using HTTPAUTHprep
[I-D.oiwa-precis-httpauthprep] before encoding it to [I-D.oiwa-precis-httpauthprep] before encoding it to
UTF-8. [[Editorial: merger with new SASLprep is being UTF-8. [[Editorial: merger with new SASLprep is being
considered and discussed in precis WG. Replace the considered and discussed in precis WG. Replace the
skipping to change at page 17, line 48 skipping to change at page 17, line 48
4.3. 401-KEX-S1 4.3. 401-KEX-S1
Every 401-KEX-S1 message SHALL be a valid HTTP 401-status Every 401-KEX-S1 message SHALL be a valid HTTP 401-status
(Authentication Required) response message containing a (Authentication Required) response message containing a
"WWW-Authenticate" header with a challenge containing a "ks1" "WWW-Authenticate" header with a challenge containing a "ks1"
parameter. parameter.
The challenge SHALL contain the parameters with the following names: The challenge SHALL contain the parameters with the following names:
version: (mandatory, extensive-token) should be the token "-wg- version: (mandatory, extensive-token) should be the token "-wg-
draft01". draft02".
algorithm, validation, auth-domain, realm: MUST be the same value as algorithm, validation, auth-domain, realm: MUST be the same value as
it is when received from the client. it is when received from the client.
sid: (mandatory, hex-fixed-number) MUST be a session sid: (mandatory, hex-fixed-number) MUST be a session
identifier, which is a random integer. The sid SHOULD identifier, which is a random integer. The sid SHOULD
have uniqueness of at least 80 bits or the square of have uniqueness of at least 80 bits or the square of
the maximal estimated transactions concurrently the maximal estimated transactions concurrently
available in the session table, whichever is larger. available in the session table, whichever is larger.
See Section 6 for more details. See Section 6 for more details.
skipping to change at page 19, line 6 skipping to change at page 19, line 6
4.4. req-VFY-C 4.4. req-VFY-C
Every req-VFY-C message SHALL be a valid HTTP request message Every req-VFY-C message SHALL be a valid HTTP request message
containing an "Authorization" header with a credential containing a containing an "Authorization" header with a credential containing a
"vkc" parameter. "vkc" parameter.
The parameters contained in the header are as follows: The parameters contained in the header are as follows:
version: (mandatory, extensive-token) should be the token "-wg- version: (mandatory, extensive-token) should be the token "-wg-
draft01". draft02".
algorithm, validation, auth-domain, realm: MUST be the same value as algorithm, validation, auth-domain, realm: MUST be the same value as
it is when received from the server for the session. it is when received from the server for the session.
sid: (mandatory, hex-fixed-number) MUST be one of the sid sid: (mandatory, hex-fixed-number) MUST be one of the sid
values that was received from the server for the same values that was received from the server for the same
authentication realm. authentication realm.
nc: (mandatory, integer) is a nonce value that is unique nc: (mandatory, integer) is a nonce value that is unique
among the requests sharing the same sid. The values among the requests sharing the same sid. The values
skipping to change at page 19, line 33 skipping to change at page 19, line 33
4.5. 200-VFY-S 4.5. 200-VFY-S
Every 200-VFY-S message SHALL be a valid HTTP message that is not of Every 200-VFY-S message SHALL be a valid HTTP message that is not of
the 401 (Authentication Required) status, containing an the 401 (Authentication Required) status, containing an
"Authentication-Info" header with a "vks" parameter. "Authentication-Info" header with a "vks" parameter.
The parameters contained in the header are as follows: The parameters contained in the header are as follows:
version: (mandatory, extensive-token) should be the token "-wg- version: (mandatory, extensive-token) should be the token "-wg-
draft01". draft02".
sid: (mandatory, hex-fixed-number) MUST be the value sid: (mandatory, hex-fixed-number) MUST be the value
received from the client. received from the client.
vks: (mandatory, algorithm-determined) is the server-side vks: (mandatory, algorithm-determined) is the server-side
authentication verification value VK_s, which is authentication verification value VK_s, which is
specified by the algorithm. specified by the algorithm.
The header MUST be sent before the content body: it MUST NOT be sent The header MUST be sent before the content body: it MUST NOT be sent
in the trailer of a chunked-encoded response. If a "100 Continue" in the trailer of a chunked-encoded response. If a "100 Continue"
skipping to change at page 26, line 35 skipping to change at page 26, line 35
consider the security impacts of the behaviors of clients that do not consider the security impacts of the behaviors of clients that do not
support these headers. support these headers.
Authentication-initializing messages with the Authentication-initializing messages with the
Optional-WWW-Authenticate header are used only where 401-INIT Optional-WWW-Authenticate header are used only where 401-INIT
response is valid. It will not replace other 401-type messages such response is valid. It will not replace other 401-type messages such
as 401-STALE and 401-KEX-S1. as 401-STALE and 401-KEX-S1.
9. Decision Procedure for Clients 9. Decision Procedure for Clients
9.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.
Clients SHOULD implement a decision procedure equivalent to the one As usual in the HTTP authentication, a single user-level request may
shown below. (Unless implementers understand what is required for result in exchange of two-or-more HTTP requests and responses in
the security, they should not alter this.) In particular, clients sequence. The following care MUST be taken by the all clients
SHOULD NOT accept "normal responses" unless explicitly allowed below. implementing this protocol:
The labels on the steps are for informational purposes only. Action
entries within each step are checked in top-to-bottom order, and the o Any kinds of "normal responses" MUST only be accepted for the very
first clause satisfied SHOULD be taken. first request in the sequence. Any "normal responses" returned
for the second or later request in the sequence SHALL be
considered invalid.
o In the same principle, any responses which refer to, or request
changing to, the authentication realm different from the client's
request MUST only be accepted for the very first request in the
sequence. Any kind of responses referring to the different realms
which are returned for the second or 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
a response to 401-INIT, and 401-STALE. However, it SHOULD NOT be
sent more than once in the sequence for a single authentication
realm, to avoid infinite loops of messages. A 401-KEX-S1 response
MUST be accepted only when the corresponding request is
req-KEX-C1.
o A req-VFY-C message MAY be sent if there is a valid session key
shared between the client and the server, established by
req-KEX-C1 and 401-KEX-S1. If any response with 401 status is
returned for such a message, the corresponding session key SHOULD
be discarded as unusable.
Especially, upon the reception of response 401-STALE, the client
SHOULD try establishing a new session by sending req-KEX-C1, but
only once within the request/response sequence.
o A 200-VFY-S message MUST be accepted only as a response to
req-VFY-C and nothing else. The VK_s field of such response
message MUST always be checked against the correct value, and if
it is incorrect, the whole response SHOULD be considered invalid.
Any content, both the content body and the headers, of such an
invalid response SHOULD be ignored and discarded.
The final status of the client request following the message exchange
sequence shall be determined as follows:
o AUTH-SUCCEED: A 200-VFY-S message with the correct VK_s value is
returned to the req-VFY-C request in the sequence.
o AUTH-REQUIRED: Two cases exists.
* A 401-INIT message is returned from the server, and the client
does not know how to authenticate to the given authentication
realm.
* A 401-INIT response is returned for req-VFY-C (or req-KEX-C1),
which means the user-supplied authentication credentials are
not accepted.
o UNAUTHENTICATED: a normal response is returned for an initial
request of any kind in the sequence.
Any kind of response (including a normal response) other than those
explicitly allowed in the above rules SHOULD be interpreted as a
fatal communication error. In such cases, the clients MUST NOT
process any data (the response body and other content-related
headers) sent from the server. However, to handle exceptional error
cases, clients MAY accept a message without an Authentication-Info
header, if it is a Server-Error (5xx) status. In such cases, they
SHOULD be careful about processing the body of the content (ignoring
it is still RECOMMENDED, as it may possibly be forged by intermediate
attackers,) and the client will be in the "UNAUTHENTICATED" status
then.
If a request is a sub-request for a resource included in another
resources (e.g., embedded images, style sheets, frames etc.), clients
MAY treat an AUTH-REQUESTED status as the same as UNAUTHENTICATED
status. In other words, the client MAY ignore server's request to
start authentication with new credentials via sub-requests.
9.2. State machine for the client-side
The following state machine describes the possible request-response
sequences derived from the above general rules. If implementors are
not quite sure on the security consequences of the above rules, it is
strongly RECOMMENDED to follow the decision procedure below. In
particular, clients SHOULD NOT accept "normal responses" unless
explicitly allowed in the rules. The labels on the steps are for
informational purposes only. Action entries within each step are
checked in top-to-bottom order, and the first clause satisfied SHOULD
be taken.
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 29, line 27 skipping to change at page 31, line 12
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.
Any kind of response (including a normal response) other than those
shown in the above procedure SHOULD be interpreted as a fatal
communication error, and in such cases the clients MUST NOT process
any data (response body and other content-related headers) sent from
the server. However, to handle exceptional error cases, clients MAY
accept a message without an Authentication-Info header, if it is a
Server-Error (5xx) status. In such cases, they SHOULD be careful
about processing the body of the content (ignoring it is still
RECOMMENDED), and the client will be in the "UNAUTHENTICATED" status
then.
If a request is a sub-request for a resource included in another
resources (e.g., embedded images, style sheets, frames etc.), clients
MAY treat an AUTH-REQUESTED status as the same as UNAUTHENTICATED
status. In other words, the client MAY ignore server's request to
start authentication with new credentials via sub-requests.
Figure 5 shows a diagram of the client-side state. Figure 5 shows a 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 34, line 5 skipping to change at page 36, line 5
o The server-side authentication credential J, derived from user- o The server-side authentication credential J, derived from user-
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 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. o A hash function H to be used with the protocol, along with its
output size hSize.
o The number of iteration for password hasing nIterPi, if it uses
the default password hashing function defined below.
Specifications for cryptographic algorithms used with this framework
MUST specify whether these will use the default functions defined
below for the functions pi, VK_c, and VK_s; or, these will define
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
to or stronger than the hash function H. If any passwords (or pass- to or stronger than the hash function H. If any passwords (or pass-
phrases or any equivalents, i.e. weak secrets) are involved, these phrases or any equivalents, i.e. weak secrets) are involved, these
SHOULD NOT be guessable from any data transmitted in the protocol, SHOULD NOT be guessable from any data transmitted in the protocol,
even if an attacker (either an eavesdropper or an active server) even if an attacker (either an eavesdropper or an active server)
knows the possible thoroughly-searchable candidate list of the knows the possible thoroughly-searchable candidate list of the
passwords. Furthermore, if possible, the function for deriving passwords. Furthermore, if possible, the function for deriving
skipping to change at page 35, line 43 skipping to change at page 37, line 50
n. n.
11.2. Default Functions for Algorithms 11.2. Default Functions for Algorithms
The functions defined in this section are common default functions The functions defined in this section are common default functions
among authentication algorithms. among authentication algorithms.
The client-side password-based (credential) pi used by this The client-side password-based (credential) pi used by this
authentication is a natural number derived in the following manner: authentication is a natural number derived in the following manner:
pi = INT(H(VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username) pi = INT(PBKDF2(HMAC_H, ph(password), VS(algorithm) | VS(auth-domain)
| VS(ph(password)))). | VS(realm) | VS(username), nIterPi, hSize / 8)),
where
o PBKDF2 is the password-based key derivation function defined in
[RFC2898],
o HMAC_H is the HMAC function, defined in [RFC2104], composed from
the hash function H, and
o hSize is the output size of hash H, counted in bits.
The values of algorithm, realm, and auth-domain are taken from the The values of algorithm, realm, and auth-domain are taken from the
values contained in the 401-INIT message. The function ph is values contained in the 401-INIT message. The function ph is
determined by the value of the pwd-hash parameter given in a 401-INIT determined by the value of the pwd-hash parameter given in a 401-INIT
message. If the password comes from a user input, it SHOULD first be message. If the password comes from a user input, it SHOULD first be
prepared using I-D.oiwa-precis-httpauthprep [RFC4013]. Then, the prepared using [I-D.oiwa-precis-httpauthprep]. Then, the password
password SHALL be encoded as a UTF-8 string before passed to ph. SHALL be encoded as a UTF-8 string before passed to ph.
The values VK_c and VK_s are derived by the following equation. The values VK_c and VK_s are derived by the following equation.
VK_c = INT(H(octet(4) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VK_c = INT(H(octet(4) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) |
VI(nc) | VS(vh))) VI(nc) | VS(vh)))
VK_s = INT(H(octet(3) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) | VK_s = INT(H(octet(3) | OCTETS(K_c1) | OCTETS(K_s1) | OCTETS(z) |
VI(nc) | VS(vh))) VI(nc) | VS(vh)))
Specifications for cryptographic algorithms used with this framework
MAY override the functions pi, VK_c, and VK_s defined above. In such
cases implementations MUST use the ones defined with such algorithm
specifications.
12. Application Channel Binding 12. Application Channel Binding
Applications and upper-layer communication protocols may need Applications and upper-layer communication protocols may need
authentication binding to the HTTP-layer authenticated user. Such authentication binding to the HTTP-layer authenticated user. Such
applications MAY use the following values as a standard shared applications MAY use the following values as a standard shared
secret. secret.
These values are parameterized with an optional octet string (t) These values are parameterized with an optional octet string (t)
which may be arbitrarily chosen by each applications or protocols. which may be arbitrarily chosen by each applications or protocols.
If there is no appropriate value to be specified, use a null string If there is no appropriate value to be specified, use a null string
skipping to change at page 42, line 15 skipping to change at page 44, line 15
[I-D.ietf-httpauth-extension] [I-D.ietf-httpauth-extension]
Oiwa, Y., Watanabe, H., Takagi, H., Hayashi, T., and Y. Oiwa, Y., Watanabe, H., Takagi, H., Hayashi, T., and Y.
Ioku, "HTTP Authentication Extensions for Interactive Ioku, "HTTP Authentication Extensions for Interactive
Clients", draft-ietf-httpauth-extension-01 (work in Clients", draft-ietf-httpauth-extension-01 (work in
progress), October 2013. progress), October 2013.
[I-D.ietf-httpbis-p1-messaging] [I-D.ietf-httpbis-p1-messaging]
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", (HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-24 (work in progress), draft-ietf-httpbis-p1-messaging-26 (work in progress),
September 2013. February 2014.
[I-D.ietf-httpbis-p7-auth] [I-D.ietf-httpbis-p7-auth]
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-24 (HTTP/1.1): Authentication", draft-ietf-httpbis-p7-auth-26
(work in progress), September 2013. (work in progress), February 2014.
[I-D.oiwa-precis-httpauthprep] [I-D.oiwa-precis-httpauthprep]
Oiwa, Y., NEMOTO, T., and B. Kihara, "HTTPAuthPrep: PRECIS Oiwa, Y., Nemoto, T., and B. Kihara, "HTTPAuthPrep: PRECIS
profile for HTTP Authentication", profile for HTTP Authentication",
draft-oiwa-precis-httpauthprep-00 (work in progress), draft-oiwa-precis-httpauthprep-00 (work in progress),
July 2013. July 2013.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
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
Specification Version 2.0", RFC 2898, September 2000.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, February 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
18.2. Informative References 18.2. Informative References
[I-D.ietf-precis-framework] [I-D.ietf-precis-framework]
Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation and Comparison of Internationalized Strings in Preparation and Comparison of Internationalized Strings in
Application Protocols", draft-ietf-precis-framework-11 Application Protocols", draft-ietf-precis-framework-16
(work in progress), October 2013. (work in progress), April 2014.
[I-D.oiwa-httpauth-mutual-algo] [I-D.oiwa-httpauth-mutual-algo]
Oiwa, Y., Watanabe, H., Takagi, H., Hayashi, T., and Y. Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi,
Ioku, "Mutual Authentication Protocol for HTTP: KAM3-based T., and Y. Ioku, "Mutual Authentication Protocol for HTTP:
Cryptographic Algorithms", KAM3-based Cryptographic Algorithms",
draft-oiwa-httpauth-mutual-algo-01 (work in progress), draft-oiwa-httpauth-mutual-algo-02 (work in progress),
October 2013. April 2014.
[ISO.10646-1.1993] [ISO.10646-1.1993]
International Organization for Standardization, International Organization for Standardization,
"Information Technology - Universal Multiple-octet coded "Information Technology - Universal Multiple-octet coded
Character Set (UCS) - Part 1: Architecture and Basic Character Set (UCS) - Part 1: Architecture and Basic
Multilingual Plane", ISO Standard 10646-1, May 1993. Multilingual Plane", ISO Standard 10646-1, May 1993.
[ITU.X690.1994] [ITU.X690.1994]
International Telecommunications Union, "Information International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic Technology - ASN.1 encoding rules: Specification of Basic
skipping to change at page 44, line 12 skipping to change at page 46, line 15
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
Appendix A. (Informative) Draft Remarks from Authors Appendix A. (Informative) Draft Remarks from Authors
The following items are currently under consideration for future The following items are currently under consideration for future
revisions by the authors. revisions by the authors.
o Whether to keep TLS-unique validation or not. o Whether to keep TLS-unique validation or not.
o Whether to introduce PBKDF2 or similar password strengthening o Whether to introduce password strengthening hashes other than
hashes into the function pi(). PBKDF2 into the function pi(). This requires standardization of
such other hash algorithms in IETF.
o Whether to modify current definition of nIterPi, which is per-
algorithm defined. To increase this parameter requires defining a
new algorithm, possibly with reconsideration for other security
parameters as well.
o Whether to keep ph() function for legacy migration or not. 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 01 B.1. Changes in Httpauth WG Revision 02
o Major change: introduction of password-strengtheing function
PBKDF2.
o Changed Section 9 to adopt "list of requirements" style. Strict
definition of state machine is now a derived, informational
definition.
B.2. Changes in Httpauth WG Revision 01
o Changed "tls-key" verification to "tls-unique" verification, and o Changed "tls-key" verification to "tls-unique" verification, and
"tls-cert" to "tls-server-end-point", adopting RFC 5929. "tls-cert" to "tls-server-end-point", adopting RFC 5929.
o Adopted [I-D.ietf-precis-framework]. o Adopted [I-D.ietf-precis-framework].
o Reverted reservation of "rekey-sid" and "rekey-method" parameters. o Reverted reservation of "rekey-sid" and "rekey-method" parameters.
o Degraded secure UI requirement to application note level, non- o Degraded secure UI requirement to application note level, non-
normative. normative.
o Adjusted levels of several requirements. o Adjusted levels of several requirements.
o Added warning text for handling of exceptional 5XX responses. o Added warning text for handling of exceptional 5XX responses.
o Dropped several references for optional authentications, except o Dropped several references for optional authentications, except
one "Note". one "Note".
o Several textual fixes, improvements and revisions. o Several textual fixes, improvements and revisions.
B.2. Changes in Httpauth Revision 00 B.3. 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.3. Changes in HttpBis Revision 00 B.4. Changes in HttpBis Revision 00
None. None.
B.4. Changes in Revision 12 B.5. Changes in Revision 12
o Added a reason "authz-failed". o Added a reason "authz-failed".
B.5. Changes in Revision 11 B.6. Changes in Revision 11
o Message syntax definition reverted to pre-07 style as httpbis-p1 o Message syntax definition reverted to pre-07 style as httpbis-p1
and p7 now defines a precise rule for parameter value parsing. and p7 now defines a precise rule for parameter value parsing.
o Replaced "stale" parameter with more infomative/extensive "reason" o Replaced "stale" parameter with more infomative/extensive "reason"
parameter in 401-INIT and 401-STALE. parameter in 401-INIT and 401-STALE.
o Reserved "rekey-sid" and "rekey-method" parameters for future o Reserved "rekey-sid" and "rekey-method" parameters for future
extensions. extensions.
o Added descriptions for replacing/non-replacing existing o Added descriptions for replacing/non-replacing existing
technologies. technologies.
B.6. Changes in Revision 10 B.7. 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 46, line 18 skipping to change at page 48, line 40
+------------+----------+-------------------------------------------+ +------------+----------+-------------------------------------------+
| S_c1, S_s1 | s_a, s_b | client/server-side secret randoms | | S_c1, S_s1 | s_a, s_b | client/server-side secret randoms |
| K_c1, K_s1 | w_a, w_b | client/server-side exchanged key | | K_c1, K_s1 | w_a, w_b | client/server-side exchanged key |
| | | components | | | | components |
| kc1, ks1 | wa, wb | parameter names for those | | kc1, ks1 | wa, wb | parameter names for those |
| VK_c, VK_s | o_a, o_b | client/server-side key verifiers | | VK_c, VK_s | o_a, o_b | client/server-side key verifiers |
| vkc, vks | oa, ob | parameter names for those | | vkc, vks | oa, ob | parameter names for those |
| z | z | session secrets | | z | z | session secrets |
+------------+----------+-------------------------------------------+ +------------+----------+-------------------------------------------+
B.7. Changes in Revision 09 B.8. 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 46, line 41 skipping to change at page 49, 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.8. Changes in Revision 08 B.9. Changes in Revision 08
o The English text has been revised. o The English text has been revised.
B.9. Changes in Revision 07 B.10. 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.10. Changes in Revision 06 B.11. 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.11. Changes in Revision 05 B.12. 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.12. Changes in Revision 04 B.13. 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.13. Changes in Revision 03 B.14. 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.14. Changes in Revision 02 B.15. 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.15. Changes in Revision 01 B.16. Changes in Revision 01
o Several texts are rewritten for clarification. o Several texts are rewritten for clarification.
o Added several security consideration clauses. o Added several security consideration clauses.
Authors' Addresses Authors' Addresses
Yutaka Oiwa Yutaka Oiwa
National Institute of Advanced Industrial Science and Technology National Institute of Advanced Industrial Science and Technology
Research Institute for Secure Systems Research Institute for Secure Systems
skipping to change at page 49, line 31 skipping to change at page 52, line 4
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 Research Institute for Secure Systems
Tsukuba Central 2 Tsukuba Central 2
1-1-1 Umezono 1-1-1 Umezono
Tsukuba-shi, Ibaraki Tsukuba-shi, Ibaraki
JP JP
Kaoru Maeda
Lepidum Co. Ltd.
#602, Village Sasazuka 3
1-30-3 Sasazuka
Shibuya-ku, Tokyo
JP
Tatsuya Hayashi Tatsuya Hayashi
Lepidum Co. Ltd. Lepidum Co. Ltd.
#602, Village Sasazuka 3 #602, Village Sasazuka 3
1-30-3 Sasazuka 1-30-3 Sasazuka
Shibuya-ku, Tokyo Shibuya-ku, Tokyo
JP JP
Yuichi Ioku Yuichi Ioku
Individual Individual
 End of changes. 45 change blocks. 
114 lines changed or deleted 222 lines changed or added

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