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

[Stephen Farrell <[e-mail]>]

Hi Barry,

(I'm sure it's obvious, but this is me-as-author responding...)

On 05/01/15 17:48, Barry Leiba wrote:
> 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....  

That's very odd. We've had a bunch of reviews and an independent
implementation (I've not done an interop though) and you're the
first to make such a comment I think. The draft assumes familiarity
with the HTTP authentication framework (RFC7235) for sure and
(100% correctly I'd say) doesn't repeat any of that as any implementer
really has to know that before they start. That's stated in the
abstract and the very first sentence of section 1 so I'm very unclear
what else is needed. And given that the responsible AD for RFC7235
was one Barry Leiba, I'm very very puzzled as to how this is not
clear to you.

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

That's all as per 7235.

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

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 blob with the
   private key corresponding to the CPK for that web-origin."

I don't see what is not clear there sorry.

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

That's in RFC 7235.

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

See above.

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

Hopefully, your forehead is already shiny:-)

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

The previous len field tells you.

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

The issue is that that function (revoke cookie) might not be available
to the HOBA code, or it might, depending on the kind of HTTP server
implementation.

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

No there's no effect on any other state I think. The point of this
is just to get a fresh challenge if the one you had has expired or
whatever.

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

Is that really DISCUSS worthy? I don't think it is. Which of
the DISCUSS criteria relate to that. Seems like a stylistic
thing to me.

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

Will check. But RFC editor would fix I'm sure. I'll fix if a -10 is
needed now.

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

I'll take that under advisement.

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

Yep, I think you're right there.

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

Wilko. I have that in my editor copy.

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

Sorry what's not clear?

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

The challenge might be shorter, or might be encoded in some other
way e.g. double encoding or something. All are reasonable, none
affect interop but we wanted to get the "at least" in there.

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

See RFC7235.

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

See RFC7235.


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

I forget TBH. I think it may be some buggy stuff seen with Basic
or Digest in the past. Or it might have been me keeping Julian as
happy as I could;-)

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

I think it's clear to be honest.

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

I'll take a look again - localStorage is needed if you do not have
WebCrypto. IndexedDB is needed if you do have WebCrypto.

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

I think it's clearer as-is to be honest.

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

It's not clear how a key identifier (kid) relates to a client public
key? (CPK) Really? A kid identifies the CPK in the nominal case. This
is crypto 101 though and ought not be there unless there's a specific
ambiguity which I don't think is the case.

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

I don't believe anyone else has had that problem. And explaining the
HTTP mechanism first seems appropriate here as that is the core thing.

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

Even though nobody else has had that problem?

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

Sorry I don't see a problem.

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

I'm fine with it as-is to be honest.

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

Will look at it.

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

Nope. If signing took 2 seconds a 1 second max-age would be a problem.
And that can happen with very old JS engines. Will go away over time
and is nearly gone now. (Much moreso than when -00 of this was done.)

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

I don't get what you mean to be honest.

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

This text is for a developer, not a user. And I have been asked
about this feature a number of times by people who don't get the
not-that-hidden complexities.

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

Sorry I don't get what's unclear. The SHOULD is targetted at the DE.
The text you suggest(?) in quotes would be less clear I think.

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

Really? Are we seriously worried about there being a bazillion
key id algs or device id types in an experimental RFC? I am not.

Cheers,
S.


> 
>