Subject: [http-auth] Proposed Virtual Interim Meeting about MutualAuth

From: Yoav Nir <[email-masked]>
Date: Wed, 28 Aug 2013 08:36:43 +0000

Hi all

Of all the experimental proposals, MutualAuth has been around for the longest time. There is running code ([1],[2]) and documentation for years. While it is not deployed in either commercial products or popular open source projects, this is the best that we can hope for in terms of maturity for the documents that this group is working on.

With that in mind, we would like the reviews of the MutualAuth proposal to begin now. Those who committed to review this, please send your comments to the list within the next few weeks, and others are welcome to do so as well.

We would also like to hold a virtual interim meeting early October. Time of day is difficult, because we truly are an international group. 8:00 AM in California is OK for Europe but is midnight in Japan. That (1500 UTC) still looks to me like the least combined pain proposal. If others feel differently, please let me know. For date, I'm thinking Tuesday, October 8th. 

If this conflicts with someone who wants to participate, please let Matt and I know soon, because interim meetings (even virtual ones) have to be announced a month in advnace. 

Also, if you plan to attend, please let us know. We are talking about a virtual interim meeting, so the technology is probably going to be a PSTN conference call. Details will be sent later on.

Thanks,

Matt & Yoav

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 29 Aug 2013 19:42:59 +0300

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?

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

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

>    base64-fixed-number = 1*( ALPHA / DIGIT /
>                          "-" / "." / "_" / "~" / "+" / "/" ) *"="

Err, mixing multiple Base64 variants? And what are "~" and "."
(couldn't find in linked RFC)?

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

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

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

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

>   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
in that case.

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

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

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

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

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

> 7.  IANA Considerations

Optional-WWW-Authenticate registration?

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

-Ilari