[http-auth] Quick review of draft-ietf-httpauth-hoba-02

[Ilari Liusvaara <[e-mail]>]

> Abstract
> 
>    HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP
>    authentication method with credentials that are not vulnerable to
>    phishing attacks, and that does not require any server-side password
>    database.  The design can also be used in Javascript-based
>    authentication embedded in HTML.  HOBA is an alternative to HTTP
>    authentication schemes that require passwords.

Well, technically whatever the database is resembles some forms of password
database, albeit with the "passwords" being of much much higher entropy.

But that's nitpicking.

>    Session management with HOBA is identical to username/password
>    session management.  Typically, the session management tool (such as
>    PHP, Python CGI, and so on) inserts a session cookie into the output
>    to the browser.  HOBA does nothing to help or hurt session cookie
>    hijacking; TLS is still required for that.

If the authentication is not bound to sessions, even TLS can't really
help against all attacks that arise.
 
>    HOBA also defines some services that are required for modern HTTP
>    authentication:
> 
>    o  Since there are always devices and applications in which state of
>       the art digital signature mechanism runtimes are significant, and
>       since HTTP authentication in theory requires that every HTTP
>       request to a given realm have a signature in an "Authorization"
>       header field, and since HOBA is a challenge response scheme, we
>       also define a way in which HTTP servers can indicate the duration
>       for which they will consider a given challenge value to be valid.
>       As a consequence we also define a way for UAs to fetch a fresh
>       challenge.

Hah, I was under impression that state-of-the-art is faster, not slower.
Of course, there is keylength increases.

Discrete to ECC, ECC to HECC.

Of course, the usual way to lighten the load without sacrificing much
security is to have symmetric short-term keys.

But yes, there are more and more devices that have very limited processing
power.

> 2.  The HOBA Authentication Scheme
> 
>    HOBA-TBS = nonce alg origin [ realm ] kid challenge
>    nonce = unreserved
>    alg = 1*2DIGIT
>    origin = scheme "://" authority ":" port
>    realm = unreserved
>    kid = unreserved
>    challenge = unreserved

What's unreserved? I can't quickly find it from httpbis p1, p7 nor from
this document.

It it includes spaces, there could be multiple ways to take it apart
(or multiple things mapping into the same string).

Well, given the realm is seemingly the only one that can have spaces, it
might not be that bad problem.

> 3.  Introduction to the HOBA-http Mechanism
> 
>    An HTTP server that supports HOBA authentication includes the "HOBA"
>    auth-scheme value in a WWW-Authenticate header field when it wants
>    the client to authenticate with HOBA.  Note that the HOBA auth-scheme
>    might not be the only one that the server includes in a WWW-
>    Authenticate.
> 
>    o  If the "HOBA" scheme is listed, it MUST be followed by two or more
>       auth-param values.  The auth-param attributes defined by this
>       specification are below.  Other auth-param attributes MAY be used
>       as well.  Unknown auth-param attributes MUST be ignored by
>       clients, if present.
> 
>    o  The "challenge" attribute MUST be included.  The challenge is the
>       string made up of the base64url encoded octets that the server
>       wants the client to sign in its response.  The challenge SHOULD be
>       unique for every HTTP 401 response in order to prevent replay
>       attacks from passive observers.
> 
>    o  An "expires" 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.
> 
>    o  A "realm" attribute MAY be included to indicate the scope of
>       protection in the manner described in HTTP/1.1, Part 7
>       [I-D.ietf-httpbis-p7-auth].  The "realm" attribute MUST NOT appear
>       more than once.

The realm attribute must only appear once? What do other parameters do if
present multiple times (nitpicking)?
 
>    The server MUST check the cryptographic correctness of the signature
>    based on a public key it knows for the kid in the signatures, and if
>    the server cannot do that, or if the signature fails cryptographic
>    checks, then validation has failed.  The server can use any
>    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 403 Forbidden
>    HTTP response.

