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

[Julian Reschke <[e-mail]>]

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

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

    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?

    ...

    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.

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

    HOBA also defines some services that are required for modern HTTP
    authentication:

Avoid lowercase BCP14 terms. Also, don't understand "modern" here

    ...

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?


1.2. Terminology

    ...

    This specification uses the Augmented Backus-Naur Form (ABNF)
    notation of [RFC5234]

s/[RFC5234]/[RFC5234]./

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

    ...


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".
...say where scheme, authority etc come from.
...maybe clarify that all of these characters are in US-ASCII (wrt to 
encoding into octets)

    ...

    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.

    ...

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


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/

    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)

    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/

    ...


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.

    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.

    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.


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/

    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/


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

    ...

    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. Why does this need to be an HTML form, 
btw?

    ...

    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.


6.1.1. Hobareg Definition

    ...

    For this reason the server MUST add a header to the response message

s/header/header field/

    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?

    ...

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

    ...

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

    ...

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

SHOULD? or even MUST?

6.2. Associating Additional Keys to an Exiting Account

I'll assume you meant to say "Existing"


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.


8.1. Privacy considerations

    HOBA does impact to some extent on privacy and could be considered to

s/on//

    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/

    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/



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.

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


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)

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