Mutual Authentication Protocol for HTTP
draft-ietf-httpauth-mutual-11

[Ballot comment]
Thank you for addressing my DISCUSS points and most of my comments!

I agree that the Introduction section might need an editing pass.

In Section 1, next to the last paragraph:

  The Mutual authentication protocol proposed in this document is a
  strong cryptographic solution for password authentications.  It
  mainly provides the two key features:

Exactly the same paragraph appears earlier in the same section. Did you forget to delete this instance?

In Section 9:

  In both cases, it is the sender's duty to correctly prepare the
  character strings.  If any non-normalized character string is
  received from the other peer of the communication, recipients MAY
  either use it as a bare UTF-8 string without any preparation, perform
  any appropriate preparations (which may cause authentication
  failure), or reject any ill-prepared inputs from the sender and
  respond as a communication error.

I think you are giving too many choices which might cause interoperability issues.
Even reducing the choices from 3 to 2 would help here.

In Section 11:

      *  Otherwise, send a 200-VFY-S response.  If the session was in
        the "key exchanging" state, the session SHOULD be changed to an
        "authenticated" state.  The maximum nc and nc flags of the
        state SHOULD be updated appropriate.

Can you explain why these 2 SHOULDs are not MUSTs? I.e., what are possible reasons for a server implementation to violate these SHOULDs?

In Section 15:

It would be good to be able to bind extension data to shared secret constructed by
both parties.

[Ballot discuss]
This is generally a well written document. I have a couple of important comments that I would like to see addressed and several less significant comments.

1) As Mirja pointed out, this spec needs need to register "Mutual" HTTP Authentication Schemes with IANA

2) In Section 7:

  If HTTP is used on a non-encrypted channel (TCP and SCTP, for
  example), the validation type MUST be "host".  If HTTP/TLS [RFC2818]
  (HTTPS) is used with a server certificate, the validation type MUST
  be "tls-server-end-point".  If HTTP/TLS is used with an anonymous
  Diffie-Hellman key exchange, the validation type MUST be "tls-unique"
  (see the note below).

  Implementations supporting Mutual authentication over HTTPS SHOULD
  support the "tls-server-end-point" validation.  Support for
  "tls-unique" validation is OPTIONAL for both servers and clients.

I think the two paragraphs are in conflict. For example, the first one
says that if TLS with server certificate is used, then "tls-server-end-point"
MUST be supported. But the second says that it is SHOULD be supported.

If the intent of the first paragraph is to say what should appear syntactically,
while the second paragraph explains what kind of validation is actually required,
I think this still can be made clearer.

I suggest you either delete the second of these 2 paragraphs, or you
need to reword text in the first (and possibly the second) to specify
a non conflicting set of requirements.

[Ballot comment]

I agree that the Introduction section might need an editing pass.

In Section 1, next to the last paragraph:

  The Mutual authentication protocol proposed in this document is a
  strong cryptographic solution for password authentications.  It
  mainly provides the two key features:

Exactly the same paragraph appears earlier in the same section. Did you forget to delete this instance?

3.2.  Values

  The parameter values contained in challenge/credentials MUST be
  parsed strictly conforming to the HTTP semantics (especially un-
  quoting of the string parameter values).  In this protocol, those
  values are further categorized into the following value types: tokens
  (bare-token and extensive-token), string, integer, hex-fixed-number,
  and base64-fixed-number.

  For clarity, implementations are RECOMMENDED to use the canonical
  representations specified in the following subsections for sending
  values.  Recipients SHOULD accept both quoted and unquoted
  representations interchangeably as specified in HTTP.

I think the last SHOULD must be a MUST, because clients that generate these values
might be using libraries that automatically quote values. So this is really not
under sender's control.


3.2.2.  Strings

  All character strings MUST be encoded to octet strings using the
  UTF-8 encoding [RFC3629] for the ISO 10646-1 character set
  [ISO.10646-1.1993].

This is the same as Unicode 1.1. Unicode now released version 9.0! I suggest you use a Unicode reference.

In 3.2.3:

I think you are overusing SHOULDs instead of MUSTs in many
places in the document (not just just in this section). For example:

  When
  these values are generated from any cryptographic values, they SHOULD
  have their "natural length"; if these are generated from a hash
  function, these lengths SHOULD correspond to the hash size;

Why not a MUST here?

  if these
  are representing elements of a mathematical set (or group), its
  lengths SHOULD be the shortest for representing all the elements in

Again, why not a MUST? Having a unique encoding will improve interoperability.

  the set.

  The numbers represented as base64-fixed-number SHALL be generated as
  follows: first, the number is converted to a big-endian radix-256
  binary representation as an octet string.  The length of the
  representation is determined in the same way as mentioned above.
  Then, the string is encoded using the Base 64 encoding [RFC4648]

