[http-auth] Barry Leiba's Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT)

["Barry Leiba" <[e-mail]>]

Barry Leiba has entered the following ballot position for
draft-ietf-httpauth-hoba-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Point 1:
I find the document to be really unclear about who does what with which
and to whom and....  I gather that what happens is that the challenge is
sent as part of the www-authenticate header, and that the client sends a
HOBA-RES back to the server in an authorization header.  I don't see the
point of the HOBA-TBS at all: it looks like it's that the "sig" in the
HOBA-RES is a signed version of the HOBA-TBS, but I don't see anything
that says that clearly.

This document would benefit from some section somewhere giving a set of
clear, numbered steps, saying who sends, who receives, and who does what
with what input at each step.  I don't find Section 5 to be doing that at
all.  "the client authenticates by signing a blob of information as
described in the previous sections," still leaves me wondering what blob
was signed, and sent how. And yes, I see that "blob" is used elsewhere,
but it's not a technical term.

Some other, easier-to-deal-with things for discussion, some of which
might just involve small clarifications (or an explanation to me that
results in my slapping my own forehead):

-- Section 2 --

In the ABNF for HOBA-TBS, is something supposed to be between the
elements?  If not, how do I know when the base64 value for nonce ends and
the length value for alg begins?

-- Section 6.3 --

   The server SHOULD also revoke or delete any cookies associated with
   the session.

Why is that not MUST?  How good is a "logout" if stolen cookies from that
session can still be reused?

-- Section 6.4 --

Protocol: does asking for and getting a new challenge affect the session
state?  The document should be clear about what happens, rather than just
saying that the client can ask for a new challenge.  Is it like a logout
and re-login?  Or what?

-- Section 8.2 --

I don't think you need to say "a la LinkedIn," and I think it's a bad
idea to have us link a company's name to a password compromise forever in
an RFC.  Especially when it's not necessary.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Minor editorial nit: you use "a HOBA" fairly consistently, but "an HOBA"
appears twice.  Oughta fix.

The abstract appears to overstate the password issue.  It'd be better for
the abstract to say that it eliminates the transmission of passwords and
their storage on the server, which are really the points.  The
introduction might expand on that a little, noting that passwords might
still be used in the user interfaces, but they would be exclusively
client-side things, never transmitted and never seen by servers.

Note that the rest of these notes were entered as I read the document
from top to bottom.  That means that some things got explained later, and
that leads to the DISCUSS point about the document's organization and
having a clear step-by-step run-through.

-- Section 2 --

The definition of "alg" says "the encoding of RSA-SHA256 is 0x30," but
the ABNF above says "alg = 1*2DIGIT", which implies "30", not "0x30".  
As I look at Section 9.3, I think I see the problem and my confusion.  I
don't think you want "a single octet" here (otherwise, how would you
encode 12 or 99?  Don't you really want something like this?:

OLD
   o  alg: specifies the signature algorithm being used encoded as a
      single octet as defined in Section 9.3.  RSA-SHA256 MUST be
      supported, RSA-SHA1 MAY be supported.  The IANA registered
      algorithm values are encoded as ASCII numbers; for example, the
      encoding of RSA-SHA256 is 0x30.
NEW
   o  alg: specifies the signature algorithm being used.  RSA-SHA256
      MUST be supported, RSA-SHA1 MAY be supported.  The IANA
      registered algorithm values (see Section 9.3) are encoded as one-
      or two-digit ASCII numbers.  For example, RSA-SHA256 (number
      0) is encoded as the ASCII character "0" (0x30), while a future
      algorithm registered as number 17 would be encoded as the
      ASCII characters "17" (0x3137).
END

For "realm", I can't really make sense of "Recall both sides know when
this needs to be there independent of the encoding via a zero length." 
Can you rephrase and/or repunctuate this (probably without the word
"recall")?

For "challenge", I'm not completely sure what the SHOULD part of this is
meaning to say:

      The challenge MUST be chosen
      so that it is infeasible to guess, and SHOULD be indistinguishable
      from (the base64url encoding of) an at least 128-bit long random
      string.

