Subject: Re: [http-auth] review of (most of) mutualauth

From: Yutaka OIWA <[email-masked]>
Date: Mon, 7 Oct 2013 18:54:00 +0900

Dear Stephen,

Really thank you for very detailed review.
It seems quite helpful to me.

2013/9/1 Stephen Farrell <[email-masked]>:

> (1) The IPR declaration on the earlier non-WG drafts
> should be updated for this draft and/or the
> "replaced-by" information needs to be updated. It is not
> enough to include a section within the draft since that
> may not be noticed at IETF LC time. And FWIW, I'd
> personally guess that the existence of the IPR will be a
> negative in terms of the probability that this gets
> wider adoption.

Thank you, I'll check the IPR status again.

> (2) draft-oiwa-httpauth-mutual-algo needs to be at least
> a normative ref and a wg draft as well.  That draft
> should get as much review as this one, however that's
> done, since the whole thing depends on the security of
> that draft. Its not possible to evaluate the security of
> this draft without reviewing that one. (Which I've not
> yet done since I'm not sure of its current status.)

My personal plan is to ask this to be WG draft too, I'll ask it for WG.
Another, alternative option is to merge two drafts.

> (3) The draft has far too much sales-pitch and that
> needs to be fixed. I fully understand why that text is
> there and including it was appropriate when this draft
> was facing a lonely uphill battle to become an RFC. But
> that's no longer the case - now we have a WG all such
> text ought be removed I wouldn't be surprised if this
> takes more than one iteration to fix as there is a lot
> of sales-pitch text.  I note some but not all of these
> in the detailed comments below.

I completely agree that we do not need it anymore.
I will greatly simplify the Section 1.

> (4) The claim that this "prevents" phishing is not
> justifiable - one can still mount phishing attacks on
> any password based scheme, regardless of the protocol
> used to transmit the password-derived authenticator.
> (Including "common" in "prevents common phishing
> attacks" does not make this ok.)
>
> (5) Following up from (4), it doesn't matter if the user
> can detect the phish after the password has been
> compromised - that's too late.

I'd like to have a separation discussion here on (4) and (5),
but I think it's better to have this discussion on another places,
either as a technical report or a companion, not
normative-intended (informational?) I-Ds.
I understand that my claim for phishing protection has
several assumptions including UIs and server operations,
which I've failed to be well discussed within this document
in the protocol specification style.

> (6) I don't think "Mutual" is a good name for this HTTP
> auth scheme - "mutual" describes a property of many
> potential schemes and isn't really specific enough.
> Note: This is a minor point, easily outweighed by any
> substantive deployment and/or multiple implementations
> (but not by one implementation).

OK.  One of my intention was that
the core part of this document can become a common
platform for implementing potential similar schemes
which require two-way key sharing,
with sharing large part of the implementation.

> (7) I don't get how the HTTP server maintains state
> between requests 3 and 6 in Figure 1. How does that
> work? It seems counter to normal HTTP to me at least,
> but then I don't know much about HTTP.

Short answer is that it's the parameter "sid" in
messages (4) and (6). It is somewhat similar to nonces in the Digest.
In Digest, the nonce parameter serves both as the
session management identifier and as the cryptographic parameter.
In Mutual, these two functionalities have separated to
two separate fields.
More detailed specs are in the later sections of the draft.

> (8) I would worry that attackers could exploit the
> potential for playing about between messages 3 and 6 in
> Figure 1. Do we have any papers or other reason to think
> they cannot?

Only the possibilities to play around, as far as I know, is
to send many (3) requests to fill the server's session tables.
This attack is common to all two-round trip (or more) authentications
including the existing Digest scheme.
(Of course, this is mentioned in the security consideration section.)

> (9) 4.1: the choices for pwd-hash are outdated - do we
> really want md5 and sha1 as choices in new protocols?
> The comment applies even if these are not security
> criticial - the only acceptable reason to have those IMO
> would be to meet some legacy interop requirement which I
> don't believe applies here.

> (10) Defining an "authenticaion realm" concept that is
> not the same as the standard web-origin seems like a
> mistake. In particular, the wildcard concept, if it
> differs from web-origin is a bad plan and if its the
> same, then why not just use what exists already?

Please refer to my answers to the common questions which was sepalately post.
I summarized the answers to the above two questions.

> (11) 5.1 talks about "path" parameters but those were
> not mentioned in the earlier text in section 5. I don't
> know how to intepret that. (I also find 5.1 quite
> unclear.)

For comment inside (...), I'll simply try to rewrite it more clearly.
The path parameter mentioned is that in Section 4.

> (12) Section 7 should really use TLS channel binding and
> not re-invent that. In any case, code implementing this
> might not have visibility inside the TLS library and so
> should not require such layering violations.

This is also a question which was raised from many peoples.
I sent my answer separately, too.

> (13) 7: Why just the server cert and not the entire cert
> path? What about TLS raw public keys? What about DANE?

Given that TLS negotiation is succeeded correctly, and that
server certificate is verified in some way outside HTTP layer
(regardless of the way of verification), what we need to be verified
is just the public key (corresponding to a single secret key).
We may need some mention for TLS raw public key used with
draft-ietf-tls-oob-pubkey (referring corresponding TLS channel binding scheme).
For DANE, I think we do not need any additional measure
as far as TLSA in RFC6698 is used.

I continue to answers to some of
> nits/minor comments:
as follows:

> - abstract: getting the HTTP acronym correct here would
> be good. (s/Transport/Transfer/) Could be this is due to
> the same error having being made in the WG charter
> earlier.

Oops.

Skipping many comments on introductions which I largely agree on,

> - 1.2, I'd say its unwise to define new 2119-like terms,
> so I'd drop the definition and uses of encouraged and
> advised.

I really have a problem here.
Is there a good stylistic example of saying
"something is better to do" without saying it a strong
"SHOULD" requirement as in IETF document,
but not "MAY" which is too weak as plain English.
# I saw in the other place than IETF,
# where normative SHALL and non-normative SHOULD
# is considered differently.
# My intention is like "SHOULD" in such conventions.

> - 4.1, the "reason" responses seem a bit verbose - why
> do you need to provide so much detail here and why isn't
> HTTP status sufficient?

HTTP status is not sufficient here for most of these
(most of them are not distinguishable as HTTP statuses, but
 degenerating to 401 responses).
I'd provided these for possible benefit for user-friendly clients.
As just a simple protocol, significant ones are "stale" and others.

> - 4.2 (and elsewhere), multiple version fields seems
> like a bad plan

As far as it is under changing draft status, including versions
in all messages are ugly but required.
Recipient servers will first look the scheme "Mutual",
and then the "version" parameter, and then do the jobs.
If we decide that future incompatible revision of this protocol
should be named "Mutual2" (or something distinguishable in
the scheme parameter), we may drop this parameter in the
final version of this experimental document.
My current proposal is to replace it to "1" in the final publication.

> - 5: "SHOULD NOT automatically reuse" seems odd - when
> would it be ok to do that? If never, then s/SHOULD NOT/
> MUST NOT/ would be right.

MUST NOT may be appropriate in most cases.
A very small reason to specify this as "SHOULD NOT" is
for simple command-line-style clients which only receive
user name and password without knowing which realm to apply to.

> - 6: sessions being local to a "server" seems like an
> odd thing to say - why can't servers load balance? If
> this were to gain traction, that'd have to be changed.

Hmm, the "server" here means the thing which seems to be a single server
from the client side, as described as "(defined by scheme, host and port)".
It is equivalent to the same "web-origin" as in RFC 6454.
We may seek for a better replacement term here.

What this phrase exactly means is somewhat like the following scenario:

1) The user accesses "https://login.example.com/" and authenticate with
    realm="R", path="/", auth-realm="*.example.com".
    A new shared-key session (only for key management) is created and
    a session ID "sid" is assigned.

2) The user accesses "https://login.example.com/welcome.html".
    The session established in 1) may be active, so the client may try using
     shared key associated with the session (short-cut method in
Figure 2 (B-1).)

3) The user accesses "https://portal.example.com/".
     In this case, as this request points to the different origin, the client
     cannot use the same session as one in 1), and sends an
unauthenticated request.
     However, if the portal server respond with 401 response with
     realm="R", path="/", auth-realm="*.example.com".,
     the credentials provided from the user in 1) is valid for this server
     and the client can automatically authenticate to this new server.

-- 
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]