ietf
[Top] [All Lists]

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

2014-12-24 07:45:50

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