Subject: [http-auth] WGLC for draft-ietf-httpauth-hoba-04

From: Yoav Nir <[email-masked]>
Date: Mon, 22 Sep 2014 08:48:58 +0300

Hi all

Stephen, Paul, and Michael submitted version -04 about a month ago, and it has received no discussion so far.  The authors are of the opinion that the document is ready for publication, and it’s time for the group to weigh in on this subject.

This mail begins working group last call for this document. Please take the time to read the draft and send comments to the list about its security, applicability, usefulness, and any other aspect you wish to discuss. For guidance on what to look for, let me quote the following from our charter:
  The httpauth WG will be a short-lived working group that will document
  a small number of HTTP user authentication schemes that might offer
  security benefits, and that could, following experimentation, be
  widely adopted as standards-track schemes for HTTP user
  authentication. Each of these RFCs will be Informational or
  Experimental, and should include a description of when use of its
  mechanism is appropriate, via a use-case or other distinguishing
  characteristics. 
The WGLC is two weeks long, and ends on October 6th. Please send your reviews as replies to this message.

Thanks,

Yoav & Matt

---

From: Michael Sweet <[email-masked]>
Date: Mon, 22 Sep 2014 15:26:59 -0700

Comments for:

    https://tools.ietf.org/html/draft-ietf-httpauth-hoba-04

- In section 1 (introduction), the following text is awkward to read:

    Current HTTP authentication methods (Basic and Digest), as well as
    username/password authentication using web forms, have been in use
    for many years, but being based on passwords, are susceptible to
    theft of server-side databases.

  The following is my suggested rewording:

   Current username/password authentication methods such as HTTP Basic,
   HTTP Digest, and web forms have been in use for many years but are
   susceptible to theft of server-side password databases.

- Also in section 1:

    Session management with HOBA is identical to username/password
    session management.  Typically, the session management tool (such as
    PHP, Python CGI, and so on) inserts a session cookie into the output
    to the browser.  HOBA does nothing to help or hurt session cookie
    hijacking; TLS is still required for that.  If the authentication is
    not bound to HTTP sessions, even TLS cannot help against all attacks.

  might read better as:

    HOBA session management is identical to username/password session
    management, with a server-side session management tool or script
    inserting a session cookie into the output to the browser.  HOBA
    still requires TLS to prevent session cookie hijacking.

- And here in section 1 aren't you talking about revoking keys?

   o  Users are also likely to lose a private key, or the client's
      memory of which key pair is associated with which origin, such as
      when a user loses the computer or mobile device in which state is
      stored.  HOBA allows for clients to tell servers to delete the
      association between an existing CPK and an account.

- This text in section 1 is also awkward/confusing:

   o  Since there are always devices and applications in which state of
      the art digital signature mechanism runtimes are significant, and
      since HTTP authentication in theory requires that every HTTP
      request to a given realm have a signature in an "Authorization"
      header field, and since HOBA is a challenge response scheme, we
      also define a way in which HTTP servers can indicate the duration
      for which they will consider a given challenge value to be valid.
      As a consequence we also define a way for UAs to fetch a fresh
      challenge.

  Perhaps reword as:

   o  Digital signatures can be expensive to compute, so HOBA defines a
      way for HTTP servers to indicate how long a given challenge value is
      valid, and a way for UAs to fetch a fresh challenge at any time.

- Section 1.1, drop "in which this can be done" from the third line.

- Section 1.2 is a mix of styles, consider making it "Term: definition" throughout, and separate HOBA-js and HOBA-http.

- Section 1.2 is missing a reference to HTTP authentication specification (which do you mean?)

- Section 1.2: The statement "This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]" probably doesn't belong here, unless you want to define ABNF as a term (in which case make it ABNF: definition [RFC5234])

- Figure 1: Shouldn't the unreserved values actually be base64url values?

- Figure 2: Ditto here - base64url encoded?

- Section 3: If this is a valid security concern, change to "the challenge MUST be unique for every HTTP 401 response ..."

- Section 4, top of page 9: Something is missing betweem "from HTML5." and "is used".

- Section 4, not sure I like the raw URL references - better to make them informative or normative references (as appropriate). Also, since WebCrypto is not available I'm not sure it is appropriate to mention it here - maybe move this to an  appendix that outlines some potential future enhancements based on in-progress work.

- Section 3: Is it ".well-known/hoba/getChal" or ".well-known/hoba/getchal" (lowercase), as it appears in section 6.4?

- Section 8: If reuse of challenge values (section 3) stays a SHOULD NOT, then it should be added here in more detail as to why this can be problematic.

- Section 9.4: Extra "i" after "ok."

- Section 10: Don't deleted sections go at the end to make the RFC Editor's job easier and to avoid broken references?