My guess is that you're saying that, say, "frxM7jEplDq" meets the SHOULD,
while "eat my shorts" doesn't (extend to 128 bits in your mind).  I get
that, but it's dicey, random-wise, because it implies that "eat my
shorts" can't come up randomly, and (here's the really dicey part) I
should refuse to use it if it does.  I wouldn't worry about this but for
the SHOULD; with the SHOULD, I'm not sure how I can be sure that I comply
with it.

This section is really unclear about who does what with which and to whom
and....  I gather that what happens is that the challenge is sent as part
of the www-authenticate header, and that the client sends a HOBA-RES back
to the server in an authorization header.  I don't see the point of the
HOBA-TBS at all. Perhaps it's that the "sig" in the HOBA-RES is a signed
version of the HOBA-TBS, but I don't see anything that says that,
anywhere.

This document would benefit from some section somewhere giving a set of
clear, numbered steps, saying who sends, who receives, and who does what
with what input at each step.  I don't find Section 5 to be doing that at
all.  "the client authenticates by signing a blob of information as
described in the previous sections," still leaves me wondering what blob
was signed, and sent how. And yes, I see that "blob" is used elsewhere,
but it's not a technical term.

-- Section 3 --

      The "realm" attribute MUST NOT appear more than once.

Does that mean that "challenge" and max-age can appear more than once? 
If not, why call it out for "realm" and not for the others?

It might be good if the description of "max-age" made it clear that it's
for the purpose of allowing multiple uses (multiple sigs).  As it is, it
looks like it's there to limit the delay before the challenge is answered
(once).  Maybe just a forward ref to Section 8 is good enough here.

-- Section 4 --

The second paragraph starts by saying that localStorage is required, and
gives a reference.  It ends by saying that localStorage is not required,
because IndexedDB works too, and it gives a reference.  That's not a
disaster, but it's sloppy, and it'd be better to say it all up front.  It
also makes me wonder whether the security considerations about attacks on
localStorage do or don't also apply to IndexedDB.

Another very minor point: I would avoid using "a hassle for users" in an
international document that non-native speakers are expected to
understand.  "Difficult for users" seems just as good and more
understandable to all.

Does the server really use session cookies to navigate around a site?  Or
does the server give the client a session cookie for the client to use to
navigate?

-- Section 5.3 --

How Does the server "recognize the CPK"?  I can't find anything that
tells me how the kid relates to the CPK.  I also don't see how the server
gets the CPK in the first place.  I realize that setting up the user's
account isn't part of HOBA, but the setup requirements need to be
explained, and I don't think they are.  The organization is also very
odd, only talking about "joining" the user after it talks about
validating the sig.

-- Section 6 --

Oh, no wait: the joining is part of the standard.  And the subsections
here answer the question I asked in 5.3 about how the CPK gets set up. 
Gaaaaa!  PLEASE reorganise this document!

-- Section 6.1 --

Why are the fields here not REQUIRED and OPTIONAL, using 2119 words, as
is the case in Section 3?

-- Section 6.2 --

It seems odd to put the NOT RECOMMENDED mechanism in the middle; I
suggest switching sections 6.2.2 and 6.2.3.

-- Section 8 --

The first paragraph doesn't say enough to make sense to me.  Perhaps a
few more words about why?

   The administrator will most likely
   want to set the max-age to something that is not too slow on the
   slowest signing device that is significant for that site.

Maybe you mean "not too short"?

-- Section 8.2 --

As to the "counter-intuitive" part, see my earlier comment about what the
introduction says about not using passwords.

-- Section 8.3 --
The chances that a typical user (consider my mother) will know or care
about this, much less will "request" anything is vanishingly small.  Can
you say anything here about what can be done that would have any
practical utility?

-- Section 9.3 --

   Please create a new HOBA signature algorithms registry as follows,
   with the specification required rule for updates.  New HOBA signature
   algorithms SHOULD be in use with other IETF standards track protocols
   before being added to this registry.

I don't think the SHOULD is really right -- who is the target?  This
needs to be cast as instructions to the designated expert, perhaps as,
"The designated expert will review other uses of requested new HOBA
signature algorithms, with particular consideration to their use in other
IETF standards track protocols."  Perhaps there's also another word or
two to say about what the DE should consider?

-- Sections 9.4 and 9.5 --
Surely, IANA (or the designated expert) will want to have some idea of
how high "small" might reasonably get.  Can you put any bound on it, even
a non-binding one?  And might there be any other advice for the
designated expert, anything at all?