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

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.

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?

= 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.

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.

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".

Comments from Meral's Gen-ART review should be looked at.

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./

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.