> On Sep 21, 2014, at 10:48 PM, Yoav Nir <[email-masked]> wrote:
> 
> Hi all
> 
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Julian Reschke <[email-masked]>
Date: Tue, 23 Sep 2014 09:10:55 +0200

On 2014-09-22 07:48, Yoav Nir wrote:
> ...

I had a look from an editorial and HTTP related angle (me no security 
person):

- it seems that the reference to RFC 7235 needs to be normative

- in the IANA sections, it would be helpful if the specification links 
would be more specific

- there's a "TBD" in Section 9.3

- for the new IANA registries, I believe you ought to specify the actual 
format of the registry and/or provide a registration form

- terminology confusion: Section 2 introduces the "authentication 
scheme" (which seems to be about HOBA in general), but the actual HTTP 
authentication scheme is defined in Section 3.

- TODO in Acknowledgements: "[[ and any more to be added ]]"

Finally some comments on Section 3:

This describes behavior, but reads a bit strange as a formal definition 
of an auth scheme. For instance:

> If the "HOBA" scheme is listed, it MUST be followed by two or more auth-param values.

Replace by:

"The HOBA scheme has two REQUIRED attributes (...) and one OPTIONAL 
attribute (realm) described below:"

Also, a full HTTP request/response exchange example might make this 
simpler to understand.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 23 Sep 2014 13:57:10 +0200

Furthermore, Section 9.6 tries to IANA-register the header field 
"HOBAREG" which doesn't seem to be defined anywhere.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 24 Sep 2014 13:53:59 +0200

...also:

>    o  An "expires" attribute MUST be included that specifies the number
>       of seconds from the time the HTTP response is emitted for which
>       responses to this challenge can be accepted.

HTTP caching (RFC 7235) knows the "Expires" header field (taking a 
date), and the "max-age" cache-control directive (taking seconds). Maybe 
it would make sense to rename this one to "max-age" for consistency.

Best regards, Julian

---

From: Yoav Nir <[email-masked]>
Date: Sun, 28 Sep 2014 00:37:00 +0300

Forwarding to the http-auth mailing list where this LC is happening.

On Sep 23, 2014, at 9:35 AM, Amos Jeffries <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 23/09/2014 9:50 a.m., Mark Nottingham wrote:
>> FYI; please have a look over this with an HTTP eye (and note that
>> the intended status is Experimental).
>> 
>> <https://tools.ietf.org/html/draft-ietf-httpauth-hoba-04>
>> 
>> Cheers,
>> 
>> 
>> Begin forwarded message:
>> 
>>> From: Yoav Nir <[email-masked]> Subject: [http-auth] WGLC
>>> for draft-ietf-httpauth-hoba-04 Date: 21 September 2014 10:48:58
>>> pm PDT To: IETF HTTP Auth <[email-masked]> Archived-At:
>>> http://mailarchive.ietf.org/arch/msg/http-auth/3B6SxPqTEQ6KadDvXMDmqQhZEiQ
>>> 
>>> 
>>> 
> Hi all
>>> 
>>> Stephen, Paul, and Michael submitted version -04 about a month
>>> ago, and it has received no discussion so far.  The authors are
>>> of the opinion that the document is ready for publication, and
>>> it’s time for the group to weigh in on this subject.
>>> 
>>> This mail begins working group last call for this document.
>>> Please take the time to read the draft and send comments to the
>>> list about its security, applicability, usefulness, and any other
>>> aspect you wish to discuss. For guidance on what to look for, let
>>> me quote the following from our charter: The httpauth WG will be
>>> a short-lived working group that will document a small number of
>>> HTTP user authentication schemes that might offer security
>>> benefits, and that could, following experimentation, be widely
>>> adopted as standards-track schemes for HTTP user authentication.
>>> Each of these RFCs will be Informational or Experimental, and
>>> should include a description of when use of its mechanism is
>>> appropriate, via a use-case or other distinguishing 
>>> characteristics. The WGLC is two weeks long, and ends on October
>>> 6th. Please send your reviews as replies to this message.
>>> 
>>> Thanks,
>>> 
>>> Yoav & Matt _______________________________________________ 
>>> http-auth mailing list [email-masked] 
>> -- Mark Nottingham   http://www.mnot.net/
>> 
> 
> Looks like the HTTP specific part is almost a duplicate of RFC 6750
> OAuth 2.0 Bearer authentication.
> 
> One could re-write this specification by doing:
> 
> * reference Bearer specification,
> * add expires= and challenge= (code=?) parameters on www-auth header,
> * add a scope parameter value "hoba:origin",
> * prohibit token re-use/replay,
> * prohibit URI-query and payload delivery mechanisms
> * define section 5 and section 6 using RFC 6749 credential management
> parameters and mechanisms.
> 
> Doing so would avoid both the need to register a new authentication
> scheme, and "well-known" URI space.
> 
> Amos
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
> 
> iQEcBAEBAgAGBQJUIRTPAAoJELJo5wb/XPRjHtcH/RSHv9Zg9YUnZw3q2Q/lsobX
> xa8cvK1LrEjrtlEBGG+R3I8G5y4WDNqhowEsbHk1hMv2Kn+WN1ZCmzSM32KWBd+X
> HalPfFlWvIctKd/M2uVe9DBXJS6GLVAGR1YhY2siBMN3G2umOgf2TCgS70NnXwVq
> W2o7xhvYwBpX1NjrxOEQTYG7B7HDYUM1oVXGjXMTjt0GhAopIS8xXXkXrxqS82kG
> gdZQ1EFfyci3TJD17zvbpGBhTEjT/ZTD5B8DY/2trdLq3MZ7FvSDBtoUwi1Ornm8
> EMFnr/8kldKG+77xqSNrfBlBnUqWfEI+epzFqKBD9wdaHVn0JE9RR+XL/7SngN0=
> =gNel
> -----END PGP SIGNATURE-----
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 29 Sep 2014 14:54:39 -0400 (EDT)

