Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2015-03-06
10 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-03-04
10 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-03-03
10 (System) RFC Editor state changed to RFC-EDITOR from IANA
2015-02-04
10 (System) RFC Editor state changed to IANA from EDIT
2015-01-21
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2015-01-20
10 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2015-01-20
10 (System) IANA Action state changed to Waiting on Authors
2015-01-13
10 Cindy Morgan IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-01-13
10 (System) RFC Editor state changed to EDIT
2015-01-13
10 (System) Announcement was received by RFC Editor
2015-01-12
10 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed
2015-01-12
10 Amy Vezza IESG has approved the document
2015-01-12
10 Amy Vezza Closed "Approve" ballot
2015-01-12
10 Amy Vezza Ballot approval text was generated
2015-01-12
10 Amy Vezza Ballot writeup was changed
2015-01-08
10 Barry Leiba
[Ballot comment]
I have looked at the change to Section 8.2, and I think it (and the reference) is a perfect choice, and makes the …
[Ballot comment]
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?
2015-01-08
10 Barry Leiba Ballot comment text updated for Barry Leiba
2015-01-08
10 Stephen Farrell IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2015-01-08
10 Stephen Farrell New version available: draft-ietf-httpauth-hoba-10.txt
2015-01-08
09 Cindy Morgan IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from Waiting for AD Go-Ahead
2015-01-08
09 Barry Leiba
[Ballot comment]
-- Section 8.2 --

I don't think you need to say "a la LinkedIn," and I think it's a bad idea to have …
[Ballot comment]
-- 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.

---

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 will propose such text.

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.

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

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

-- 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?
2015-01-08
09 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to Yes from Discuss
2015-01-08
09 Cindy Morgan Changed consensus to Yes from Unknown
2015-01-08
09 Ted Lemon [Ballot Position Update] New position, Yes, has been recorded for Ted Lemon
2015-01-08
09 Richard Barnes
[Ballot comment]
Old DISCUSS points:

