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

[Paul Hoffman <[e-mail]>]

Sorry for the *long* delay in getting back to you. I'm about to do the -03, and kept your message around for doing that.

On Nov 6, 2013, at 8:27 AM, Ilari Liusvaara <[e-mail]> wrote:

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

If an attacker gets the server-side database, they still are not able to impersonate users. It's not just "higher entropy": the attacker has to determine the private keys.

> But that's nitpicking.

I would say "it's wrong". :-)


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

Added.

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

Right. If they're using RSA, that's completely different than...

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

That's our point here.

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

It simply means that it is not defined in the format. I added this.

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

Nitpicking. HTTP sucks at this, and it is not our job to fix it.

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

Noted.

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

I'm not sure what cut-and-paste attack you mean here. I put a note in, but it would be good to hear more.

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

Got it.

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

Still not yet specified.

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

Noted.

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

I'm not sure what you mean here. The origins don't have the users' private 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)=

Yuck.

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

None, really.

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

Good catch.

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

Yes, but it is something that people have asked for with connection latching.

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

Noted.

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

Certainly, once people settle on one. Added.

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

It is a single blob, the subjectPublicKeyIdentifier.

>>   "1" means a URI, such as a mailto: or acct: URI, but anything
>>   conforming to [RFC3986] is ok.i
> 
> "ok.i"? Should be "ok."?

Yep.

Thanks a zillion for these. We'll turn in the -03 sometime this week before the document expires.

--Paul Hoffman