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
On 16/12/14 13:30, Julian Reschke wrote:
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]"?
I prefer the current text to be honest. Seems purely stylistic
to me.
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.
I disagree that this is confusing.
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]
That's done in section 1. Earlier would be quite tricky.
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?
They're there later.
...
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.
Yep - good catch. Added a ref to 6265 there. (There was one later
anyway.)
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".
Yes, that's not great - changed to say "X.509 public key certificates"
instead of "PKIX certificates."
HOBA also defines some services that are required for modern HTTP
authentication:
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).
...
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?
Yes, which is why we don't say HOBA-js. My server code does exactly
that in most cases.
1.2. Terminology
...
This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234]
s/[RFC5234]/[RFC5234]./
ack
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]./
ack
...
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".
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
encoding into octets)
Really? Another ref to RFC20? Sure, why not.
...
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.
It's still worth saying though.
...
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"?
Heh. Fixed. (Well, made it correct, fixing it would change the
name:-)
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/
ack
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)
Ah good yes.
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/
ack
...
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.
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.)
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.
Ditto:-)
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.
Ditto ditto:-)
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/
good thanks
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/
yep
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?)
Yes that's better I think.
...
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.
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.
...
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.
Seems to me that it is not necessary to have an example of every
single use of UTF8. Happy to add supplied text though.
6.1.1. Hobareg Definition
...
For this reason the server MUST add a header to the response message
s/header/header field/
ack (I get that wrong now and then regardless of how often I'm told,
maybe we should start to get over the distinction:-)
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?
Maybe but would prefer to not entwine with DIGEST in that way.
Seems like all we'd get is delay and no benefit.
...
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".
Sure, that's better. I left in the list example as well though.
...
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...
ack
...
o Intermediaries should never insert, delete or modify a Hobareg
header field.
SHOULD? or even MUST?
Got rid of the "should" based on another comment, so it's now the
moral equivalent of MUST
6.2. Associating Additional Keys to an Exiting Account
I'll assume you meant to say "Existing" :-)
heh:-)
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.
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.
8.1. Privacy considerations
HOBA does impact to some extent on privacy and could be considered to
s/on//
No, it's correct as-is.
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/
ack
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/
ack
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.
sure
[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).
Tidied up.
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)
changed, ref is earlier
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./
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
http-auth(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/http-auth