(1) Cleared (I still think the architecture is bad and Stephen should feel bad, but I'm willing to let this …
[Ballot comment]
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.
2015-01-08
09 Richard Barnes [Ballot Position Update] Position for Richard Barnes has been changed to No Objection from Discuss
2015-01-08
09 Richard Barnes
[Ballot discuss]
(1) It does not seem to me that the mechanism defined in this document actually conforms to the framework for HTTP authentication.  The …
[Ballot discuss]
(1) It does not seem to me that the mechanism defined in this document actually conforms to the framework for HTTP authentication.  The general framework defined in RFC 7235 is all scoped to a resource -- you can implement authorization for a specific resource, without impacting anything else on the server.  HOBA, by contrast, requires the authenticating resource to be also be correlated to several resource under .well-known, meaning that it will not be usable in a large number of deployment circumstances.  Was this issue discussed in the WG, and was there input from the broader HTTP community? 

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

(3) Cleared (bounds on <2048-bit keys)
2015-01-08
09 Richard Barnes Ballot discuss text updated for Richard Barnes
2015-01-08
09 Alia Atlas [Ballot comment]
Agree with Barry
2015-01-08
09 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-01-08
09 Richard Barnes
[Ballot discuss]
(1) It does not seem to me that the mechanism defined in this document actually conforms to the framework for HTTP authentication.  The …
[Ballot discuss]
(1) It does not seem to me that the mechanism defined in this document actually conforms to the framework for HTTP authentication.  The general framework defined in RFC 7235 is all scoped to a resource -- you can implement authorization for a specific resource, without impacting anything else on the server.  HOBA, by contrast, requires the authenticating resource to be also be correlated to several resource under .well-known, meaning that it will not be usable in a large number of deployment circumstances.  Was this issue discussed in the WG, and was there input from the broader HTTP community? 

(2) What is your justification for using a SHA-1 based signature in a new protocol, when it is being actively deprecated elsewhere, in particular the web PKI?

(3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> MUST
2015-01-08
09 Richard Barnes
[Ballot comment]
Given that the size of the header seems to be a concern (since you're not passing the key in the header), why are …
[Ballot comment]
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.
2015-01-08
09 Richard Barnes Ballot comment and discuss text updated for Richard Barnes
2015-01-07
09 Joel Jaeggli [Ballot comment]
satisfied with the rersults from david black's opsdir review.
2015-01-07
09 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2015-01-07
09 Richard Barnes
[Ballot discuss]
(1) It does not seem to me that the mechanism defined in this document actually conforms to the framework for HTTP authentication.  The …
[Ballot discuss]
(1) It does not seem to me that the mechanism defined in this document actually conforms to the framework for HTTP authentication.  The general framework defined in RFC 7235 is all scoped to a resource -- you can implement authorization for a specific resource, without impacting anything else on the server.  HOBA, by contrast, requires the authenticating resource to be also be correlated to several resource under .well-known, meaning that it will not be usable in a large number of deployment circumstances.  Was this issue discussed in the WG, and was there input from the broader HTTP community? 

(2) What is your justification for using a SHA-1 based signature in a new protocol, when it is being actively deprecated elsewhere, in particular the web PKI?

(3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> MUST

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

(5) For that matter, why bother defining a new algorithm registry at all, when JWA provides a perfectly nice one that only costs you 4 characters.
2015-01-07
09 Richard Barnes
[Ballot comment]
The HOBA-TBS construction seems really unnecessarily complicated.  Other than in the "origin" component, there are no ":" characters allowed in any of the …
[Ballot comment]
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.
2015-01-07
09 Richard Barnes [Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes
2015-01-07
09 Alissa Cooper
[Ballot comment]
Good stuff! Couple of comments.

= Logging out =

The intro says

"Logout features can be useful for UAs, so HOBA defines a …
[Ballot comment]
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.
2015-01-07
09 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2015-01-07
09 Kathleen Moriarty Ballot writeup was changed
2015-01-07
09 Pete Resnick
[Ballot comment]
Yay HOBA! Very good that we are finally doing this thing. Totally nitty things here. Barry covered anything substantive that I found:

- …
[Ballot comment]
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
2015-01-07
09 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2015-01-07
09 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-01-07
09 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2015-01-06
09 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2015-01-05
09 Barry Leiba
[Ballot discuss]
One small point left:

-- Section 8.2 --

I don't think you need to say "a la LinkedIn," and I think it's a …
[Ballot discuss]
One small point left:

-- 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.
2015-01-05
09 Barry Leiba
[Ballot comment]
This document would benefit from some section somewhere giving a set of clear, numbered steps, saying who sends, who receives, and who does …
[Ballot comment]
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 will propose such text.

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.

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

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

-- 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?
2015-01-05
09 Barry Leiba Ballot comment and discuss text updated for Barry Leiba
2015-01-05
09 Barry Leiba
[Ballot discuss]
Two small points to discuss:

-- Section 6.3 --

  The server SHOULD also revoke or delete any cookies associated with
  the …
[Ballot discuss]
Two small points to discuss:

-- Section 6.3 --

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

Why is that not MUST?  If the SHOULD is just to accommodate some implementations, is that really how we want to specify the protocol?

-- 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.
2015-01-05
09 Barry Leiba
[Ballot comment]
This document would benefit from some section somewhere giving a set of clear, numbered steps, saying who sends, who receives, and who does …
[Ballot comment]
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 will propose such text.

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.

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

-- 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 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 for the slowest signing device"?

-- 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?
2015-01-05
09 Barry Leiba Ballot comment and discuss text updated for Barry Leiba
2015-01-05
09 Barry Leiba
[Ballot discuss]
Point 1:
I find the document to be really unclear about who does what with which and to whom and....  I gather that …
[Ballot 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.
2015-01-05
09 Barry Leiba
[Ballot comment]
Minor editorial nit: you use "a HOBA" fairly consistently, but "an HOBA" appears twice.  Oughta fix.

The abstract appears to overstate the password …
[Ballot 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?
2015-01-05
09 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to Discuss from No Record
2015-01-05
09 Barry Leiba
[Ballot comment]
Minor editorial nit: you use "a HOBA" fairly consistently, but "an HOBA" appears twice.  Oughta fix.

The abstract appears to overstate the password …
[Ballot 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.

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

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

I don't think you need to say "a la LinkedIn," and I'd rather not see a company's name forever linked in an RFC to a password compromise.  Especially when it's not necessary.

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?
2015-01-05
09 Barry Leiba Ballot comment text updated for Barry Leiba
2015-01-02
09 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2015-01-02
09 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Donald Eastlake.
2015-01-02
09 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-12-31
09 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2014-12-31
09 Stephen Farrell [Ballot Position Update] New position, Recuse, has been recorded for Stephen Farrell
2014-12-30
09 Kathleen Moriarty Ballot has been issued
2014-12-30
09 Kathleen Moriarty [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty
2014-12-30
09 Kathleen Moriarty Created "Approve" ballot
2014-12-30
09 Stephen Farrell New version available: draft-ietf-httpauth-hoba-09.txt
2014-12-30
08 David Black Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: David Black.
2014-12-29
08 Jean Mahoney Request for Telechat review by GENART is assigned to David Black
2014-12-29
08 Jean Mahoney Request for Telechat review by GENART is assigned to David Black
2014-12-26
08 Stephen Farrell IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-12-26
08 Stephen Farrell New version available: draft-ietf-httpauth-hoba-08.txt
2014-12-26
07 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2014-12-24
07 Kathleen Moriarty Placed on agenda for telechat - 2015-01-08
2014-12-24
07 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2014-12-22
07 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2014-12-22
07 Amanda Baber
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-httpauth-hoba.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-httpauth-hoba.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has a question about one of the actions requested in the IANA considerations section of this document.

IANA understands that, upon approval of this document, there are six actions which need to be completed.

First, in the HTTP Authentication Schemes registry under the Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry heading at

https://www.iana.org/assignments/http-authschemes/

a new authentication scheme will be registered as follows:

Authentication Schemem Name: HOBA
Reference: Section 3 of [ RFC-to-be ]
Notes: [ none ]

Second, in the Well-Known URI registry located at:

https://www.iana.org/assignments/well-known-uris/

a new well-known URI will be registered as follows:

URI Suffix: hoba
Change Controller: IETF
Reference: Section 6 of [ RFC-to-be ]
Related Information: [ none ]

IANA Note -> As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, a new registry is to be created called the HOBA Signature Algorithms registry.

IANA understands that the registry will consist of a number, meaning and reference.

IANA Question -> per RFC 5226, what is the registration procedure for this registry?

IANA Question -> Where should this new registry be located? Does it belong at an existing URL, under an existing heading at http://www.iana.org/protocols? If not, please supply a title for the new category (for example, "HTTP Origin-Bound Authentication (HOBA) Parameters").

IANA Question -> Does this registry have a maximum value?

These are the initial registrations:

Number: 0
Meaning: RSA-SHA256
Reference: [ RFC-to-be ]

Number: 1
Meaning: RSA-SHA1
Reference: [ RFC-to-be ]

Fourth, a new registry is to be created called the HOBA Key Identifier Types registry.

IANA understands that the registry will consist of a number, meaning and reference.

IANA Question -> per RFC 5226, what is the registration procedure for this registry?

IANA Question -> Where should this new registry be located?

IANA Question -> Does this registry have a maximum value?

These are the initial registrations:

Number: 0
Meaning: a hashed public key [ RFC6698 ]
Reference: [ RFC-to-be ]

Number: 1
Meaning: a URI [ RFC3986 ]
Reference: [ RFC-to-be ]

Number: 2
Meaning: an unformatted string, at the user's/UA's whim
Reference: [ RFC-to-be ]

Fifth, a new registry is to be created called the HOB Device Identifier Types registry.

IANA understands that the registry will consist of a number, meaning and reference.

IANA Question -> per RFC 5226, what is the registration procedure for this registry?

IANA Question -> Where should this new registry be located?

IANA Question -> Does this registry have a maximum value?

These are the initial registrations:

Number: 0
Meaning: an unformatted string, at the user's/UA's whim
Reference: [ RFC-to-be ]

Sixth, in the Permanent Message Header Field Names subregistry of the Message Headers registry located at:

https://www.iana.org/assignments/message-headers/

a new message header field name will be registered as follows:

Header Field Name: Hobareg
Template:
Protocol: HTTP
Status:
Reference: [ RFC-to-be ]

IANA Note -> As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2014-12-17
07 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Ready. Reviewer: David Black.
2014-12-16
07 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Withdrawn'
2014-12-16
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to David Black
2014-12-16
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to David Black
2014-12-16
07 David Black Request for Last Call review by GENART Completed: On the Right Track. Reviewer: David Black.
2014-12-15
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2014-12-15
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2014-12-11
07 Jean Mahoney Request for Last Call review by GENART is assigned to David Black
2014-12-11
07 Jean Mahoney Request for Last Call review by GENART is assigned to David Black
2014-12-11
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2014-12-11
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2014-12-10
07 Amy Vezza IANA Review state changed to IANA - Review Needed
2014-12-10
07 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (HTTP Origin-Bound Authentication (HOBA)) to …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC


The IESG has received a request from the Hypertext Transfer Protocol
Authentication WG (httpauth) to consider the following document:
- 'HTTP Origin-Bound Authentication (HOBA)'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-12-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  HTTP Origin-Bound Authentication (HOBA) is a digital signature based
  design for an HTTP authentication method.  The design can also be
  used in Javascript-based authentication embedded in HTML.  HOBA is an
  alternative to HTTP authentication schemes that require passwords and
  therefore avoids all problems related to passwords, such as leakage
  of server-side password databases.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ballot/


No IPR declarations have been submitted directly on this I-D.


2014-12-10
07 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2014-12-10
07 Kathleen Moriarty Last call was requested
2014-12-10
07 Kathleen Moriarty Ballot approval text was generated
2014-12-10
07 Kathleen Moriarty IESG state changed to Last Call Requested from Publication Requested
2014-12-10
07 Kathleen Moriarty Ballot writeup was changed
2014-12-10
07 Kathleen Moriarty Ballot writeup was generated
2014-12-10
07 Kathleen Moriarty Last call announcement was generated
2014-12-10
07 Yoav Nir
Authors are Stephen Farrell, Paul Hoffman, and Michael Thomas. Kathleen
Moriarty is the responsible Area Directory. Yoav Nir is the document
shepherd.

Summary
  HTTP …
Authors are Stephen Farrell, Paul Hoffman, and Michael Thomas. Kathleen
Moriarty is the responsible Area Directory. Yoav Nir is the document
shepherd.

Summary
  HTTP Origin-Bound Authentication (HOBA) is a digital signature based
  design for an HTTP authentication method.  The design can also be
  used in Javascript-based authentication embedded in HTML.  HOBA is an
  alternative to HTTP authentication schemes that require passwords and
  therefore avoids all problems related to passwords, such as leakage
  of server-side password databases.
 
Review and Consensus
  This document is one of the experimental documents submitted to the
  HTTP-Auth working group. The proposed authentication method has been
  reviewed by many participants, mostly in WGLC, resulting in a
  longish list in the acknowledgements section and some substantial
  changes.
 
  With version -07 it is the consensus of the HTTP-Auth working group
  that this document is fit to be published as an experimental RFC.
 
  There are at least two implementations of the protocol in this
  document ([1],[2]). They work and interoperate, but there is no
  wide-spread deployment, which suggests that "experimental" is the
  correct track for this document.
 
Intellectual Property
  All authors have confirmed that they are not aware of any undisclosed
  IPR associated with this document. There have been no IPR disclosures.
 
Other Issues
  None
 
[1] https://hoba.ie
[2] https://github.com/razevedo/hoba-authentication
2014-12-10
07 Yoav Nir IETF WG state changed to Submitted to IESG for Publication from WG Document
2014-12-10
07 Yoav Nir IESG state changed to Publication Requested
2014-12-10
07 Yoav Nir IESG process started in state Publication Requested
2014-12-10
07 Yoav Nir Changed document writeup
2014-12-10
07 Yoav Nir Notification list changed to draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, "Yoav Nir" <ynir.ietf@gmail.com> from draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org
2014-12-10
07 Yoav Nir Document shepherd changed to Yoav Nir
2014-12-09
07 Stephen Farrell New version available: draft-ietf-httpauth-hoba-07.txt
2014-12-05
06 Kathleen Moriarty Intended Status changed to Experimental from None
2014-12-05
06 Kathleen Moriarty Notification list changed to draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org
2014-12-05
05 Kathleen Moriarty Shepherding AD changed to Kathleen Moriarty
2014-12-05
06 Stephen Farrell New version available: draft-ietf-httpauth-hoba-06.txt
2014-10-07
05 Stephen Farrell New version available: draft-ietf-httpauth-hoba-05.txt
2014-08-14
04 Stephen Farrell New version available: draft-ietf-httpauth-hoba-04.txt
2014-04-18
03 Paul Hoffman New version available: draft-ietf-httpauth-hoba-03.txt
2013-10-18
02 Paul Hoffman New version available: draft-ietf-httpauth-hoba-02.txt
2013-07-15
01 Stephen Farrell New version available: draft-ietf-httpauth-hoba-01.txt
2013-05-14
00 Stephen Farrell New version available: draft-ietf-httpauth-hoba-00.txt