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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/http-auth >