Subject: Re: [http-auth] Review of Mutual Auth

From: Yutaka OIWA <[email-masked]>
Date: Mon, 7 Oct 2013 19:10:42 +0900

Thank you Yaron,

we really appreciate your review comments, which seems really insightful for
us to improving the drafts.

2013/9/28 Yaron Sheffer <[email-masked]>:
> draft-ietf-httpauth-mutual-00

> • 1.2: Treating the domain of hash functions as numbers (rather than octet
> strings) is very uncommon and confusing.

I'm sorry there is some confusion (mistaken inconsistency in ph).
I'd like to rewrite it to more consistent notation.
One of my past reasons to using such convention is
now not significant in the current drafts, so
I will take the octet-string convention now.

> • 2.2: POP APOP - please add a reference

Agreed.

> • Server responds with 401 in case of password mismatch: is it within the
> same session, or a new one?

Response is (technically speaking) within the same session,
however, it is impossible to use that session any more.
A new request with new password will generate a new session.
(as specified in Section 10,
>> if the received vkc is incorrect, [...]
>> If the session is in the "key exchanging" state,
>> it SHOULD be changed to the "rejected" state;
)

> • "This case should not happen" - but it might happen if there's a MITM
> attacker.
"[...] should not happen between a correctly-implemented server and a client"...
we may need to append it with "without any interventions (such as MITM
attacks)".

> • 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?

As details specified in Section 10, in such cases, servers will simply send
401-STALE responses.  You're correct that servers cannot know whether
it is stale or being attacked, and it's OK to send 401-STALE in both cases.
Distinction between 401-INIT and 401-STALE is important for correct
behavior of the "valid" clients.

> • Can the server send a hint to the client regarding the expected lifetime
> of the sid?

It's a good idea.

> • This document appears to define a new "session continuation" mechanism, in
> addition to mere authentication.

My idea is much like nonces in Digest and a part of authentication mechanism.
It is just a cache of shared keys for short-cut fast re-authentication.
We hide this "session continuation"-like mechanism to the internal of
authentication protocol, so that any servers and clients can
simply discard any cached sessions, can introduce any arbitrary limits
on session
durations (which is sometimes critical for security management), regardless of
how long Web applications intend to retain user authentication sessions.
Having two layers here is intentional design choise which has reasons.

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

Good point, but as generating KEX-C1 is time-consuming, I personally
prefer sending a hint for time-based session durations, as you suggested above.

> • 3, last paragraph: how is the client expected to handle multiple
> challenges? Are they each associated with a separate session? An so on.

For multiple challenges contained in 401 responses (it happens for 401-INIT),
clients can choose any of that for authentication trial.
After that, a single session is bound to a single realm (i.e. single challenge).

> • Why allow uppercase in hex digits, and then recommend not to use it?

It's mostly my personal preference that sending messages should be canonified
as much as possible, and recipients should be liberal as much as
security is kept.
For this specific case, it is not a strong requirement for security,
so we may loosen it to any-case.

> • And why allow so many characters in base64, instead of alpha+digits, "+"
> and "/"?

It shares the grammer of "token68" in httpbis-p7, which was named "b64token"
when I wrote it.  Possible fixes are to make it strict or to refer
token68, which is appropriate?

> • The version field should have an IANA registry. Recipients must reject
> unknown versions (and any other fields).

Yes.

> • pwd-hash: unclear (yet?) what this is for. Why not also support PBKDF2?

It is only for (possible) legacy-migration of password databases, and
if not required, we may omit it.
Please refer my previous post named as answers to FAQs for more details.

> • 4.2: please specify that the 4 reflected parameters are mandatory.

Technically, "algorithm", "auth-domain" and "realm" are defining the
scope of each authentication scope (called authentication realms in Sec 5).
We may rethink of algorithm and validation, however.

> • 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.).

Good point :-)
Each session roughly takes about 2^9 bytes of storage at least
(two 2048-bit keys), and
the world's largest storage is around a few hundled petabytes,
around 2^59 according to Google search result.
This means at extreme the number will not exceed 2^100,
and most likely not beyond 2^80.  Quite interesting :-)

One point here is that we need to include all sessions which is
generated, thought to be active in the client but cleared from the
server storage
into this number.  Even in this case, 2^80 seems to be safe :-)

However, at the same time, I do not to want to have the number 2^80
"walk alone" (as we say in Japanese) without background reasons.
The number should always be associated with supporting reasons.
How do you think?

> • 4.3: do we really have to support the RFC 2617 "domain" construction
> (here, the "path" parameter)? Is it being used by implementations?

"SHOULD" may be a bit too strong, but I strongly recommend to
implement this for better performance using complex HTTP authentication
from now on.

