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

[Kathleen Moriarty <[e-mail]>]

Hello,

Is there a response to my comments?  I'd like to progress these 2
drafts into IETF last call once these comments are addressed.

Thank you,
Kathleen

On Thu, Aug 11, 2016 at 10:18 PM, Kathleen Moriarty
<[e-mail]> wrote:
> 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



-- 

Best regards,
Kathleen