[http-auth] AD review of draft-ietf-httpauth-mutual-08

[Kathleen Moriarty <[e-mail]>]

Hello,

Thank you for your work on draft-ietf-httpauth-mutual-08.  I will try
to get through my AD review of the accompanying draft tomorrow.

I read through the draft and have the following questions.


-----
Section 2.1, in the following text:

 o  Authenticated key exchange messages: used by both peers to perform
      authentication and the sharing of a cryptographic secret.

      *  req-KEX-C1 message: a message sent from the client.

      *  401-KEX-S1 message: a message sent from the server in response
         to a req-KEX-C1 message.

1. What does the response mean?  Is there a pass/fail message in the
response or is this just an ack that the message was received by the
server to the client?

Then in the following:
      *  200-VFY-S message: a client-authentication successful response
         used by the server, which also simultaneously asserts to the
         client that the server is authentic.

2. Maybe this will be clear as I read further through the draft, but
that seems like a lot to assert at once.  This note is a placeholder
for me in case I do't feel like there is an adequate answer when I get
deeper into the draft.

-----

Second bullet on page 7:

 o  At this point (5), both peers calculate a shared "session secret"
      using the exchanged values in the key exchange messages.  Only
      when both the server and the client have used secret credentials
      generated from the same password will the session secret values
      match.  This session secret will be used for access authentication
      of every individual normal after this point.

3. I think a word may be missing in the last sentence, can you
rephrase it?  I'm not able to parse it.

-----
In another bullet on page 7:

 o  If the authentication verification value from the client was
      correct, it means that the client definitely owns the credential
      based on the expected password (i.e., the client authentication
      succeeded).  The server will respond with a successful message
      (200-VFY-S) (7).  Contrary to the usual one-way authentication
      (e.g., HTTP Basic authentication or POP APOP authentication
      [RFC1939]), this message also contains a server-side
      authentication verification value.

      When the client's verification value is incorrect (e.g., because
      the user-supplied password was incorrect), the server will respond
      with the 401-INIT message (the same one as used in (2)) instead.

4. This last section should specify that the extensive-token
indicating an authentication failure must be included.  I would also
recommend that this information be logged and have that stated in this
draft.  Since we are pushing for protocols to be encrypted, the use of
sniffers to detect errors will continue to fall off and people will
need to rely on logs more.  I think it would be more helpful to have
an accurate log that responds saying the authentication failed
(user/password if you don't want to say which).  Encouraging richer
logs will be more helpful going forward.
-----
In Section 7, just to make sure I am reading this correctly:

The valid tokens for the validation parameter and corresponding
   values of vh are as follows:

   host:          host-name validation: The value vh will be the ASCII
                  string in the following format:
                  "<scheme>://<host>:<port>", where <scheme>, <host>,
                  and <port> are the URI components corresponding to the
                  currently accessing resource.

5. By "currently accessing resource", you mean the source system,
correct?  It might be better to rephrase that so it is clear since
this is important to developers.
-----
6. In Section 8, it is the reason parameter of the INIT that lets you
know if t is 'valid', correct?
   Authentication-initializing messages with the
   Optional-WWW-Authenticate header are used only where the 401-INIT
   response is valid.  It will not replace other 401-type messages such
   as 401-STALE and 401-KEX-S1.

I think it would be helpful to explicitly state what is a valid
response unless that is defined already and I missed it?  I think it
depends on the token or extensive token set in the reason parameter of
the INIT message.

----
7. In section 10.1, if you change "normal responses" to "normal
response", it is easier to fix the grammar in the following sentences:

   This also
   holds true for the reception of "normal responses" (responses which
   do not contain Mutual authentication-related headers) from HTTP
   servers.
change to:
   This also
   holds true for the reception of a "normal response" (responses which
   do not contain Mutual authentication-related headers) from HTTP
   servers.

from:
      Any kinds of "normal responses" MUST only be accepted for the very
      first request in the sequence.  Any "normal responses" returned
      for the second or later requests in the sequence SHALL be
      considered invalid.
change to:
      Any kind of "normal response" MUST only be accepted for the very
      first request in the sequence.  Any "normal response" returned
      for the second or later request in the sequence SHALL be
      considered invalid.

------
8. Section 10.1, please consider rewording the following sentences to
make it easier to read:
   o  In the same principle, any responses which refer to or request
      changing to an 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 different realms
      which are returned for the second or later requests in the
      sequence SHALL be considered invalid.
-----
9. In section 17.2, it might be helpful to include a reference to the
TLS 1.2 BCP, RFC7525.  The bullet might say something like, when TLS
1.2 is used, follow best practices in RFC7525.
-----
10. Section 17.3 is the first place I see a clear motivation for this
protocol.  It might help to have this stated in the introduction.
Although the points about password attacks in section 17.2 leave me
questioning how much of an improvement this really is.  How much
analysis was done on this new method? I know the drafts have been
around for a while.  I'd have to take another pass at the documents to
dig deeper, but would like to know if this analysis was done.  Can you
make the statement that this is more secure?  The motivation for HOBA
was clear - getting rid of the use of passwords.

Passwords are not sent in the clear, but this isn't stated in a
motivation section.  It just is part of the protocol and mentioned at
the end of section 17.5.  It might be helpful to include this in the
introduction as well in a motivation paragraph.  The abstract saying
that, "server truly knows the user's
encrypted password" isn't the same as saying that the password is
encrypted on the wire and doesn't rely on transport encryption.
-----
11. Section 17.3.  I'm not clear on this sentence in the last paragraph:
   Of course, in such cases, the user interfaces for asking passwords
   for this authentication shall be clearly identifiable against
   imitation by other insecure password input fields (such as forms).
Common attacks of this nature would be to direct users to a form that
isn't the real form.  Is it the mutual authentication that helps here?
 If so, explain how.  How is it clearly identifiable against
imitation?

-- 

Best regards,
Kathleen