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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]