On Mon, 22 Sep 2014, Yoav Nir wrote:

> Hi all
>
> Stephen, Paul, and Michael submitted version -04 about a month ago, and
> it has received no discussion so far.  The authors are of the opinion
> that the document is ready for publication, and it’s time for the group
> to weigh in on this subject.
>

I see a few places that could be unclear, and have a handful of editorial
comments.

In section 2,

   On receipt of a challenge (and optional realm) from a server, the
   client marshals an HOBA to-be-signed (TBS) blob that includes a
   client generated nonce, the web-origin, the realm, an identifier for
   the CPK and the challenge string; and signs that hashed blob with the
   private key corresponding to the CPK for that web-origin.

The client is supposed to marshal a blob, but then signs a hashed blob.
How does the hashing happen (or is it part of the signature)?

Still in section 2,

   The value that is sent over the network is the HOBA "client result"
   which we now define.

It might be good to explicitly say that this is sent over the network by
the client.

In section 3, we hear that the HOBA scheme "MUST be followed by two or
more auth-param values."  It might be useful to include here an example of
how those attributes are encoded.

And the editorial bits:

In section 3,

   the client to authenticate with HOBA.  Note that the HOBA auth-scheme
   might not be the only one that the server includes in a WWW-
   Authenticate.

I think that "a WWW-Authenticate header" is better grammar, unless this is
some usage I'm not familiar with.

Still in section 3,

   When the "client response" is created, the UA encodes the HOBA
   client-result (a string matching the HOBA-RES production in Figure 2
   as an auth-param with the name "result" and returns that in the
   Authorization header.

There is no matching close parenthesis.

In section 4,

   storage.  For example, an implementation would store a dictionary
   account identifier, public key, private key tuples in the origin's
   localStorage for subsequent authentication requests.

I don't think the grammar is correct in the specification of the contents
of the tuples stored in localStorage.

Also in section 4,

   available: WebCrypto (see http://www.w3.org/TR/WebCryptoAPI).  In
   lieu of WebCrypto, JavaScript crypto libraries can be employed with
   the known deficiencies of PRNG, and the general immaturity of those
   libraries.

The grammar is not correct in this sentence.

In section 5.1,

   In the CPK preparation phase, the client determines if it already has
   a CPK for the web-origin it is going to.

Reading this, I want to ask "what is the client going to do?", that is,
the language feels informal to the point of causing confusion.

In section 9.3,

   TBD, hopefully re-use and existing registry

s/and/an/

In section 9.4,

   "1" means a URI, such as a mailto: or acct: URI, but anything
   conforming to [RFC3986] is ok.i

The trailing 'i' was already mentioned, but I would consider expanding out
"okay" or using less-informal terminology.

Throughout section 9 in general, the list entries are inconsistent about
whether they end with a period or not.

-Ben

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Sep 2014 21:32:57 +0100

Hi all,

Apologies for not responding to the good comments sent so far
but I hope to get time for that this week. (And if the chairs
want to prolong the WGLC accordingly on the basis of tardy
author responses that'd be quite reasonable:-)

Cheers,
S.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 30 Sep 2014 10:30:54 +0300

> Apologies for not responding to the good comments sent so far

Yeah, I was going to comment on that…

> author responses that'd be quite reasonable:-)

I don’t see a need for that. There are obviously some points raised that need discussing, and I don’t think all of them will be sorted out to everyone’s satisfaction by next Monday. So this is more “get people to finally read the draft” WGLC rather than a real last call. So discussion will continue on the list, and if needed, we’ll also spend time on it in Honolulu.

Thanks.

Yoav