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

From: The IESG <[email-masked]>
Date: Wed, 10 Dec 2014 06:22:47 -0800

The IESG has received a request from the Hypertext Transfer Protocol
Authentication WG (httpauth) to consider the following document:
- 'HTTP Origin-Bound Authentication (HOBA)'
  <draft-ietf-httpauth-hoba-07.txt> as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2014-12-24. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   HTTP Origin-Bound Authentication (HOBA) is a digital signature based
   design for an HTTP authentication method.  The design can also be
   used in Javascript-based authentication embedded in HTML.  HOBA is an
   alternative to HTTP authentication schemes that require passwords and
   therefore avoids all problems related to passwords, such as leakage
   of server-side password databases.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 16 Dec 2014 14:30:22 +0100

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 16 Dec 2014 14:31:43 +0100

Hi there,

Best regards, Julian

-- feedback here --

1. Introduction

    ...

Expand "PKIX".

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

    ...

1.2. Terminology

    ...

s/[RFC5234]/[RFC5234]./

    ...

    HOBA-TBS = len ":" nonce
               len ":" alg
               len ":" origin
               len ":" [ realm  ]
               len ":" kid
               len ":" challenge
    len = 1*DIGIT
    nonce = 1*base64urlchars
    alg = 1*2DIGIT

    ...

    ...

"Authorized"?

    ...

s/indicatge/indicate/

    ...

s/attribute/parameter/

    ...

    ...

Add proper reference.

And here.

And here.

    ...

s/401/401 response/

    ...

s/URLs/requests/

6.1. Registration

    ...

    ...

    ...

s/header/header field/

    ...

    ...

    ...

SHOULD? or even MUST?

I'll assume you meant to say "Existing"

6.3. Logging Out

s/on//

s/exepect/expect/

9.6. Hobareg HTTP Header

s/Header/Header Field/

    ...

Appendix B. Example

s/443/443./

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Dec 2014 11:15:13 +0000

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

> "HTTP authentication [RFC7235] or authentication based on HTML forms and

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

> protocols (sharing algorithms), one as HTTP auth scheme, one using JS.

I disagree that this is confusing.

> "HOBA JS whatever"). [I see you later defined HOBA-http and HOBA-js;

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

> Maybe add citations for these schemes?

They're there later.

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

>    which the client is using the CPK.

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

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

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

>    This specification uses the Augmented Backus-Naur Form (ABNF)

ack

> s/.  [RFC7235]./[RFC7235]./

ack

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

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

> "MUST be able to use"... doesn't sound testable.

It's still worth saying though.

>    signature and is sent in the HTTP Authorized header field value using

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

>       that means that only one signature will be accepted for this

ack

> "..fails the request with a 401..." (I'd prefer not to speak of

Ah good yes.

>    age attribute allows.  This means that replay is possible within the

ack

>    www.w3.org/TR/webstorage/) from HTML5 can be used for persistent key

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

>    alternative to localStorage that can also be used here.

Ditto:-)

>    the general immaturity of those libraries.

Ditto ditto:-)

>    401 is triggered.  None of this is standardized: it all follows the

good thanks

>    URLs.  However, as that would potentially cause security issues when

yep

> s/WWW-Authenticate/401 response/ (right?)

Yes that's better I think.

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

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

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

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

> Could this use the Authentication-Info header field currently defined in

Maybe but would prefer to not entwine with DIGEST in that way.
Seems like all we'd get is delay and no benefit.

> Misleading; just state that any ABNF-invalid value is to be interpreted

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

> Drop the part about PUT; not allowed in request means not allowed in

ack

>    o  Intermediaries should never insert, delete or modify a Hobareg

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

> I'll assume you meant to say "Existing" :-)

heh:-)

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

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

No, it's correct as-is.

>    exepect that UAs that implement HOBA will likely treat HOBA

ack

>    the user choose to "forget" that site.

ack

> This is likely normative.

sure

> This reference looks broken (interpunction-wise).

Tidied up.

> s/Plain/Basic/ ? (also add ref)

changed, ref is earlier

>    the origin https://example.com:443 Carriage-returns have been added

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Dec 2014 11:15:13 +0000

Hi Julian,

a proto-08

Cheers,
S.

They're there later.

ack

ack

done

ack

Ah good yes.

ack

Ditto:-)

Ditto ditto:-)

good thanks

yep

ack

heh:-)

No, it's correct as-is.

ack

ack

sure

Tidied up.

changed, ref is earlier

S.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 24 Dec 2014 12:40:12 +0100

> 2.2 of RFC 7235 though, is that enough?

What's the ABNF for "unreserved"?

> replace with a better ref so long as that better ref is not a

<http://www.w3.org/TR/2014/REC-html5-20141028/forms.html#url-encoded-form-data> 
I assume.

> Seems like all we'd get is delay and no benefit.

...that supports my p.o.v. that it should be in a separate spec :-)

> fine too, but think that is allowed by the above.

GET is defined as safe, and safe is defined as:

"Request methods are considered "safe" if their defined semantics are 
essentially read-only; i.e., the client does not request, and does not 
expect, any state change on the origin server as a result of applying a 
safe method to a target resource. Likewise, reasonable use of a safe 
method is not expected to cause any harm, loss of property, or unusual 
burden on the origin server." -- 
<http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7231.html#rfc.section.4.2.1.p.1>

So you can't have GET perform a logout.

> the end of sentences) but they can fix if needed.

In doubt, put it the URI in delimiters...

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Dec 2014 13:45:17 +0000

Hiya,

Thanks for the follow up...

> What's the ABNF for "unreserved"?

See p18 of RFC 3986. I (sadly) added yet another comment
around the already overloaded abnf there. (Sadly, because I
think we're now documenting this assuming all developers are
dim, which if sad if correct, and sad if incorrect;-)

> <http://www.w3.org/TR/2014/REC-html5-20141028/forms.html#url-encoded-form-data>

Lovely.

> ...that supports my p.o.v. that it should be in a separate spec :-)

Sure. And when it is and if HOBA is put on the standards-track
those can be better aligned if that's seen as useful.

> GET is defined as safe, 

Ah sorry, I mis-read your comment. You're right. Luckily, that's
what the code I've seen does anyway:-) But that's a good catch.

> and safe is defined as:

Changed that to say use POST.

> In doubt, put it the URI in delimiters...

Or... If in doubt, wait and see what RFC editor prefers:-)

The above changes applied as before at [1,2]. If there's no
more follow up, I'll publish that in a couple of days.

Cheers,
S.