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

Hi Julian,

Thanks for the review and as noted in my response to
David's...

a proto-08
version (handling the various IETF LC comments) is at [1]
with a diff vs. 07 at [2]. I'll plan to publish that as an
official -08 in a few days if there are no comments.

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

On 16/12/14 13:30, Julian Reschke wrote:
> Hi there,
> 
> 
> see below my feedback on draft-ietf-httpauth-hoba-07.
> 
> Best regards, Julian
> 
> 
> -- feedback here --
> 
> 
> 1. Introduction
> 
>    HTTP Origin-Bound Authentication (HOBA) is an authentication design
>    that can be used as an HTTP authentication scheme [RFC7235] and for
>    Javascript-based authentication embedded in HTML.  The main goal of
>    HOBA is to offer an easy-to-implement authentication scheme that is
>    not based on passwords, but that can easily replace HTTP or HTML
>    forms-based password authentication.  Deployment of HOBA can reduce
>    or eliminate password entries in databases, with potentially
>    significant security benefits.
> 
> "HTTP or HTML forms-based password authentication" reads weird. Maybe
> "HTTP authentication [RFC7235] or authentication based on HTML forms and
> cookies [ref]"?

I prefer the current text to be honest. Seems purely stylistic
to me.

> 
>    HOBA is an HTTP authentication mechanism that complies with the
>    framework for such schemes [RFC7235].  As a JavaScript design, HOBA
>    demonstrates a way for clients and servers to interact using the same
>    credentials that are used by the HTTP authentication scheme.
> 
> Also confusing. Maybe state upfront that you define two different
> protocols (sharing algorithms), one as HTTP auth scheme, one using JS.

I disagree that this is confusing.

> When done, use terminology conistently ("HOBA", HOBA HTTP auth scheme",
> "HOBA JS whatever"). [I see you later defined HOBA-http and HOBA-js;
> maybe do this earlier]

That's done in section 1. Earlier would be quite tricky.

> 
>    Current username/password authentication methods such as HTTP Basic,
>    HTTP Digest, and web forms have been in use for many years but are
> 
> Maybe add citations for these schemes?

They're there later.

> 
>    ...
> 
>    HOBA session management is identical to username/password session
>    management, with a server-side session management tool or script
>    inserting a session cookie into the output to the browser.  HOBA
>    still requires TLS to prevent session cookie hijacking.
> 
> At this point you absolutely need to cite the Cookie spec.

Yep - good catch. Added a ref to 6265 there. (There was one later
anyway.)

> 
>    HOBA keys are "bare keys", so there is no need for the semantic
>    overhead of PKIX certificates, particularly with respect to naming
>    and trust anchors.  The client public key ("CPK") structures in HOBA
>    do not have any publicly-visible identifier for the user who
>    possesses the corresponding private key, nor the web-origin with
>    which the client is using the CPK.
> 
> Expand "PKIX".

Yes, that's not great - changed to say "X.509 public key certificates"
instead of "PKIX certificates."

> 
>    HOBA also defines some services that are required for modern HTTP
>    authentication:
> 
> Avoid lowercase BCP14 terms. Also, don't understand "modern" here ;-)

AVOIDED:-) "Modern" here means considering more of the life
cycle as is clear from the list that follows (and hence does
not need to be clarified before the list itself).

> 
>    ...
> 
> 1.1. Interfacing to Applications (Cookies)
> 
>    HOBA can be used as a drop-in replacement for password-based user
>    authentication schemes used in common web applications.  The simplest
>    way is to (re-)direct the UA to a HOBA "Login" URL and for the
>    response to a successful HTTP request containing a HOBA signature to
>    set a session cookie [RFC6265].  Further interactions with the web
>    application will then be secured via the session cookie, as is
>    commonly done today.
> 
> Does this apply to the HTTP authentication scheme, too?

Yes, which is why we don't say HOBA-js. My server code does exactly
that in most cases.

> 
> 
> 1.2. Terminology
> 
>    ...
> 
>    This specification uses the Augmented Backus-Naur Form (ABNF)
>    notation of [RFC5234]
> 
> s/[RFC5234]/[RFC5234]./

ack

> 
>    Account: The term "account" is (loosely) used to refer to whatever
>    data structure(s) the server maintains that are associated with an
>    identity.  That will contain of at least one CPK and a web-origin; it
>    will also optionally include an HTTP "realm" as defined in the HTTP
>    authentication specification.  [RFC7235].  It might also involve many
> 
> s/.  [RFC7235]./[RFC7235]./

