Subject: Re: [http-auth] Review of MutalAuth

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

Deal Ilari,

Thank you very much for the detailed review.
Here is the answers to your questions.

2013/8/30 Ilari Liusvaara <[email-masked]>:
> Main mutualauth spec:
>
>>   implementations for user authentication using HTML Forms and Web
>>   browser rendering engines.  However, that method has many potential
>>   security weaknesses as same as the HTTP Basic authentication as it
>>   uses plaintext.  Considering server-impersonations and existence of

> I can't parse this... I can see it asserts that there is substantial
> overlap of vulernabilties between forms and HTTP Basic (true).
>
> But, does it assert one has all the vulernabilies of the other
> (superset), the same vulernabilties (equivalence) or just substantial
> overlap?

We do not have strong intention on asserting any subset-relation
between two technologies here.  In simple protocol-level-only discussion,
HTML form authentication may have all vulnerabilities of Basic auth,
but there are also some Web-level mitigations (such as personalized
sign-in seal) which can only be done with HTML form authentication.

>> still relying on the HTTPS for the integrity and secrecy of the HTTP
>> payload.  This protocol ensures users the integrity and secrecy of

> Perhaps s/secrecy/confidentiality/g ?
Thanks. Its clearer.

>>   All character strings outside ASCII character sets MUST be encoded
>>   using the UTF-8 encoding [RFC3629] for the ISO 10646-1 character set
>>   [ISO.10646-1.1993], without any leading BOM characters.  Both peers

> Why mention of ASCII? It is strict subset of UTF-8 anyway.

I see.  I noted "outside ASCII character sets" because there is
currently a confusion around non-ASCII character encoding in HTML
but not around ASCII characters.
But you're correct: "outside ASCII character sets" is
just technically redundant.

>>    base64-fixed-number = 1*( ALPHA / DIGIT /
>>                          "-" / "." / "_" / "~" / "+" / "/" ) *"="
>
> Err, mixing multiple Base64 variants? And what are "~" and "."
> (couldn't find in linked RFC)?

The only reason is that it is equivalent to
"token68" syntax in httpbis-p7 (which had an original name
b64token), whose parser may already
be included in HTTP implementations.
Solution is either to reduce it to strict base64, or to
refer token68 in httpbis-p7, whichever seems appropriate.

>>   o  For requests, the parameters "kc*" (where * stands for any decimal
>>      integers), and "vks" are mutually exclusive and any challenge
>>      MUST NOT contain two or more parameters among them.  They MUST NOT
>>      contain any "ks*" and "vks" parameters.

> The first "vks" is supposed to be "vkc"?

You're correct.  I'll fix it.

>>   version:       (mandatory extensive-token) should be the token "-wg-
>>                  draft00" in this specification.  The behavior is
>>                  undefined when other values are specified.

> Add some note for RFC editor to replace the value (for the final RFC)?

I'll do it.

>>   auth-domain:   (non-mandatory string) specifies the authentication
>>                  domain, the set of hosts for which the authentication
>>                  credentials are valid.  It MUST be one of the strings
>>                  described in Section 5.  If the value is omitted, it
>>                  is assumed to be the "single-port" type domain in
>>                  Section 5.

> There is no "single-port" type in section 5. You mean single-server type?

Yes.  It was renamed in section 5 to single-server type.

>>   pwd-hash:      (non-mandatory extensive-token) specifies the hash
>>                  algorithm (hereafter referred to by ph) used for
>>                  additionally hashing the password.  The valid tokens
>>                  are
>>
>>                  *  none: ph(p) = p
>>
>>                  *  md5: ph(p) = MD5(p)
>>
>>                  *  digest-md5: ph(p) = MD5(username | ":" | realm |
>>                     ":" | p), the same value as MD5(A1) for "MD5"
>>                     algorithm in [RFC2617].
>>
>>                 *  sha1: ph(p) = SHA1(p)

> None produces a octet string, whereas others produce integers.
> Perhaps add some OCTETS() into right places.

Thank you.  I'll review again for all relevant things around hash co-domains.
I remember I changed some definitions around hash co-domains in the past,
and there seems to be inconsistencies remaining to be fixed.

>>   In the above specifications, every "scheme", "host", and "domain"
>>   MUST be in lower-case, and any internationalized domain names beyond
>>   the ASCII character set SHALL be represented in the way they are sent
>>   in the underlying HTTP protocol, represented in lower-case
>>   characters; i.e. these SHALL be in the form of the LDH labels in IDNA
>>   [RFC5890].  All "port"s MUST be in the shortest, unsigned, decimal
>>   number notation.  Not obeying these requirements will cause failure
>>   of valid authentication attempts.
>
> What about when dealing with DNS-SD? That uses native UTF-8 on the wire
> instead of Punycode. I have no idea how HTTP host names are represented

Interesting indication here, and it seems to be an HTTP issue.
I think that encoding Host: part in an IDN-way in HTTP is at least "de-facto"
standard now, but do anyone know where it is defined?
RFC 3986 defines percent-encoding of UTF-8 characters in the host part
for uniform representation "independent of the underlying name resolution
technology" but it also recommends to generate IDNA-encoded URIs.

>>   tls-key:       TLS shared-key validation: The value v will be the
>>                  octet string of the shared master secret negotiated in
>>                  the underlying TLS (or SSL) connection.
>
> Any reason to deviate from tls-unique of RFC 5929 (Standards Track), which
> uses latest finished message instead?

I answered it separately as "an answer to FAQ".

>>   pi = H(VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username) |
>>   VS(ph(password))).
>
> VS(ph(password))) is ill-defined if pwd-hash is not none, as it then
> tries to apply VS to an integer.

Output of ph will be an octet string (as I'll fix the issue above).

>>   existing sessions regardless of these statuses.  One way to mitigate
>>   such attacks are that servers MAY have a number and a time limits for
>>   unverified pending key exchange requests (in the "wa received"
>>   status).
>
> "wa received"???

Correctly, it's "key exchanging" (I renamed this in the past, too.)
Thank you, I'll fix it.

> Auth extension:
>
>>   The value of this parameter MUST be a string that contains an
>>   absolute URL location.  If a given URL is not absolute, the clients
>>   MAY consider it a relative URL from the current location.
>
> Err... X MUST be Y, but if X is not Y...

Is it better if I write "Senders MUST must send X as Y.
Recipients MUST consider X as Z if it isn't Y"?.

>>   When the user requests to terminate an authentication period, if the
>>   client supports this parameter but the server response does not
>>   contain this parameter, the client's RECOMMENDED behavior is as
>>   follows: if the request corresponding to the current content was
>>   idempotent (e.g.  GET), reload the page without the authentication
>>   credential.  If the request was non-idempotent (e.g.  POST), keep the
>>   current content as-is and simply forget the authentication status.
>>   The client SHOULD NOT replay a non-idempotent request without the
>>   user's explicit approval.

> Should it replay PUT or DELETE (or LINK/UNLINK)? Those methods are
> idempotent.

Oh, interesting point, too.  If there are any "interactive clients"
which sends PUT/DELETE interactively, these should be excluded.
Do you know better term other than just saying it a "GET" or "idempotent"?
(note: XMLHTTP and WebDAV are not "interactive" in the scope of
this document.)

>> 7.  IANA Considerations
>
> Optional-WWW-Authenticate registration?

We may need it before the finalization.

> Mutualauth algo:
>
> Is there a security analysis of (this version of) KAM3? In practicular,
> considering various mathematical attacks and establishing a lower bound
> on difficulty (e.g. Attack X is at least as hard as CDH on the group and
> so on)?

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