HTTP Origin-Bound Authentication (HOBA)
draft-ietf-httpauth-hoba-10

Note: This ballot was opened for revision 09 and is now closed.

Barry Leiba (was Discuss) Yes

Comment (2015-01-08)
No email
send info
I have looked at the change to Section 8.2, and I think it (and the reference) is a perfect choice, and makes the document stronger.  Thank you very much for going in this direction!

------------
Remaining minor comments, left for posterity
------------

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

-- 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.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 --
Might there be any advice for the designated expert, anything at all?

(Ted Lemon) Yes

(Kathleen Moriarty) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Comment (2015-01-08 for -09)
No email
send info
Agree with Barry

(Richard Barnes) (was Discuss) No Objection

Comment (2015-01-08 for -09)
No email
send info
Old DISCUSS points:

(1) Cleared (I still think the architecture is bad and Stephen should feel bad, but I'm willing to let this go for Experimental)

(2) Cleared (SHA-1 only allowed if the platform doesn't do SHA-256)

(3) Cleared (bounds on <2048-bit keys)

-----

Given that the size of the header seems to be a concern (since you're not passing the key in the header), why are there no ECC signing algorithms defined?  It seems like if you used any of the normal curves, you could comfortably pass the key along with the authentication value.

The HOBA-TBS construction seems really unnecessarily complicated.  Other than in the "origin" component, there are no ":" characters allowed in any of the components, so if you could remove the unnecessarily pretty serialization of the origin, you could just use ':' as a delimiter.  Or leave the origin, and delimit with something like %x20.  Either way, this length construction seems like a pain to implement by comparison.

"alg = 1*2DIGIT" - In general, it seems unwise to limit code point spaces unnecessarily.

In addition to the funny title of Section 6.2.2, the contents seem kind of risible as well.  Making a OTP is 100% equivalent to the mechanism recommended in Section 6.2.3, and arguably more likely to deploy (since the OTP doesn't have special semantics of being a URI).

Please update the algorithms so that the reader doesn't have to go look up which algorithm this is (PKCS1 vs. PSS).

OLD: "RSA is defined in Section 8.2 of [RFC3447]" 

NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of [RFC3447]"

Given how convoluted the use case is here, an example would be very helpful.  At the very least to demonstrate the syntax of the WWW-Authenticate header.

(Benoît Claise) No Objection

Alissa Cooper No Objection

Comment (2015-01-07 for -09)
No email
send info
Good stuff! Couple of comments.

= Logging out =

The intro says

"Logout features can be useful for UAs, so HOBA defines a way to
      close a current HTTP "session", and also a way to close all
      current sessions, even if more than one session is currently
      active from different UAs for the same account."
    
But the method specified in 6.3 seems to only accomplish the first of these (assuming the recommendation about server deletion of cookies related to "the session" is meant to be specific to one session). What is the method for logging out of all sessions associated with different UAs for the same account?

= Section 6.1 =

Either the device identifier/device identifier type bits are underspecified, or it's not clear to me how they are meant to be used. What other device identifier types are expected to be used in the future, such that a registry of them is necessary? To me it seems like you would want UAs/users to take some care with the precision of the device identifiers shared with servers -- e.g., "Alissa's laptop" seems like it could be useful and fairly safe, whereas "IMEI 013584009812219" seems like total overkill and a bad idea. (As an aside, it might be good to provide some guidance about this in the document.) The creation of the registry makes me wonder if more structured device identifiers of the IMEI-ilk are envisioned, and if so what the purpose of them is expected to be?

Also, I would suggest

s/if absent then the "string" form of device identifier MUST be used./if absent then the "string" form of device identifier defined in Section 9.5 MUST be used.

= Section 8 =

"Binding my CPK with someone else's account would be fun and
   profitable so SHOULD be appropriately hard."

Sarcasm translates pretty poorly across cultures. I would suggest saying what you actually mean here.

= Section 8.2 =

If you want to leave in the LinkedIn reference, or any specific example, it needs a citation.

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Joel Jaeggli) No Objection

Comment (2015-01-07 for -09)
No email
send info
satisfied with the rersults from david black's opsdir review.

(Pete Resnick) No Objection

Comment (2015-01-07 for -09)
No email
send info
Yay HOBA! Very good that we are finally doing this thing. Totally nitty things here. Barry covered anything substantive that I found:

- Use of the word "we" always makes me gag in IETF documents. Blech. For example, in 1.2 (2 times):

OLD
   We use this term when describing something that is
NEW
   This term is used when describing something that is

Passive voice is under-rated for some things. There are 9 other uses of "we" throughout the doc. We would be happy if we changed them.

- The last paragraph of section 2 is (a) ungrammatical and (b) seems more like it belongs in section 1.

- Grammatical 2119 fussiness:

OLD
   UAs MAY optimise their use of challenges by pre-fetching a challenge
NEW
   To optimise their use of challenges, UAs MAY pre-fetch a challenge

(Martin Stiemerling) No Objection

(Stephen Farrell) Recuse