ack

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

> ...say where scheme, authority etc come from.

done

> ...maybe clarify that all of these characters are in US-ASCII (wrt to
> encoding into octets)

Really? Another ref to RFC20? Sure, why not.

> 
>    ...
> 
>    o  nonce: is a random value chosen by the UA and MUST be base64url
>       encoded before being included in the HOBA-TBS value. (base64url
>       encoding is defined in [RFC4648].)  UAs MUST be able to use at
>       least 32 bits of randomness in generating a nonce.  UAs SHOULD be
>       able to use 64 or more bits of randomness for nonces.
> 
> "MUST be able to use"... doesn't sound testable.

It's still worth saying though.

> 
>    ...
> 
>    The HOBA "client result" is a dot-separated string that includes the
>    signature and is sent in the HTTP Authorized header field value using
> 
> "Authorized"?

Heh. Fixed. (Well, made it correct, fixing it would change the
name:-)

> 
> 
> 3. Introduction to the HOBA-http Mechanism
> 
>    ...
> 
>    o  A "max-age" attribute MUST be included that specifies the number
>       of seconds from the time the HTTP response is emitted for which
>       responses to this challenge can be accepted for example "max-age:
>       10" would indicatge ten seconds.  If max-age is set to zero, then
>       that means that only one signature will be accepted for this
>       challenge.
> 
> s/indicatge/indicate/

ack

> 
>    o  A "realm" attribute MAY be included to indicate the scope of
>       protection in the manner described in HTTP/1.1, Part 7 [RFC7235].
>       The "realm" attribute MUST NOT appear more than once.
> 
>    ...
>    additional mechanisms to validate the signature.  If the validation
>    fails, or if the server chooses reject the signature for any reason
>    whatsoever, the server aborts the transaction via a 401 Unauthorized
>    HTTP response.
> 
> "..fails the request with a 401..." (I'd prefer not to speak of
> transactions here)

Ah good yes.

> 
>    Note that a HOBA signature is good for however long a non-zero max-
>    age attribute allows.  This means that replay is possible within the
> 
> s/attribute/parameter/

ack

> 
>    ...
> 
> 
> 4. Introduction to the HOBA-js Mechanism
> 
>    ...
> 
>    One element is required for HOBA-js: localStorage (see http://
>    www.w3.org/TR/webstorage/) from HTML5 can be used for persistent key
> 
> Add proper reference.

I'll follow the RFC editor's preference. (I prefer refs that are only
URLs like this myself, but they'll fix as they need to.)

> 
>    storage.  For example, an implementation would store a dictionary
>    account identifier, public key and private key tuples in the origin's
>    localStorage for subsequent authentication requests.  How this
>    information is actually stored in localStorage is an implementation
>    detail.  This type of key storage relies on the security properties
>    of the same-origin policy that localStorage enforces.  See the
>    security considerations for discussion about attacks on localStorage.
>    Note that IndexedDB (See http://www.w3.org/TR/IndexedDB/) is an
>    alternative to localStorage that can also be used here.
> 
> And here.

Ditto:-)

> 
>    Because of JavaScript's same-origin policy, scripts from subdomains
>    do not have access to the same localStorage that scripts in their
>    parent domains do.  For larger or more complex sites, this could be
>    an issue that requires enrollment into subdomains, which could be a
>    hassle for users.  One way to get around this is to use session
>    cookies because they can be used across subdomains.  That is, with
>    HOBA-js, the user might log in using a single well-known domain, and
>    then the server uses session cookies to navigate around a site.
> 
>    Another element will be highly desirable for HOBA-js when it becomes
>    available: WebCrypto (see http://www.w3.org/TR/WebCryptoAPI).  In
>    lieu of WebCrypto, JavaScript crypto libraries can be employed with
>    the known deficiencies of their pseudo-random number generators and
>    the general immaturity of those libraries.
> 
> And here.

Ditto ditto:-)

> 
> 
> 5.3. Authentication Phase
> 
>    ...
>    If this stage of the process involves additional information for
>    authentication, such as asking the user which account she wants to
>    use (in the case where a UA is used for multiple accounts on a site),
>    the server can prompt the user for account identifying information or
>    the user could choose based on HTML offered by the server before the
>    401 is triggered.  None of this is standardized: it all follows the
> 
> s/401/401 response/

good thanks

> 
>    server's security policy and session flow.  At the end of this, the
>    server probably assigns or updates a session cookie for the client.
> 
> 
> 6. Other Parts of the HOBA Process
> 
>    ...
> 
>    There are many use cases for these URLs to redirect to other URLs: a
>    site that does registration through a federated site, a site that
>    only does registration under HTTPS, and so on.  Like any HTTP client,
>    HOBA-http clients have to be able to handle redirection of these
>    URLs.  However, as that would potentially cause security issues when
> 
> s/URLs/requests/

yep

> 
> 
> 6.1. Registration
> 
>    Normally, a registration (also called "joining") is expected to
>    happen after a UA receives a WWW-Authenticate for a web-origin and
> 
> s/WWW-Authenticate/401 response/ (right?)

Yes that's better I think.

> 
>    ...
> 
>    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:-)

