Subject: [http-auth] I-D Action: draft-ietf-httpauth-mutual-00.txt

From: [email-masked]
Date: Mon, 01 Jul 2013 07:03:19 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF.

	Title           : Mutual Authentication Protocol for HTTP
	Author(s)       : Yutaka Oiwa
                          Hajime Watanabe
                          Hiromitsu Takagi
                          Boku Kihara
                          Tatsuya Hayashi
                          Yuichi Ioku
	Filename        : draft-ietf-httpauth-mutual-00.txt
	Pages           : 53
	Date            : 2013-07-01

Abstract:
   This document specifies a mutual authentication method for the Hyper-
   text Transport Protocol (HTTP).  This method provides a true mutual
   authentication between an HTTP client and an HTTP server using
   password-based authentication.  Unlike the Basic and Digest
   authentication methods, the Mutual authentication method specified in
   this document assures the user that the server truly knows the user's
   encrypted password.  This prevents common phishing attacks: a
   phishing attacker controlling a fake website cannot convince a user
   that he authenticated to the genuine website.  Furthermore, even when
   a user authenticates to an illegitimate server, the server cannot
   gain any information about the user's password.  The Mutual
   authentication method is designed as an extension to the HTTP
   protocol, and is intended to replace the existing authentication
   methods used in HTTP (the Basic method, Digest method, and
   authentication using HTML forms).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-mutual-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 6 Jul 2013 19:05:53 +0300

> 	Filename        : draft-ietf-httpauth-mutual-00.txt

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

The reference to ASCII seems unnecressary, since UTF-8 is true super-
set of ASCII.

2) "Both peers are RECOMMENDED to reject any invalid UTF-8 sequences
that might cause decoding ambiguities (e.g., containing <"> in the second
or later byte of the UTF-8 encoded characters)."

Why not reject all invalid UTF-8 sequences, at least:
- Leading/Continuation not matching what is expected.
- Overlong encodings.
- Surrogates.

3) "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" should be "vkc"?

4) " Every 401-INIT or 401-STALE message SHALL be a valid HTTP 401-status
(Authentication Required) message containing one (and only one:
hereafter not explicitly noticed) "WWW-Authenticate" header
containing a "reason" parameter in the challenge."

Only one? Makes sense in 401-STALE, but not necressarily in first
401 response (server may support number of schemes). Or is this
something unrelated?

5) "   version:       (mandatory extensive-token) should be the token 
"-wg-draft00" in this specification."

Put RFC editor note after this?

Note that this also appears in some other places.

6) "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"

This seems somewhat dangerous, since hash functions return numbers,
but this one doesn't, defintion problems can arise.

7) "path:         (non-mandatory, string) specifies which path in the
"URI space the same authentication is expected to be applied."

How is matching supposed to be done? Component-by-component prefix
match?

8) "auth-domain:   [...] If the value is omitted, it is assumed to
be the "single-port" type domain in Section 5."

There is no "single-port" in section 5. "Single-Server"?

9) "Single-host type: The "host" part of the requested URI.  This is
the default value."

Eh, isn't the default "single-port", which definitely doesn't sound
like "single-host"?

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

Master secret? Does some TLS binding specification specify binding
to be done like that?

I found some RFC regarding TLS channel bindings, the per-connection
binding is to finished message, not to master secret.

11) "The function octet(c) generates a single octet string whose code
value is equal to c."

Took me few readings to correctly parse that.

12) "pi = H(VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username) |
VS(ph(password)))."

VS() takes an octet string. What does it mean to apply it to an integer
(since apparently ph() can be integer-valued)?

13) "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? Should this be Key Exchanging?

14) Authors list

That might draw some discussion (6 authors)...

-Ilari