Subject: [http-auth] Review of Mutual Auth

From: Yaron Sheffer <[email-masked]>
Date: Sat, 28 Sep 2013 14:03:32 +0300

I have reviewed all three documents. Unfortunately I got distracted and 
so this took a long time, and by the time I finished the review I no 
longer saw the forest for the trees. I still hope these notes will be of 
value to the authors.

In general, I think password authentication will be with us for a long 
time, even when most Web sites use other mechanisms for most logins. And 
it needs to be integrated in the browser if it is to be secure. So this 
proposal is a very valid way of implementing a necessary feature.

On the other hand, if we want to move to a world where user agents 
normally authenticate with public keys (or PSKs, for that matter) into 
IdPs, and other Web authentication uses OAUTH or similar with an IdP, 
then the main use case for password authentication is reduced to "First 
time login into my IdP from my new phone". This is still critical, but 
surely can be done with a lot fewer headers/extensions than the current 
general-purpose set of documents.

Detailed Comments

draft-ietf-httpauth-mutual-00

• 1.1.1.2: I would contend that the main advantage of form 
authentication is not its flexibility but rather the ability to control 
the GUI: branding etc.
• 1.1.2.3: There is only one such example, Kerberos (GSS-API is used to 
extend Kerberos into the Web domain). In fact Kerberos suffers from 
phishing-like issues in its initial authentication, and the current 
protocol could be used to resolve them.
• 1.2: Treating the domain of hash functions as numbers (rather than 
octet strings) is very uncommon and confusing.
• 2.2: POP APOP - please add a reference
• Server responds with 401 in case of password mismatch: is it within 
the same session, or a new one?
• "This case should not happen" - but it might happen if there's a MITM 
attacker.
• 2.3: the server seldom knows whether the sid value is stale or a new 
one being tried by an attacker. Why not send a simple 401-INIT instead?
• Can the server send a hint to the client regarding the expected 
lifetime of the sid?
• This document appears to define a new "session continuation" 
mechanism, in addition to mere authentication.
• 2.3: The 3 round trip case could be shortened if we allowed the client 
to piggyback a KEX-C1 on top of the VFY-C. If there's no way for the 
client to guess in advance if the session secret is stale, this 
optimization may be valuable.
• 3, last paragraph: how is the client expected to handle multiple 
challenges? Are they each associated with a separate session? An so on.
• Why allow uppercase in hex digits, and then recommend not to use it?
• And why allow so many characters in base64, instead of alpha+digits, 
"+" and "/"?
• The version field should have an IANA registry. Recipients must reject 
unknown versions (and any other fields).
• pwd-hash: unclear (yet?) what this is for. Why not also support PBKDF2?
• 4.2: please specify that the 4 reflected parameters are mandatory.
• 4.3: the square of the max number of sessions is never going to be >80 
bits, because of physical limitations (number of atoms in the universe 
etc.).
• 4.3: do we really have to support the RFC 2617 "domain" construction 
(here, the "path" parameter)? Is it being used by implementations?
• 5: aren't we reinventing the wheel here? How does this discussion 
relate to web origins (RFC 6454)?
• 6: the discussion of nonces sounds like it it always the client that 
generates a nonce, and the server verifies it. But shouldn't we support 
the other direction, too?
• 6, last paragraph: it is unclear how the protocol is supposed to work 
if everybody is using the value 2**32-1 for all messages, which is how I 
understand the last sentence. Why not simply re-establish the session 
when the value overflows?
• 7: "tls-cert": this is the *server* certificate, right? I.e. neither a 
client cert nor a CA cert.
• 7: why not use RFC 5705 to bind to the TLS session?
• 7: why do we disallow anonymous TLS (e.g. Anonymous DH) for Web 
browsers? Actually Mutual Auth is a great solution when combined with 
ADH and channel binding.
• 8: what do you mean by "non modal"?
• 8: the value of non-mandatory auth is not clear to me. I suggest to 
omit it here and just give a pointer to the extension document.
• 9: in Step 14, please mention explicitly that a missing VK_s is fatal.
• 9: I suggest to remove the "should display" paragraph and not 
recommend UI behavior. This can quickly deteriorate into an endless 
discussion about "mixed" states (main page is authenticated but CSS is not).
• 9: for the 5xx exception, you should warn about displaying/using the 
response body.
• Fig. 5: this is missing the arrow from Step 14 into "unauthenticated" 
state.
• 10: IMHO management of invalid ("fake") session is an implementation 
detail, and out of scope of this document.
• 13: what is "m. m."?
• 16.1: please clarify the explanation why a valid SSL certificate is 
required for security of this protocol. I think this question is 
orthogonal to cross-site scripting.
• 16.3, last bullet: salting the password with the user name is much 
better than plain hashing of the password.
• 16: the security considerations should mention that the protocol is 
still vulnerable to active password guessing attacks, and so 
authentication attempts should be rate limited.

draft-oiwa-httpauth-mutual-algo-00

• Appendix A: there are good reasons to use already existing MODP 
groups. Can we do that?
• I think the document should define one method as "mandatory to implement".

draft-ietf-httpauth-extension-00

• 3: "The server is NOT RECOMMENDED to include" -> "It is NOT 
RECOMMENDED for the server to include" (this is purely grammar, but it 
repeats many time throughout the documents.)
• 4: Authentication-Control - this header should be associated with a 
particular session rather than with an authentication scheme.
• 4.2: If the parameter MUST be absolute, I don't understand why the 
following sentence discusses what happens if it isn't absolute.
• 5: "A user interface which allows users to log out" implies something 
in the browser's chrome. Instead we should assume (and work on?) a 
JavaScript API to drive authentication.
• 8: Any authentication token must be bound to an identity, and can also 
be bound to a duration. So I don't understand why we only define a 
client-local timeout feature, instead or requiring that any 
implementation of mutual auth should include a timeout feature that's 
usable by both client and server.