Er, I thought authentication failures trigger 401, authorization failures
trigger 403 (except if request isn't authenticated).
 
>    Note that a HOBA signature is good for however long the expires
>    attribute allows.  This means that replay is possible within the time
>    window specified by the "expires" value chosen by the server.
>    Servers can attempt to detect any such replay and MAY react to such
>    replays by responding with a second (or subsequent) 401-status HTTP
>    response containing a new challenge.

How could such detection be done in face of cut-and-paste attacks?

With TLS, one could include something like TLS-Unique (or what it was).
That would defeat most cut'n'paste.

> 6.1.  Registration

> 
>    The registration message sent to server has one mandatory field (pub)
>    and some optional fields that allow the UA to specify the type and
>    value of key and device identifiers that the UA wishes to use.

Again, what if these are duplicated? :->
 
>    o  kidtype: contains the type of key identifier, this is a numeric
>       value intended to contain one of the values from Section 9.4.  If
>       this is not present then the mandatory to implement "DANE-hash"
>       option MUST be used.

What's "DANE-hash"?

>    o  curtime: the number of milliseconds since the Unix epoch,
>       formatted as [[ not yet specified ]].  This is based on the
>       expectation that the synchronization between the browser's and
>       server's clocks is sufficiently reliable.  This is used to guard
>       against the replay of a legitimate registration message.  The
>       server needs to have a replay cache covering a signature timeout
>       window.  This might be done using a database table that is keyed
>       (in the database sense of the term) using the signature bits.  If
>       the signature is in the replay table, the server will reject it.
>       If the timestamp in the signature is outside the current replay
>       cache window then it also gets rejected.

Decimal unix timestamp with three decimal digits?
 
>    [[ A comment raised on the list was: how does the UA know that the
>    registration process has completed successfully or badly?  That's not
>    yet handled.  ]]

You mean if the request was processed as-is, or more data will be required?

(For immediate request, there's HTTP status codes, so I presume it is that
"was this final success?" problem).
 
> 6.2.  Associating Additional Keys to an Exiting Account
> 
> 6.2.1.  Moving private keys
> 
>    It is common for a user to have multiple UAs, and to want all those
>    UAs to be able to authenticate to a single account.  One method to
>    allow a user who has an existing account to be able to authenticate
>    on a second device is to securely transport the private and public
>    keys and the origin information from the first device to the second.
>    If this approach is taken, then there is no impact on the HOBA-http
>    or HOBA-js so this is a pure UA implementation issue and not
>    discussed further.

There could also be copying private keys between origins/realms. In certain
cases, the server could even recognize such keys.

> 6.2.2.  One time password
> 
>    The one-time password should be easy for a user to type into the new
>    UA, but at the same time needs to have enough randomness to prevent
>    an attacker from succeeding if they try to use the password during
>    its short lifetime.  After the server gets the password in the new
>    UA, it verifies the signature and verifies that the password supplied
>    is in a list of unexpired one-time passwords.  If so, the server
>    knows that the authenticated user is associated with the second CPK.
>    The server can choose to associate the two CPKs with one account.
>    Whether to do so is entirely at the server's discretion however, but
>    the server needs make the outcome clear to the user.

Something like S/Key passwords (might not be the best in mobile enviroment)=
 
>    Alternatively, if an already-enrolled UA is not available to the user
>    when they want to associate a new UA with an existing account, and
>    the site has an out-of-band communication mechanism such as email or
>    SMS associated with that account, the user can request that a one-
>    time password be sent to the user out of band.  The user receives the
>    one-time password and, using the new UA, tells it to the server.  On
>    HOBA-http, this is done with the URL ".well-known/hoba/associate-
>    from-oob" using a POST message [[ more detail is clearly needed here
>    ]].

What's the difference to the first case from server POV (the URL being
different)?
 
> 6.3.  Logging Out
> 
>    The user can tell the server it wishes to log out.  With HOBA-http,
>    this is done by going to the URL ".well-known/hoba/logout".  The UA
>    SHOULD also delete or modify session cookies associated with the
>    session so that the user's state is no longer "logged in."

Modify? I don't think cookies are modifiable, so that just leaves deleting
those.
 
>    The server MUST NOT allow TLS session resumption for any logged out
>    session.  [[ Need to determine if this is needed or even a good idea.
>    ]]

Eeh? Specify that server MUST destroy TLS session state on HOBA logout?

These things run on totally separate layers...
 
> 8.  Security Considerations
> 
>    [[ The potential impact on privacy of HOBA needs to be addressed.  If
>    a site can use a 401 and a CPK to track users without permission that
>    would be not-so-nice so some guidance on how a UA could indicate to a
>    user that HOBA stuff is going on might be needed.  ]]

Obviously any authentication mechanism allows tracking within account.

> 9.3.  Algorithm Names
> 
>    TBD, hopefully re-use and existing registry
> 
>    "0" means RSA-SHA256
> 
>    "1" means RSA-SHA1

Just RSA? Nothing more modern?

> 9.4.  Key Identifier Types
> 
>    "0" means a hashed public key, as done in DANE.  [RFC6698]

Er, doesn't that constist of two parts, once all implicit fields are
left out?
 
>    "1" means a URI, such as a mailto: or acct: URI, but anything
>    conforming to [RFC3986] is ok.i

"ok.i"? Should be "ok."?


-Ilari