Subject: [http-auth] I-D Action: draft-ietf-httpauth-hoba-07.txt

From: [email-masked]
Date: Tue, 09 Dec 2014 04:38:10 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF.

        Title           : HTTP Origin-Bound Authentication (HOBA)
        Authors         : Stephen Farrell
                          Paul Hoffman
                          Michael Thomas
	Filename        : draft-ietf-httpauth-hoba-07.txt
	Pages           : 25
	Date            : 2014-12-09

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-hoba-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-hoba-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 09 Dec 2014 12:42:37 +0000

Hi all,

This I hope fixes the potential issue Watson identified by
adding a length: to each field in HOBA-TBS.

I also took the chance to update the examples to example.com
and not hoba-local.ie since they needed to change anyway
with the change to the bytes of HOBA-TBS.

So from my POV I think this is ready for IETF LC now once
the chairs post the write up and Kathleen hits the button.

Thanks,
S.

PS: I've updated my code enough to test this and re-generate
the examples but haven't yet commited that back to the
repo. Will try get to that in the next day or so.

On 09/12/14 12:38, [email-masked] wrote:
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
> 
>

---

From: Michael Sweet <[email-masked]>
Date: Fri, 12 Dec 2014 10:06:38 -0500

Stephen,

Some comments for things I think should be resolved before this goes to IETF LC:

- In section 6.1.1 you say the values are "regok" and "reginwork", but the ABNF and subsequent text use "regok" and "inwork".

- Also in section 6.1.1, bottom of page 13 and top of page 14 you have:

   o  Only one single value is allowed in a Hobareg header field.
      Should more than one (a list) be encountered, that should be
      interpreted as being the same as "inwork."

          Suggested rewording to fix grammar and use of 2119 conformance terms:

          o  Only a single value is allowed in a Hobareg header field.
             If the server receives a list of values, it SHOULD interpret them
             as the same as "inwork."

          [or "reginwork", whichever is the correct one]

   o  The Hobareg header field can only be used in HTTP responses.

          But you allow clients to send it in requests?

   o  Since Hobareg is only meant for responses it ought not appear in a
      PUT request.

          How about listing the methods that MAY contain it as a request header?
          And tie it/merge it with the previous bullet.

   o  The HTTP response code does affect the interpretation of Hobareg.
      Registration is only considered to have succeeded if the regok
      value is seen in a 2xx response. 4xx and other errors means that
      registration has failed regardless of the value of Hobareg seen.
      The request method has no influence on the interpretation of
      Hobareg.

          Suggest you separate the Hobareg request header discussion from the
          Hobareg response header.

   o  Intermediaries should never insert, delete or modify a Hobareg
      header field.

          SHOULD?

   o  As a response-only header field, it is not appropriate to list a
      Hobareg in a Vary response header field.

          Is this still true?

   o  Hobareg is allowed in trailers.

   o  As a response-only header field, Hobareg will not be preserved
      across re-directs.

          Is this still true? Or just true that the Hobareg response
          header is not preserved across redirects?

   o  Hobareg itself discloses little security or privacy sensitive
      information.  If an attacker can somehow detect that a Hobareg
      header field is being added, then that attacker would know that
      the UA is in the process of registration which could be
      significant.  However, it is likely that the set of messages
      between the UA and server would expose this information in many
      cases, regardless of whether or not TLS is used.  Using TLS is
      still however a good plan.

          TLS is RECOMMENDED?

- In section 6.3 you say "The server MUST NOT allow TLS session resumption for any logged out
  session." but you don't say why.

- In section 6.4, you say the challenge is returned in the body of the response. Is that sufficient, or do you want to say the response will have a specific Content-Type and the body *is* the challenge with no other data (other than whitespace)?

- In section 8, how does one enforce conformance of hard-to-guess URLs? Perhaps reword as "To make this more difficult, the server generates hard to guess URLs and other values as part of any CPK binding processes, for whatever level of difficulty chosen by the server."

- Also in section 8, you state a conformance requirement for server administrators. Perhaps "Server administrators can set the max-age ..." instead of SHOULD.

- In section 8.1, "we" are sending a key - reword as "the client/user agent needs to send"?

> On Dec 9, 2014, at 7:42 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi all,
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 12 Dec 2014 15:26:48 +0000

Hi Michael,

The IETF LC has started but these are fine IETF LC comments:-)
I'm heading for an airport now but will get back in a day or
so.

Thanks,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 14 Dec 2014 18:34:51 +0000

Hi Michael,

Thanks again for the further review.

On 12/12/14 15:06, Michael Sweet wrote:
> - In section 6.1.1 you say the values are "regok" and "reginwork",
> but the ABNF and subsequent text use "regok" and "inwork".

Thanks. Fixed so both say reginwork now.

> o  Only one single value is allowed in a Hobareg header field. Should
> more than one (a list) be encountered, that should be interpreted as
> being the same as "inwork."
> 
> o  Only a single value is allowed in a Hobareg header field. If the
> server receives a list of values, it SHOULD interpret them as the
> same as "inwork."