I assume you meant Section 4 alphabet and not Section 5 alphabet from this
RFC. Please add section reference to the above.

  without any spaces and newlines.  Implementations decoding base64-
  fixed-number SHOULD reject any input data with invalid characters,
  excess/insufficient padding, or non-canonical pad bits (See Sections
  3.1 to 3.5 of [RFC4648]).

7.1.  Applicability notes

  When the client is a Web browser with any scripting capabilities, the

Can you explain why scripting capabilities are important here?

  underlying TLS channel used with HTTP/TLS MUST provide server
  identity verification.  This means (1) anonymous Diffie-Hellman key
  exchange cipher suites MUST NOT be used, and (2) verification of the
  server certificate provided by the server MUST be performed.

In Section 9:

  In both cases, it is the sender's duty to correctly prepare the
  character strings.  If any non-normalized character string is
  received from the other peer of the communication, recipients MAY
  either use it as a bare UTF-8 string without any preparation, perform
  any appropriate preparations (which may cause authentication
  failure), or reject any ill-prepared inputs from the sender and
  respond as a communication error.

I think you are giving too many choices which might cause interoperability issues.
Even reducing the choices from 3 to 2 would help here.

In Section 11:

      *  Otherwise, send a 200-VFY-S response.  If the session was in
        the "key exchanging" state, the session SHOULD be changed to an
        "authenticated" state.  The maximum nc and nc flags of the
        state SHOULD be updated appropriate.

Can you explain why these 2 SHOULDs are not MUSTs? I.e., what are possible reasons for a server implementation to violate these SHOULDs?

In Section 15:

It would be good to be able to bind extension data to shared secret constructed by
both parties.

[Ballot comment]
I agree with Alvaro on concerns about the IPR section.  Didn't we have large issues just saying that there was another draft with the creative commons copyright?

[Ballot comment]
Most of my comments have already been covered by others.

I agree with others that the introduction really needs more editing.

I share the question about the IPR section. In general, IETF stream documents are not expected to contain licensing language beyond that in the TLP. OTOH, that's about copyright, and this is clearly not--but I wonder why the existing IPR disclosure is not sufficient. If the section is to remain,  I suggest making sure this has been reviewed by someone from the IETF trust prior to publication.

- Section 16: I don't think 2119 MUSTs are appropriate for IANA instructions.
-- I think the registration policy you are looking for is "Specification Required".

[Ballot comment]
I only reviewed sections 1-6, but I am sending my comments so far:

In Section 1, next to the last paragraph:

  The Mutual authentication protocol proposed in this document is a
  strong cryptographic solution for password authentications.  It
  mainly provides the two key features:

Exactly the same paragraph appears earlier in the same section. Did you forget to delete this instance?

3.2.  Values

  The parameter values contained in challenge/credentials MUST be
  parsed strictly conforming to the HTTP semantics (especially un-
  quoting of the string parameter values).  In this protocol, those
  values are further categorized into the following value types: tokens
  (bare-token and extensive-token), string, integer, hex-fixed-number,
  and base64-fixed-number.

  For clarity, implementations are RECOMMENDED to use the canonical
  representations specified in the following subsections for sending
  values.  Recipients SHOULD accept both quoted and unquoted
  representations interchangeably as specified in HTTP.

I think the last SHOULD must be a MUST, because clients that generate these values
might be using libraries that automatically quote values. So this is really not
under sender's control.


3.2.2.  Strings

  All character strings MUST be encoded to octet strings using the
  UTF-8 encoding [RFC3629] for the ISO 10646-1 character set
  [ISO.10646-1.1993].

This is the same as Unicode 1.1. Unicode now released version 9.0! I suggest you use a Unicode reference.

In 3.2.3:

  The numbers represented as base64-fixed-number SHALL be generated as
  follows: first, the number is converted to a big-endian radix-256
  binary representation as an octet string.  The length of the
  representation is determined in the same way as mentioned above.
  Then, the string is encoded using the Base 64 encoding [RFC4648]

I assume you meant Section 4 alphabet and not Section 5 alphabet from this
RFC. Please add section reference to the above.

  without any spaces and newlines.  Implementations decoding base64-
  fixed-number SHOULD reject any input data with invalid characters,
  excess/insufficient padding, or non-canonical pad bits (See Sections
  3.1 to 3.5 of [RFC4648]).

[Ballot comment]
= Section 1 =

I agree with Terry that the introduction would benefit from an edit pass.

= Section 2.3 =

"The server MAY have thrown out the corresponding session from the
      session table."
   
This seems like an inappropriate use of normative MAY, as it is describing behavior in the past. Either "MAY throw out" or "may have thrown out" would be appropriate.

