draft-ietf-httpauth-mutual-09.txt   draft-ietf-httpauth-mutual-10.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: February 18, 2017 ITRI, AIST Expires: March 26, 2017 ITRI, AIST
K. Maeda K. Maeda
T. Hayashi T. Hayashi
Lepidum Lepidum
Y. Ioku Y. Ioku
Individual Individual
August 17, 2016 September 22, 2016
Mutual Authentication Protocol for HTTP Mutual Authentication Protocol for HTTP
draft-ietf-httpauth-mutual-09 draft-ietf-httpauth-mutual-10
Abstract Abstract
This document specifies a mutual authentication scheme for the This document specifies a mutual authentication scheme for the
Hypertext Transfer Protocol (HTTP). This scheme provides true mutual Hypertext Transfer Protocol (HTTP). This scheme provides true mutual
authentication between an HTTP client and an HTTP server using authentication between an HTTP client and an HTTP server using
password-based authentication. Unlike the Basic and Digest password-based authentication. Unlike the Basic and Digest
authentication schemes, the Mutual authentication scheme specified in authentication schemes, the Mutual authentication scheme specified in
this document assures the user that the server truly knows the user's this document assures the user that the server truly knows the user's
encrypted password. encrypted password.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 18, 2017. This Internet-Draft will expire on March 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 21 skipping to change at page 3, line 21
17.2.1. On-line Active Password Attacks . . . . . . . . . . . 45 17.2.1. On-line Active Password Attacks . . . . . . . . . . . 45
17.3. Communicating the status of mutual authentication with 17.3. Communicating the status of mutual authentication with
users . . . . . . . . . . . . . . . . . . . . . . . . . . 45 users . . . . . . . . . . . . . . . . . . . . . . . . . . 45
17.4. Implementation Considerations . . . . . . . . . . . . . . 45 17.4. Implementation Considerations . . . . . . . . . . . . . . 45
17.5. Usage Considerations . . . . . . . . . . . . . . . . . . . 46 17.5. Usage Considerations . . . . . . . . . . . . . . . . . . . 46
18. Notice on Intellectual Properties . . . . . . . . . . . . . . 46 18. Notice on Intellectual Properties . . . . . . . . . . . . . . 46
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
19.1. Normative References . . . . . . . . . . . . . . . . . . . 47 19.1. Normative References . . . . . . . . . . . . . . . . . . . 47
19.2. Informative References . . . . . . . . . . . . . . . . . . 48 19.2. Informative References . . . . . . . . . . . . . . . . . . 48
Appendix A. (Informative) Draft Change Log . . . . . . . . . . . 50 Appendix A. (Informative) Draft Change Log . . . . . . . . . . . 50
A.1. Changes in Httpauth WG Revision 09 . . . . . . . . . . . . 50 A.1. Changes in Httpauth WG Revision 10 . . . . . . . . . . . . 50
A.2. Changes in Httpauth WG Revision 08 . . . . . . . . . . . . 50 A.2. Changes in Httpauth WG Revision 09 . . . . . . . . . . . . 50
A.3. Changes in Httpauth WG Revision 07 . . . . . . . . . . . . 50 A.3. Changes in Httpauth WG Revision 08 . . . . . . . . . . . . 50
A.4. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 50 A.4. Changes in Httpauth WG Revision 07 . . . . . . . . . . . . 50
A.5. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 50 A.5. Changes in Httpauth WG Revision 06 . . . . . . . . . . . . 50
A.6. Changes in Httpauth WG Revision 04 . . . . . . . . . . . . 51 A.6. Changes in Httpauth WG Revision 05 . . . . . . . . . . . . 51
A.7. Changes in Httpauth WG Revision 03 . . . . . . . . . . . . 51 A.7. Changes in Httpauth WG Revision 04 . . . . . . . . . . . . 51
A.8. Changes in Httpauth WG Revision 02 . . . . . . . . . . . . 51 A.8. Changes in Httpauth WG Revision 03 . . . . . . . . . . . . 51
A.9. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 51 A.9. Changes in Httpauth WG Revision 02 . . . . . . . . . . . . 51
A.10. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 52 A.10. Changes in Httpauth WG Revision 01 . . . . . . . . . . . . 51
A.11. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 52 A.11. Changes in Httpauth Revision 00 . . . . . . . . . . . . . 52
A.12. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 52 A.12. Changes in HttpBis Revision 00 . . . . . . . . . . . . . . 52
A.13. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 52 A.13. Changes in Revision 12 . . . . . . . . . . . . . . . . . . 52
A.14. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 52 A.14. Changes in Revision 11 . . . . . . . . . . . . . . . . . . 52
A.15. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 53 A.15. Changes in Revision 10 . . . . . . . . . . . . . . . . . . 52
A.16. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 54 A.16. Changes in Revision 09 . . . . . . . . . . . . . . . . . . 53
A.17. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 54 A.17. Changes in Revision 08 . . . . . . . . . . . . . . . . . . 54
A.18. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 54 A.18. Changes in Revision 07 . . . . . . . . . . . . . . . . . . 54
A.19. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 54 A.19. Changes in Revision 06 . . . . . . . . . . . . . . . . . . 54
A.20. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 55 A.20. Changes in Revision 05 . . . . . . . . . . . . . . . . . . 55
A.21. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 55 A.21. Changes in Revision 04 . . . . . . . . . . . . . . . . . . 55
A.22. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 55 A.22. Changes in Revision 03 . . . . . . . . . . . . . . . . . . 55
A.23. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 55 A.23. Changes in Revision 02 . . . . . . . . . . . . . . . . . . 55
A.24. Changes in Revision 01 . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
This document specifies a mutual authentication scheme for Hypertext This document specifies a mutual authentication scheme for Hypertext
Transfer Protocol (HTTP). The scheme, called "Mutual Authentication Transfer Protocol (HTTP). The scheme, called "Mutual Authentication
Protocol" in this document, provides true mutual authentication Protocol" in this document, provides true mutual authentication
between an HTTP client and an HTTP server, using just a simple between an HTTP client and an HTTP server, using just a simple
password as a credential. password as a credential.
skipping to change at page 13, line 26 skipping to change at page 13, line 26
values. Recipients SHOULD accept both quoted and unquoted values. Recipients SHOULD accept both quoted and unquoted
representations interchangeably as specified in HTTP. representations interchangeably as specified in HTTP.
3.2.1. Tokens 3.2.1. Tokens
For sustaining both security and extensibility at the same time, this For sustaining both security and extensibility at the same time, this
protocol defines a stricter sub-syntax for the "token" to be used. protocol defines a stricter sub-syntax for the "token" to be used.
Extensive-token values SHOULD use the following syntax (after HTTP Extensive-token values SHOULD use the following syntax (after HTTP
value parsing): value parsing):
bare-token = 1*(DIGIT / ALPHA / "-" / "_") bare-token = bare-token-lead-char *bare-token-char
extension-token = "-" bare-token 1*("." bare-token) bare-token-lead-char = %x30-39 / %x41-5A / %x61-7A
extensive-token = bare-token / extension-token bare-token-char = %x30-39 / %x41-5A / %x61-7A / "-" / "_"
extension-token = "-" bare-token 1*("." bare-token)
extensive-token = bare-token / extension-token
Figure 3: BNF syntax for token values Figure 3: BNF syntax for token values
The tokens (bare-token and extension-token) are case insensitive; The tokens (bare-token and extension-token) are case insensitive;
Senders SHOULD send these in lower case, and receivers MUST accept Senders SHOULD send these in lower case, and receivers MUST accept
both upper and lower cases. When tokens are used as (partial) inputs both upper and lower cases. When tokens are used as (partial) inputs
to any hash or other mathematical functions, they MUST always be used to any hash or other mathematical functions, they MUST always be used
in lower case. in lower case.
Extensive-tokens are used in this protocol where the set of Extensive-tokens are used in this protocol where the set of
skipping to change at page 25, line 31 skipping to change at page 25, line 31
itself to another server as a valid user by forwarding the received itself to another server as a valid user by forwarding the received
credentials. credentials.
The valid tokens for the validation parameter and corresponding The valid tokens for the validation parameter and corresponding
values of vh are as follows: values of vh are as follows:
host: host-name validation: The value vh will be the ASCII host: host-name validation: The value vh will be the ASCII
string in the following format: string in the following format:
"<scheme>://<host>:<port>", where <scheme>, <host>, "<scheme>://<host>:<port>", where <scheme>, <host>,
and <port> are the URI components corresponding to the and <port> are the URI components corresponding to the
currently accessing server-side resource. The scheme server-side resource currently being accessed. The
and host are in lower case, and the port is in a scheme and host are in lower case, and the port is in
shortest decimal representation. Even if the request- a shortest decimal representation. Even if the
URI does not have a port part, v will include the request-URI does not have a port part, v will include
default port number. the default port number.
tls-server-end-point: TLS endpoint (certificate) validation: The tls-server-end-point: TLS endpoint (certificate) validation: The
value vh will be the octet string of the hash value of value vh will be the octet string of the hash value of
the server's public key certificate used in the the server's public key certificate used in the
underlying TLS [RFC5246] connection, processed as underlying TLS [RFC5246] connection, processed as
specified in Section 4.1 of [RFC5929]. specified in Section 4.1 of [RFC5929].
tls-unique: TLS shared-key validation: The value vh will be the tls-unique: TLS shared-key validation: The value vh will be the
channel binding material derived from the Finished channel binding material derived from the Finished
messages, as defined in Section 3.1 of [RFC5929]. messages, as defined in Section 3.1 of [RFC5929].
skipping to change at page 27, line 50 skipping to change at page 27, line 50
[I-D.ietf-httpauth-extension], except for the "auth-style" parameter. [I-D.ietf-httpauth-extension], except for the "auth-style" parameter.
This specification also proposes (however, does not mandate) the This specification also proposes (however, does not mandate) the
default "auth-style" be "non-modal". Web applications SHOULD however default "auth-style" be "non-modal". Web applications SHOULD however
consider the security impacts of the behaviors of clients that do not consider the security impacts of the behaviors of clients that do not
support these headers. support these headers.
Authentication-initializing messages with the Authentication-initializing messages with the
Optional-WWW-Authenticate header are used only where the 401-INIT Optional-WWW-Authenticate header are used only where the 401-INIT
response is valid. It will not replace other 401-type messages such response is valid. It will not replace other 401-type messages such
as 401-STALE and 401-KEX-S1. That is, the reason field of such a as 401-STALE and 401-KEX-S1. That is, the reason field of such a
message &MUST be "initial" (or any extensive-tokens NOT defined in message MUST be "initial" (or any extensive-tokens NOT defined in
Section 4.1). Section 4.1).
9. String Preparation 9. String Preparation
It is important for interoperability that user names and passwords It is important for interoperability that user names and passwords
used in this protocol are binary-comparable regardless of the user's used in this protocol are binary-comparable regardless of the user's
input methods and/or environments. To ensure this, the following input methods and/or environments. To ensure this, the following
preparation SHOULD be performed: preparation SHOULD be performed:
o User names received from users SHOULD be prepared using the o User names received from users SHOULD be prepared using the
skipping to change at page 47, line 15 skipping to change at page 47, line 15
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., Maeda, K., Hayashi, Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi,
T., and Y. Ioku, "HTTP Authentication Extensions for T., and Y. Ioku, "HTTP Authentication Extensions for
Interactive Clients", draft-ietf-httpauth-extension-08 Interactive Clients", draft-ietf-httpauth-extension-09
(work in progress), August 2016. (work in progress), August 2016.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>. <http://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
skipping to change at page 50, line 18 skipping to change at page 50, line 18
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS) Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension", Session Hash and Extended Master Secret Extension",
RFC 7627, DOI 10.17487/RFC7627, September 2015, RFC 7627, DOI 10.17487/RFC7627, September 2015,
<http://www.rfc-editor.org/info/rfc7627>. <http://www.rfc-editor.org/info/rfc7627>.
Appendix A. (Informative) Draft Change Log Appendix A. (Informative) Draft Change Log
[To be removed on final publication] [To be removed on final publication]
A.1. Changes in Httpauth WG Revision 09 A.1. Changes in Httpauth WG Revision 10
o Small rephrasing and a typo fix.
A.2. Changes in Httpauth WG Revision 09
o Reflected AD review comments. o Reflected AD review comments.
o Authors' addresses updated. o Authors' addresses updated.
A.2. Changes in Httpauth WG Revision 08 A.3. Changes in Httpauth WG Revision 08
o Minor text update, in sync with httpauth-extension. o Minor text update, in sync with httpauth-extension.
o The version token is raised to "1". o The version token is raised to "1".
A.3. Changes in Httpauth WG Revision 07 A.4. Changes in Httpauth WG Revision 07
o Several comments from reviewers are reflected to the text. o Several comments from reviewers are reflected to the text.
o The password-hash has been completely dropped. o The password-hash has been completely dropped.
o The version token is raised to "1". o The version token is raised to "1".
A.4. Changes in Httpauth WG Revision 06 A.5. Changes in Httpauth WG Revision 06
o The auth-domain parameter has been renamed to auth-scope, o The auth-domain parameter has been renamed to auth-scope,
following suggestions on the mailing list. following suggestions on the mailing list.
o The digest-md5 password-hash has been dropped, as Digest with MD5 o The digest-md5 password-hash has been dropped, as Digest with MD5
hash is now obsoleted. hash is now obsoleted.
A.5. Changes in Httpauth WG Revision 05 A.6. Changes in Httpauth WG Revision 05
o Minimum nonce number window has increased to 128. (HTTP 2.0 o Minimum nonce number window has increased to 128. (HTTP 2.0
recommends at least 100 concurrent sessions to exist) recommends at least 100 concurrent sessions to exist)
o Reference to TLS session hash extension added for tls-unique o Reference to TLS session hash extension added for tls-unique
security issues. security issues.
o Comments in the previous F2F meeting has been reflected to the o Comments in the previous F2F meeting has been reflected to the
text. text.
A.6. Changes in Httpauth WG Revision 04 A.7. Changes in Httpauth WG Revision 04
o Merged httpauthprep proposal into general PRECIS Username/Password o Merged httpauthprep proposal into general PRECIS Username/Password
profile. profile.
o Adopting RFC 5987 extended syntax for non-ASCII parameter values. o Adopting RFC 5987 extended syntax for non-ASCII parameter values.
o Refer draft-ietf-httpbis-auth-info for Authentication-Info header. o Refer draft-ietf-httpbis-auth-info for Authentication-Info header.
This results in a different syntax for that header. This results in a different syntax for that header.
A.7. Changes in Httpauth WG Revision 03 A.8. Changes in Httpauth WG Revision 03
o Incompatible change: Single-port type authentication realm label o Incompatible change: Single-port type authentication realm label
has been changed to harmonize with Web Origin. (That is, the has been changed to harmonize with Web Origin. (That is, the
default ports (80 and 443) are to be omitted.) default ports (80 and 443) are to be omitted.)
A.8. Changes in Httpauth WG Revision 02 A.9. Changes in Httpauth WG Revision 02
o Major change: introduction of password-strengthening function o Major change: introduction of password-strengthening function
PBKDF2. PBKDF2.
o Changed Section 10 to adopt "list of requirements" style. Strict o Changed Section 10 to adopt "list of requirements" style. Strict
definition of state machine is now a derived, informational definition of state machine is now a derived, informational
definition. definition.
A.9. Changes in Httpauth WG Revision 01 A.10. Changes in Httpauth WG Revision 01
o Changed "tls-key" verification to "tls-unique" verification, and o Changed "tls-key" verification to "tls-unique" verification, and
"tls-cert" to "tls-server-end-point", adopting RFC 5929. "tls-cert" to "tls-server-end-point", adopting RFC 5929.
o Adopted PRECIS framework [RFC7564]. o Adopted PRECIS framework [RFC7564].
o Reverted reservation of "rekey-sid" and "rekey-method" parameters. o Reverted reservation of "rekey-sid" and "rekey-method" parameters.
o Degraded secure UI requirement to application note level, non- o Degraded secure UI requirement to application note level, non-
normative. normative.
o Adjusted levels of several requirements. o Adjusted levels of several requirements.
o Added warning text for handling of exceptional 5XX responses. o Added warning text for handling of exceptional 5XX responses.
o Dropped several references for optional authentications, except o Dropped several references for optional authentications, except
one "Note". one "Note".
o Several textual fixes, improvements and revisions. o Several textual fixes, improvements and revisions.
A.10. Changes in Httpauth Revision 00 A.11. Changes in Httpauth Revision 00
o Changed the version token. o Changed the version token.
o Renamed "verification tokens" to "Host verification tokens" and o Renamed "verification tokens" to "Host verification tokens" and
variables "v" to "vh" for clarification. (Back-ported from variables "v" to "vh" for clarification. (Back-ported from
draft-oiwa-httpauth-multihop-template-00) draft-oiwa-httpauth-multihop-template-00)
A.11. Changes in HttpBis Revision 00 A.12. Changes in HttpBis Revision 00
None. None.
A.12. Changes in Revision 12 A.13. Changes in Revision 12
o Added a reason "authz-failed". o Added a reason "authz-failed".
A.13. Changes in Revision 11 A.14. Changes in Revision 11
o Message syntax definition reverted to pre-07 style as httpbis-p1 o Message syntax definition reverted to pre-07 style as httpbis-p1
and p7 now defines a precise rule for parameter value parsing. and p7 now defines a precise rule for parameter value parsing.
o Replaced "stale" parameter with more informative/extensive o Replaced "stale" parameter with more informative/extensive
"reason" parameter in 401-INIT and 401-STALE. "reason" parameter in 401-INIT and 401-STALE.
o Reserved "rekey-sid" and "rekey-method" parameters for future o Reserved "rekey-sid" and "rekey-method" parameters for future
extensions. extensions.
o Added descriptions for replacing/non-replacing existing o Added descriptions for replacing/non-replacing existing
technologies. technologies.
A.14. Changes in Revision 10 A.15. Changes in Revision 10
o The authentication extension parts (non-mandatory authentication o The authentication extension parts (non-mandatory authentication
and authentication controls) are separated to yet another draft. and authentication controls) are separated to yet another draft.
o The default auth-domain parameter is changed to the full scheme- o The default auth-domain parameter is changed to the full scheme-
host-port syntax, which is consistent with usual HTTP host-port syntax, which is consistent with usual HTTP
authentication framework behavior. authentication framework behavior.
o Provision for application channel binding is added. o Provision for application channel binding is added.
skipping to change at page 53, line 32 skipping to change at page 53, 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 |
+------------+----------+-------------------------------------------+ +------------+----------+-------------------------------------------+
A.15. Changes in Revision 09 A.16. 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 54, line 8 skipping to change at page 54, 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 |
+-------------------+-----------------+-----------------------------+ +-------------------+-----------------+-----------------------------+
A.16. Changes in Revision 08 A.17. Changes in Revision 08
o The English text has been revised. o The English text has been revised.
A.17. Changes in Revision 07 A.18. Changes in Revision 07
o Adapt to httpbis HTTP/1.1 drafts: o Adapt to httpbis HTTP/1.1 drafts:
* Changed definition of extensive-token. * Changed definition of extensive-token.
* LWSP continuation-line (%0D.0A.20) deprecated. * LWSP continuation-line (%0D.0A.20) deprecated.
o To simplify the whole spec, the type of nonce-counter related o To simplify the whole spec, the type of nonce-counter related
parameters are change from hex-integer to integer. parameters are change from hex-integer to integer.
o Algorithm tokens are renamed to include names of hash algorithms. o Algorithm tokens are renamed to include names of hash algorithms.
o Clarified the session management, added details of server-side o Clarified the session management, added details of server-side
protocol decisions. protocol decisions.
o The whole draft was reorganized; introduction and overview has o The whole draft was reorganized; introduction and overview has
been rewritten. been rewritten.
A.18. Changes in Revision 06 A.19. Changes in Revision 06
o Integrated Optional Mutual Authentication to the main part. o Integrated Optional Mutual Authentication to the main part.
o Clarified the decision procedure for message recognitions. o Clarified the decision procedure for message recognitions.
o Clarified that a new authentication request for any sub-requests o Clarified that a new authentication request for any sub-requests
in interactive clients may be silently discarded. in interactive clients may be silently discarded.
o Typos and confusing phrases are fixed. o Typos and confusing phrases are fixed.
o Several "future considerations" are added. o Several "future considerations" are added.
A.19. Changes in Revision 05 A.20. Changes in Revision 05
o A new parameter called "version" is added for supporting future o A new parameter called "version" is added for supporting future
incompatible changes with a single implementation. In the (first) incompatible changes with a single implementation. In the (first)
final specification its value will be changed to 1. final specification its value will be changed to 1.
o A new header "Authentication-Control" is added for precise control o A new header "Authentication-Control" is added for precise control
of application-level authentication behavior. of application-level authentication behavior.
A.20. Changes in Revision 04 A.21. Changes in Revision 04
o Changed text of patent licenses: the phrase "once the protocol is o Changed text of patent licenses: the phrase "once the protocol is
accepted as an Internet standard" is removed so that the sentence accepted as an Internet standard" is removed so that the sentence
also covers the draft versions of this protocol. also covers the draft versions of this protocol.
o The "tls-key" verification is now OPTIONAL. o The "tls-key" verification is now OPTIONAL.
o Several description fixes and clarifications. o Several description fixes and clarifications.
A.21. Changes in Revision 03 A.22. Changes in Revision 03
o Wildcard domain specifications (e.g. "*.example.com") are allowed o Wildcard domain specifications (e.g. "*.example.com") are allowed
for auth-domain parameters (Section 4.1). for auth-domain parameters (Section 4.1).
o Specification of the tls-cert verification is updated o Specification of the tls-cert verification is updated
(incompatible change). (incompatible change).
o State transitions fixed. o State transitions fixed.
o Requirements for servers concerning w_a values are clarified. o Requirements for servers concerning w_a values are clarified.
o RFC references are updated. o RFC references are updated.
A.22. Changes in Revision 02 A.23. Changes in Revision 02
o Auth-realm is extended to allow full-scheme type. o Auth-realm is extended to allow full-scheme type.
o A decision diagram for clients and decision procedures for servers o A decision diagram for clients and decision procedures for servers
are added. are added.
o 401-B1 and req-A3 messages are changed to contain authentication o 401-B1 and req-A3 messages are changed to contain authentication
realm information. realm information.
o Bugs on equations for o_A and o_B are fixed. o Bugs on equations for o_A and o_B are fixed.
o Detailed equations for the entire algorithm are included. o Detailed equations for the entire algorithm are included.
o Elliptic-curve algorithms are updated. o Elliptic-curve algorithms are updated.
o Several clarifications and other minor updates. o Several clarifications and other minor updates.
A.23. Changes in Revision 01 A.24. Changes in Revision 01
o Several texts are rewritten for clarification. o Several texts are rewritten for clarification.
o Added several security consideration clauses. o Added several security consideration clauses.
Authors' Addresses Authors' Addresses
Yutaka Oiwa Yutaka Oiwa
National Institute of Advanced Industrial Science and Technology National Institute of Advanced Industrial Science and Technology
Information Technology Research Institute Information Technology Research Institute
 End of changes. 32 change blocks. 
60 lines changed or deleted 67 lines changed or added

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