> Why does this need to be an HTML form,
> btw?

Doesn't need to be, but it just is as that works fine.

> 
>    ...
> 
>    o  did: a UTF8 string that specifies the device identifier.  This can
>       be used to help a user be confident that authentication has
>       worked, e.g., following authentication some web content might say
>       "You last logged in from device 'did' at time T."
> 
> An example would be good to people note that many characters (plus all
> non-ASCII characters) need to be percent-escaped in this payload format.

Seems to me that it is not necessary to have an example of every
single use of UTF8. Happy to add supplied text though.

> 
> 
> 6.1.1. Hobareg Definition
> 
>    ...
> 
>    For this reason the server MUST add a header to the response message
> 
> s/header/header field/

ack (I get that wrong now and then regardless of how often I'm told,
maybe we should start to get over the distinction:-)

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

> 
>    ...
> 
>    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."
> 
> Misleading; just state that any ABNF-invalid value is to be interpreted
> as "inwork".

Sure, that's better. I left in the list example as well though.

> 
>    ...
> 
>    o  Since Hobareg is only meant for responses it ought not appear in a
>       PUT request.
> 
> Drop the part about PUT; not allowed in request means not allowed in
> requests...

ack

> 
>    ...
> 
>    o  Intermediaries should never insert, delete or modify a Hobareg
>       header field.
> 
> SHOULD? or even MUST?

Got rid of the "should" based on another comment, so it's now the
moral equivalent of MUST

> 
> 6.2. Associating Additional Keys to an Exiting Account
> 
> I'll assume you meant to say "Existing" :-)

heh:-)

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

> 
> 
> 8.1. Privacy considerations
> 
>    HOBA does impact to some extent on privacy and could be considered to
> 
> s/on//

No, it's correct as-is.

> 
>    represent a super-cookie to the server, or to any entity on the path
>    from UA to HTTP server that can see the HOBA signature.  This is
>    because we need to send a key identifier as part of the signature and
>    that will not vary for a given key.  For this reason, and others, it
>    is strongly RECOMMENDED to only use HOBA over server-authenticated
>    TLS and to migrate web sites using HOBA to only use "https" URLs.
> 
>    UAs SHOULD provide users a way to manage their CPKs.  Ideally, there
>    would be a way for a user to maintain their HOBA details for a site
>    while at the same time deleting other site information such as
>    cookies or non-HOBA HTML5 LocalStorage.  However, as this is likely
>    to be complex and appropriate user interfaces counter intutitive, we
>    exepect that UAs that implement HOBA will likely treat HOBA
> 
> s/exepect/expect/

ack

> 
>    information as just some more site data, that would disappear should
>    the user choose to "forget" that site.
> 
> 
> 
> 9.6. Hobareg HTTP Header
> 
> s/Header/Header Field/

ack

> 
> 
> 
> 12.1. Normative References
> 
> 12.2. Informative References
> 
>    [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
>               Encodings", RFC 4648, October 2006.
> 
> This is likely normative.

sure

> 
>    [bonneau]  Bonneau, , "The science of guessing: analyzing an
>               anonymized corpus of 70 million passwords.", Security and
>               Privacy (SP), 2012 IEEE Symposium on. IEEE, 2012. , 2012.
> 
> This reference looks broken (interpunction-wise).

Tidied up.

> 
> 
> Appendix A. Problems with Passwords
> 
>    ...
> 
>    Using memorizable passwords on unencrypted channels also poses risks
>    to the users.  If a web site uses either the HTTP Plain
> 
> s/Plain/Basic/ ? (also add ref)

changed, ref is earlier

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

S.

> 
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth
> 