No, the server dosn't get Hobareg headers from a client at all.
Those are only server->UA. If we give the wrong impression
somewhere then we should fix that so if you can say what gave
you the impression the client was sending Hobareg we might want
to change something.

> [or "reginwork", whichever is the correct one]

Fixed that.

> But you allow clients to send it in requests?

No.

> o  Since Hobareg is only meant for responses it ought not appear in
> a PUT request.
> 
> How about listing the methods that MAY contain it as a request
> header? And tie it/merge it with the previous bullet.

None.

> Registration is only considered to have succeeded if the regok value
> is seen in a 2xx response. 4xx and other errors means that 
> registration has failed regardless of the value of Hobareg seen. The
> request method has no influence on the interpretation of Hobareg.
> 

But it's never part of a request.

> o  Intermediaries should never insert, delete or modify a Hobareg 

I went for s/should never/never/ as it's really a MUST NOT but
we actually don't need any 2119 term in this case.

> Hobareg in a Vary response header field.

Yes.

> o  As a response-only header field, Hobareg will not be preserved 

Yes.

> Or just true that the Hobareg response header is
> not preserved across redirects?
> 
> 
> information.  If an attacker can somehow detect that a Hobareg header
> field is being added, then that attacker would know that the UA is in
> the process of registration which could be significant.  However, it
> is likely that the set of messages between the UA and server would
> expose this information in many cases, regardless of whether or not
> TLS is used.  Using TLS is still however a good plan.
> 
> TLS is RECOMMENDED?

Elsewhere yes, so no need to repeat that here. I think it's ok as
is.

> 
> - In section 6.3 you say "The server MUST NOT allow TLS session
> resumption for any logged out session." but you don't say why.

Yes, we don't and I'd argue to not try add much there as it's likely
hard to get right and not that useful. The reason for the MUST NOT
is so a server is less likely to get confused between TLS and HOBA
state.

> - In section 6.4, you say the challenge is returned in the body of
> the response. Is that sufficient, or do you want to say the response
> will have a specific Content-Type and the body *is* the challenge
> with no other data (other than whitespace)?

Ah - good catch. I don't think we care about the content-type (or
at least I don't:-) but yes it could be more specific about the
body being the challenge. I added that whitespace MUST be ignored
but would be equally fine with saying that the entire response
MUST be the b64-encoded challenge if that was better.

> - In section 8, how does one enforce conformance of hard-to-guess
> URLs? Perhaps reword as "To make this more difficult, the server
> generates hard to guess URLs and other values as part of any CPK
> binding processes, for whatever level of difficulty chosen by the
> server."

One cannot enforce such conformance except by looking into the
implementation, but I think the MUST is ok in a security
considerations section. And the "how" for that is well known
really. I think the current text is ok as-is but would also be
ok with getting rid of the MUST.

> 
> - Also in section 8, you state a conformance requirement for server
> administrators. Perhaps "Server administrators can set the max-age
> ..." instead of SHOULD.

Yeah, I think "can" is better there s/SHOULD/can/ done

> - In section 8.1, "we" are sending a key - reword as "the client/user

Could do, but I think it's ok as-is. Happy to change it if others
feel that further de-personalisation is better:-)

I've put a working-copy for a -08 at [1], diff vs. 07 at [2].
(On the assumption that the resolutions above are ok, if not
we'll iterate/fix as guided by the shepherd/AD.)

That proto-08 also moves a bit of text I put in the wrong place
in 07 and updates the implementation status section which I also
forgot for -07.

Cheers,
S.

[1]
[2]
https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-07.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt

>> This I hope fixes the potential issue Watson identified by adding a
>> length: to each field in HOBA-TBS.
>> 
>> I also took the chance to update the examples to example.com and
>> not hoba-local.ie since they needed to change anyway with the
>> change to the bytes of HOBA-TBS.
>> 
>> So from my POV I think this is ready for IETF LC now once the
>> chairs post the write up and Kathleen hits the button.
>> 
>> Thanks, S.
>> 
>> PS: I've updated my code enough to test this and re-generate the
>> examples but haven't yet commited that back to the repo. Will try
>> get to that in the next day or so.
>> 
>>> A New Internet-Draft is available from the on-line
>>> Internet-Drafts directories. This draft is a work item of the
>>> Hypertext Transfer Protocol Authentication Working Group of the
>>> IETF.
>>> 
>>> Title           : HTTP Origin-Bound Authentication (HOBA) Authors
>>> : Stephen Farrell Paul Hoffman Michael Thomas Filename        :
>>> draft-ietf-httpauth-hoba-07.txt Pages           : 25 Date
>>> : 2014-12-09
>>> 
>>> 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.
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at
>>> tools.ietf.org.
>>> 
>>> _______________________________________________ http-auth mailing
>>> list [email-masked] 
>> _______________________________________________ http-auth mailing
>> list [email-masked] 
> _________________________________________________________ Michael
> Sweet, Senior Printing System Engineer, PWG Chair
>

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 14 Dec 2014 18:37:42 +0000

> we'll iterate/fix as guided by the shepherd/AD.)

Forgot to put in the URL for [1]. It was guessable though:-)

S.

[1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt
[2]
https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-07.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-08.txt