"Under the
  appropriate settings and implementations, most of the requests to
  resources are expected to meet both criteria, and thus only one
  round-trip of request/response will be required."

This statement seems to presume much wider deployment than I would anticipate for this experiment. If I understand correctly, you would need mutual auth implemented by a sufficient proportion of servers to justify providing a knob in a browser that allows the user to indicate that he wants to send a key exchange in the first request to sites that have required mutual auth in the past. Is that what is meant by "settings"? If so, I think this either requires more explanation about the circumstances under which "most" requests can be reduced to 1 RT, or this statement needs to be qualified at a level below "most."

= Section 4.1 =

"user-unknown: this is a special case of auth-
                    failed, suggesting that the provided user name is
                    invalid.  The use of this parameter is
                    NOT RECOMMENDED due to security implications,
                    except for special-purpose applications where it
                    makes sense."

The exception case here seems underspecified. It's not clear what kind of "special-purpose" application would warrant this in light of the information it potentially leaks and the fact that such applications, if they do not have scripting capabilities, do not require transport security when using this protocol according to Section 7.

I have the same question about invalid-credential.

[Ballot comment]
Thanks for writing a very detailed document.

A few minor comments.

1) Please review the introduction, there are several grammatical errors in there. Meaning still came through just fine, but they were a little distracting.

2) The state machine diagram of the client is quite complex. A candidate for the new RFC format?

3) I agree with Alvaro's comment on the IPR. Thank you for making it royalty free, however not sure you need to add the text in the RFC.

4) This to me seems as it is essentially a shared secret construct, one sentence from RFC 2361 (security considerations) seems applicable here. "All the security in this system is provided by the secrecy of the private keying material." If this the case, please provide ample warning that (as one would expect) loss of the password from either the client or the server results in a complete compromise.

[Ballot comment]
Some editorial comments from our OPS-DIR reviewer, Qin Wu.

I believe this document is ready for publication. Here are a few editorial comments I like to ask authors to consider:

Minor issues:

1.      Section 1.1 said:

“

When a natural

  number output is required, the notation INT(H(s)) is used.



”

I will see INT(H(s)) as a formula to convert H(s) into natural number

2.      Section 2, 1st paragraph:

What is DL-based notations? Can you expand DL? Is it Description Logic or something else?

You can consider to add acronym and abbreviation section.

3.Section 2, 2nd paragraph and the figure that describe protocol exchange for four value

Where you define the first two messages in this draft? Are you referred to the first messages that contain ID, K_c1 and K_s1 respectively in the figure? I don’t see you specify message format or give a message name? I don’t see you related text with the message shown in the figure?



In addition, where the last two message defined in [I-D.ietf-httpauth-mutual]? Can you provide section number?

By reading [[I-D.ietf-httpauth-mutual], I see K_c1, K_s1, VK_c,VK_s has already been defined in [[I-D.ietf-httpauth-mutual], I feel confused and am wondering if this draft really defines the first two messages? Or four message shown in the figure are all defined in the [[I-D.ietf-httpauth-mutual].



4.Section 3.1, 3rd paragraph said:

“

The functions named octet(), OCTETS(), and INT() are those defined in

the core specification [I-D.ietf-httpauth-mutual].

“

Is the core specification [I-D.ietf-httpauth-mutual]the core document mentioned in section 3? If yes, please make them consistent.



5.Section 3.3, symbol “G”

g: for "the generator" associated with the group.

How the symobol “G” is different from symbol “g”in the section 3.2? Does G stand for the generator associated with the defined group? What do you mean “the defined point”? Would be great to clarify the difference between G and g.



6.Section 5.2 said:

“

In the EC setting, r has to be

prime.  Defining a variation of this algorithm using a different

domain parameter SHOULD be attentive to these conditions.

“

What is EC setting? Please expand EC? Elliptic Curve? Please make this clear or add this abbreviation into abbreviation section.



Nites:

1.Section 1,1st paragraph

s/ use withMutual authentication protocol/ use with Mutual authentication protocol

2.Section 5.2

s/ mixing values from from two/ mixing values from two


-Qin

[Ballot comment]
Thanks for this well written spec!

One important question:
Doesn't this spec need to register a new HTTP Authentication Schemes ("Mutual") with IANA?

Further minor comments/questions:

1) Somehow I don't understand this:
"For responses, the parameters "reason", any "ks#" (where # stands
      for any decimal integer), and "vks" are mutually exclusive; any
      challenge MUST NOT contain two or more parameters among them.
      They MUST NOT contain any "kc#" or "vkc" parameters."
Who is 'they' in the last sentence?

2) "Typically, clients can ensure the above property by using a
  monotonically-increasing integer counter that counts from zero up to
  the value of nc-max."