> • 5: aren't we reinventing the wheel here? How does this discussion relate
> to web origins (RFC 6454)?

No.  It's much like a domain parameter in the Cookie, which
creates a set of multiple RFC6454-web origins.
I also posted a separate answer for this, please let me refer it.

> • 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?

Do you mean about HTTP/2.0 server push? :-)
If HTTP/2.0 really goes to support server push of authenticated contents,
we may extend the specification to support that.

> • 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?

What I mean is, if a some server sends a message containing 2^80 as a
maximal allowed nonce, the client MUST NOT treat it as 0 (as 2^80 mod 2^32),
but rather, client may freely treat it as one of 2^64-1, 2^63-1,
2^32-1, 2^31-1 or
10000 or 9999 or any other possible values which make sense.

> • 7: "tls-cert": this is the *server* certificate, right? I.e. neither a
> client cert nor a CA cert.

It's server cert.

> • 7: why not use RFC 5705 to bind to the TLS session?

Please refer my sepalately summarized answer for this, too.

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

Yes, but we need more complex requirement for secure handling of POST requests.

> • 8: what do you mean by "non modal"?

Oops, some editing error here (lacking reference for the other draft).
It's a keyword value defined in the Auth-extension draft.

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

Yes, I mostly agree.  A small nits exists around here, so I will
rethink of this within the context about the extension document.
(We have some situation where 401 and WWW-Authenticate should
 always be sent, instead of the extended Optional-WWW-Authentication.)

> • 9: in Step 14, please mention explicitly that a missing VK_s is fatal.

Thank you, I'll do it.

> • 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).

OK.  I have a security model here (why mixed document is OK in this
specific case),
but I agree this is not the right place to fully discuss it.
I'm thinking of an alternative way.

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

Thank you.

> • 10: IMHO management of invalid ("fake") session is an implementation
> detail, and out of scope of this document.

Hmm, however, disregarding this case seems to be critical vulnerability
in the security community...  If there is more simple way to write it,
I'll seek for it.

> • 13: what is "m. m."?

!? seems to be a typo, sorry.

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

Simple answer to this is, this protocol can protect some existing origin scope
(authenticating a single content inside a protected domain will ensure
that the whole content is (in some way) trustful), however,
if there is a mixed-content between Mutual-protected and non-authenticated
contents in the unauthenticated TLS server, Mutual itself cannot establish
a secure scope.

> • 16.3, last bullet: salting the password with the user name is much better
> than plain hashing of the password.

Yes.  In this text, J(pi) and pi (and ph when the hash is digest-md5) are
salted with the user name.

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

Thank you.

> draft-oiwa-httpauth-mutual-algo-00

> • Appendix A: there are good reasons to use already existing MODP groups.
> Can we do that?

Parameters in Appendix A (Informative) is just copies of existing groups in
RFC3526.  We repeated this just because the original specification does
not contain the value of r (mathematically derived from q and g).

The value of r is a divisor of (q-1), and it is better to be as large
as possible.
The possible largest value is (q-1)/2,
but not all possible prime q will have this value as r.

If we want to use more other MODP groups, we may simply define a
new algorithm name with a new parameter, with having respective value of
r to be calculated.

> • I think the document should define one method as "mandatory to implement".

OK.  I prefer dl2048 in this case.

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

Thnak you.

> • 4: Authentication-Control - this header should be associated with a
> particular session rather than with an authentication scheme.

I agree, and under RFC2617, we need (at least) to add "realm" here.

> • 4.2: If the parameter MUST be absolute, I don't understand why the
> following sentence discusses what happens if it isn't absolute.

Maybe I should rewrite to "servers MUST send ..." and "clients SHOULD
treat ...".

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

It's also interesting, I think.

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

My design is:
Servers can initiate logout by sending "Logout-timeout=0".
Clients can always make a logout by simply forgetting a credential
(and the Location-when-logout parameter is for better application-level UI
behavior in this case).
Only the case to be handled explicitly is about the termination of
client-side stored session after that these peer have no communication for
the idle time.
(clearing server-side cache is not enough in HTTP authentication,
 because clients will simply re-authenticate itself to the server
(think of Basic auth behavior).)

More precise control can also be achieving by using Cookies or
some other new session continuation mechanism with complex control on
server side (implemented in all possible Web resources), and "Logout-timeout=0"
parameter in this extension is also useful in this case
for clearing client-side session from the server side.

-- 
Yutaka OIWA, Ph.D.                 Leader, System Life-cycle Research Group
                               Research Institute for Secure Systems (RISEC)
     National Institute of Advanced Industrial Science and Technology (AIST)
                       Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]