Re: [http-auth] Last Call: <draft-ietf-httpauth-hoba-07.txt> (HTTP Origin-Bound Authentication (HOBA)) to Experimental RFC

[Stephen Farrell <[e-mail]>]

Hiya,

Thanks for the follow up...

On 24/12/14 11:40, Julian Reschke wrote:
> On 2014-12-24 12:15, Stephen Farrell wrote:
>> ...
>>> 2. The HOBA Authentication Scheme
>>>
>>>     HOBA-TBS = len ":" nonce
>>>                len ":" alg
>>>                len ":" origin
>>>                len ":" [ realm  ]
>>>                len ":" kid
>>>                len ":" challenge
>>>     len = 1*DIGIT
>>>     nonce = 1*base64urlchars
>>>     alg = 1*2DIGIT
>>>     origin = scheme "://" authority ":" port
>>>     realm = unreserved
>>>     kid = 1*base64urlchars
>>>     challenge = 1*base64urlchars
>>>     ; Characters for Base64URL encoding from Table 2 of RFC 4648
>>>     base64urlchars = %x30-39             ; Digits
>>>                      / %x41-5A           ; Uppercase letters
>>>                      / %x61-7A           ; Lowercase letters
>>>                      / "-" / "_" / "="   ; Special characters
>>>
>>>                     Figure 1: To-be-signed data for HOBA
>>>
>>> ...specify a proper ABNF production for "unreserved".
>>
>> What? I don't know what you mean there. I added a pointer to
>> 2.2 of RFC 7235 though, is that enough?
> 
> What's the ABNF for "unreserved"?

See p18 of RFC 3986. I (sadly) added yet another comment
around the already overloaded abnf there. (Sadly, because I
think we're now documenting this assuming all developers are
dim, which if sad if correct, and sad if incorrect;-)

> 
>>>     ...
>>>
>>>     The registration message for HOBA-http is sent as a POST message to
>>>     the URL ".well-known/hoba/register" with an HTML form (x-www-form-
>>>     encoded) described below; The registration message for HOBA-js
>>> can be
>>>
>>> Need citation for payload format.
>>
>> To RFC 1867? Added that (though it's been obsoleted). Happy to
>> replace with a better ref so long as that better ref is not a
>> work-in-progress:-)
> 
> <http://www.w3.org/TR/2014/REC-html5-20141028/forms.html#url-encoded-form-data>
> I assume.

Lovely.

> 
>> ...
>>>     when the registration has succeded to indicate the new state.  The
>>>     header to be used is "Hobareg" and the value when registration has
>>>     succeeded is to be "regok".  When registration is inwork (e.g. on an
>>>     HTTP response for an interstitial page) the server MAY add this
>>>     header with a value of "reginwork".  See Section 9.6 for the
>>> relevant
>>>     IANA registration of this header field.
>>>
>>> Could this use the Authentication-Info header field currently defined in
>>> DIGEST?
>>
>> Maybe but would prefer to not entwine with DIGEST in that way.
>> Seems like all we'd get is delay and no benefit.
> 
> ...that supports my p.o.v. that it should be in a separate spec :-)

Sure. And when it is and if HOBA is put on the standards-track
those can be better aligned if that's seen as useful.

> 
>> ...
>>> 6.3. Logging Out
>>>
>>>
>>>     The user can tell the server it wishes to log out.  With HOBA-http,
>>>     this is done by sending any HOBA-authenticated HTTP message to the
>>>     URL ".well-known/hoba/logout" on the site in question.  The UA
>>> SHOULD
>>>     also delete session cookies associated with the session so that the
>>>     user's state is no longer "logged in."
>>>
>>> Nope. Don't define this for GET (or any "safe" method). POST would work.
>>
>> Sorry I'm not seeing why that is GET specific? I agree POST should be
>> fine too, but think that is allowed by the above.
> 
> GET is defined as safe, 

Ah sorry, I mis-read your comment. You're right. Luckily, that's
what the code I've seen does anyway:-) But that's a good catch.

> and safe is defined as:
> 
> "Request methods are considered "safe" if their defined semantics are
> essentially read-only; i.e., the client does not request, and does not
> expect, any state change on the origin server as a result of applying a
> safe method to a target resource. Likewise, reasonable use of a safe
> method is not expected to cause any harm, loss of property, or unusual
> burden on the origin server." --
> <http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7231.html#rfc.section.4.2.1.p.1>
> 
> 
> So you can't have GET perform a logout.

Changed that to say use POST.

> 
>> ...
>>> Appendix B. Example
>>>
>>>
>>>     The following values show an example of HOBA-http authentication to
>>>     the origin https://example.com:443 Carriage-returns have been added
>>>
>>> s/443/443./
>>
>> Sure, though not sure what RFC editor prefers there (for URLs at
>> the end of sentences) but they can fix if needed.
> 
> In doubt, put it the URI in delimiters...

Or... If in doubt, wait and see what RFC editor prefers:-)

The above changes applied as before at [1,2]. If there's no
more follow up, I'll publish that in a couple of days.

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

> 
> Best regards, Julian