Wouldn't it be better to use a randomized number?

3) Nit: s/Even if the request-URI does not have a port part, v will include the default port number./Even if the request-URI does not have a port part, vh will include the default port number./

[Ballot comment]
Thanks for this well written spec!

One importnat question:
Doesn't this spec need to register a new HTTP Authentication Schemes ("Mutual") with IANA?

Further minor comments/questions:

1) Somehow I don't understand this:
"For responses, the parameters "reason", any "ks#" (where # stands
      for any decimal integer), and "vks" are mutually exclusive; any
      challenge MUST NOT contain two or more parameters among them.
      They MUST NOT contain any "kc#" or "vkc" parameters."
Who is 'they' in the last sentence?

2) "Typically, clients can ensure the above property by using a
  monotonically-increasing integer counter that counts from zero up to
  the value of nc-max."
Wouldn't it be better to use a randomized number?

3) Nit: s/Even if the request-URI does not have a port part, v will include the default port number./Even if the request-URI does not have a port part, vh will include the default port number./

[Ballot comment]
I don't object to the publication of this document.  But I found it interesting that Section 18. (Notice on Intellectual Properties) is even there -- I don't think it is needed.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-httpauth-mutual-10.txt. If any part of this review is inaccurate, please let us know.

We have a question about one of the actions requested in the IANA Considerations section of this document.

Upon approval of this document, we understand that there are two registry actions to complete.

First, a new registry is to be created called the HTTP Mutual authentication algorithms registry. We note that the registrations in this new registry will consist of a Token, a Description and a Reference.

QUESTION -> Where should this new registry be located? Is it a new registry on the List of all IANA maintained protocol parameter registries or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained?

We understand that the registry is to be managed through Expert Review as defined in RFC 5226.

While this document provides no initial values for the new registry, we understand that another document ietf-httpauth-mutual-algo is dependent upon the actions in this IANA Considerations section being completed. When they are, the document ietf-httpauth-mutual-algo will provide new registrations for the new registry.

Second, another new registry is to be created called the HTTP Mutual authentication host validation methods registry. We note that the registrations in this new registry will consist of a Token, a Description and a Reference.

QUESTION -> Where should this new registry be located? Is it a new registry on the List of all IANA maintained protocol parameter registries or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained?

We understand that the registry is to be managed through Expert Review as defined in RFC 5226.

There are initial registrations in this new registry as follows:

+----------------------+----------------------------+----------------------------+
| Token | Description | Reference |
+----------------------+----------------------------+----------------------------+
| host | Host name verification | [ RFC-to-be Section 7 ] |
| | only | |
| tls-server-end-point | TLS certificate-based | [ RFC-to-be Section 7 ] |
| tls-unique | TLS unique key-based | [ RFC-to-be Section 7 ] |
+----------------------+----------------------------+----------------------------+

We understand that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-httpauth-mutual@ietf.org, rifaat.ietf@gmail.com, httpauth-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, http-auth@ietf.org, "Rifaat Shekh-Yusef"
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Mutual Authentication Protocol for HTTP) to Experimental RFC


The IESG has received a request from the Hypertext Transfer Protocol
Authentication WG (httpauth) to consider the following document:
- 'Mutual Authentication Protocol for HTTP'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-10-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies a mutual authentication scheme for the
  Hypertext Transfer Protocol (HTTP).  This scheme provides true mutual
  authentication between an HTTP client and an HTTP server using
  password-based authentication.  Unlike the Basic and Digest
  authentication schemes, the Mutual authentication scheme specified in
  this document assures the user that the server truly knows the user's
  encrypted password.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/906/
  https://datatracker.ietf.org/ipr/2220/

Technical Summary
-----------------

This document specifies a mutual authentication scheme for the
Hypertext Transfer Protocol (HTTP).  This scheme provides true mutual
authentication between an HTTP client and an HTTP server using
password-based authentication.  Unlike the Basic and Digest
authentication schemes, the Mutual authentication scheme specified in
this document assures the user that the server truly knows the user's
encrypted password.


Working Group Summary
---------------------

This document is one of the experimental documents submitted to the
HTTP-Auth working group.

With version -8 it is the consensus of the HTTP-Auth working group
that this document is fit to be published as an experimental RFC.


Document Quality
----------------

The proposed mutual authentication method has been reviewed by a fair
number of participants.

There is at least one known implementation of this protocol.


Intellectual Property
=====================

The authors declared 2 IPRs:
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-httpauth-mutual


Personnel
---------

Authors: Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Kaoru Maeda,
        Tatsuya Hayashi, and Yuichi Ioku
Shepherd: Rifaat Shekh-Yusef
Area Director: Kathleen Moriarty