And thanks for the changes in -08 to address this review - in addition to what's noted below, -08 also addresses [B] w/more compact text than I had suggested. Everything that remains is down to editorial comments or nits. I'll go send a review of -08 to that effect. Thanks, --David > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@xxxxxxxxx] > Sent: Friday, December 26, 2014 6:40 PM > To: Black, David; paul.hoffman@xxxxxxxx; mike@xxxxxxxxxxxxx; General Area > Review Team (gen-art@xxxxxxxx); ops-dir@xxxxxxxx > Cc: ietf@xxxxxxxx; http-auth@xxxxxxxx > Subject: Re: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07 > > > Hi David, > > Again thanks for the follow up... > > On 24/12/14 18:40, Black, David wrote: > > Hi Stephen, > > > > Thanks for the response and initial updates - anything that I don't comment > > on further is fine, and everything in this response should now be reduced to > > requests for minor additional text changes: > > > >>> [2] Challenge verification and reuse > >>> > >>> This sentence on p.6 strikes me as subtly dangerous: > >>> > >>> The challenge however is sent over > >>> the network so as to make it simpler for a server to be stateless. > >>> (One form of stateless challenge might be a ciphertext that the > >>> server decrypts and checks, but that is an implementation detail.) > >>> > >>> The draft elsewhere asserts or assumes that challenge reuse can be > >>> prevented by the server or be time-bounded by max-age, and relies on > >>> those reuse limits for security properties, > > > > [... snip ...] > > > >> Hmm. I think that HOBA ought not REQUIRE full replay protection > >> in all cases, that is, it SHOULD be possible to deploy a server > >> that is vulnerable to some replay. The reason is that we're trying > >> to displace passwords here and I believe (without much hard evidence > >> I'll grant you) that we'd lose some deployment chances if we were > >> to insist on every single challenge being fresh. > >> > >> So I'd argue for no-change here, but would welcome further discussion > >> evidence or suggestions for text that's not going to be so onerous > >> as to weaken our chances of getting this deployed. > > > > The word "stateless" is bothering me, > > That's HTTP for ya:-) > > > as doing a good job of replay > > prevention usually requires saving state to remember what has already > > been seen. The following change would address this concern: > > > > OLD > > The challenge however is sent over > > the network so as to make it simpler for a server to be stateless. > > NEW > > The challenge however is sent over > > the network so as to reduce the amount of state that needs to be > > maintained by servers. > > I don't see a useful difference, but I can buy that your wording > is maybe better so I've made that change. > > > > > The rest of the text on replay, including allowing some replay (e.g., > > within max-age) is fine w/me. > > > >>> [4] TLS requirement level > >>> > >>> TLS is only a "SHOULD" requirement for HOBA, not a "MUST" requirement - > >>> first paragraph in Section 8.1 (Privacy Considerations). > >> > >>> If TLS is not a "MUST" requirement, at least a discussion of man-in-the- > >>> middle (MITM) attacks seems to be in order. There's no need for an> > extensive > >>> discussion of all of the security properties of TLS, but MITM attacks are > >>> definitely worth a mention, and that could be complemented by a pointer to > >>> suitable HTTP/TLS security considerations text elsewhere. > >> > >> I think that's covered where we note the potential for replay, which > >> is what a MitM would/could do in this case. That is noted in both > >> section 3 and in 6.1 and in section 8. I think we have it covered to > >> be honest. > > > > Ok, in looking further at the text on TLS, I suggest clarifying the last > > sentence in this text in section 1: > > > > HOBA session management is identical to username/password session > > management, with a server-side session management tool or script > > inserting a session cookie [RFC6265] into the output to the browser. > > HOBA still requires TLS to prevent session cookie hijacking. > > > > This is not a requirement on HOBA interactions - it's on the overall > > HTTP session. Suggestion: > > > > OLD > > HOBA still requires TLS to prevent session cookie hijacking. > > NEW > > Use of TLS for the HTTP session is still necessary to prevent > > session cookie hijacking. > > As above:-) > > > > >>> [5] Section 5.3 - unrecognized key > >>> > >>> Paragraphs 4 and 5 in this section don't seem to belong here, and appear > to > >>> be written in a somewhat loose fashion, particularly around user > verification. > >>> A server that does what is suggested here could have significant security > >>> weaknesses. > >> > >> Which specific weaknesses do you mean? > > > > In this text: > > > > The server >>can<< then use some out-of-band method (such as a > > confirmation email round trip, SMS, or an UA that is already > > enrolled) to verify that the "new" user is the same as the already- > > enrolled one. > > > > and this text > > > > Completion of the joining process >>might<< require confirmation by > > email, SMS, Captcha, and so on. > > > > the use of "can" and "might" appears to make user verification optional, > > which is a poor recommendation for obvious reasons. > > > > The simplest fix would be to change both of those words to "ought to" > > or "should" (lower case). > > Ok, at this point I think we're more into tweaking for the sake of it > so I've not made that change. > > > > >>> [A] ABNF encoding of alg > >>> > >>> In section 2, I see: > >>> > >>> alg = 1*2DIGIT > >>> > >>> o alg: specifies the signature algorithm being used encoded as an > >>> ASCII character as defined in Section 9.3. > >>> > >>> Section 9.3 specifies a single digit. How does that become 1*2DIGIT ? > >> > >> Huh? The current algs only use one digit, but the abnf allows for > >> more. Nothing odd there that I can see. > > > > What if someone uses "01" instead of "1" ? Adding the following variant > > of your response (which is better than my initial proposal) would close off > > this corner case: > > > > Algorithms defined in this document use only one digit; the ABNF > > allows for two digits for future expansion. > > But that's already clear. No change made for now. > > > > >>> [B] Section 5.3 - CPK vs. kid > > > >>> IIUC, the HOBA client sends: > >>> > >>> HOBA-RES = kid "." challenge "." nonce "." sig > >>> > >>> If so, I don't understand how the server extracts a CPK from that. > >> > >> Via the kid yes. > > > > [... snip ...] > > > >> I'm not seeing an actionable issue that needs a change. > > > > The client sends a kid, but the server is supposed to recognize the CPK. > > The description of the server's actions needs to start from the kid, as > > kid->CPK lookup may fail. Here's a possible text change: > > > > OLD > > In the authentication phase, the server extracts the CPK from the > > signing phase and decides if it recognizes the CPK. If the server > > recognizes the CPK, the server may finish the client authentication > > process. > > NEW > > In the authentication phase, the server uses the kid to locate its > > copy of the client's CPK. If the server finds the CPK and recognizes > > that CPK as appropriate for use, the server may finish the client > > authentication process. > > > > That results in a couple of knock-on changes to generalize "recognize" > > to "locate or recognize" - here's the first one: > > > > OLD > > During the authentication phase, if the server does not recognize the > > CPK, > > NEW > > During the authentication phase, if the server cannot locate or does > > not recognize the CPK, > > > > The other one is similar. > > > >>> [C] RSA signature algorithm > > > > [... nit snipped ...] > > > >>> The minor issue is > >>> whether that is the signature algorithm that's wanted, on which I'll defer > >>> to the crypto experts on that (e.g., I seem to recall a negative saag > >>> comment on PKCS 1.5 mechanisms in the past couple of months). > >> > >> Yes, it's fine for security and is correct for interop/deployment > >> reasons. PKCSv1.5 encryption is what's less desirable if not done > >> well and attempting to mandate PSS here would be a bad plan. > > > > Ok, that's what I wanted to see checked. No problem. > > > >>> [D] Javascript local storage. > > > > Again, one word is bothering me - here's a suggested change to the abstract: > > > > 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. > > > > Remove "all" - or change it to "many" or "common". > > I'm gonna stick with all - an implementation of HOBA can be > vulnerable to many things, and one likely but temporary > style of implementation (non-WebCrypto in browsers) will be > vulnerable (as we note) but the protocol itself does avoid > all password problems. > > I'll post -08 in a few minutes with those changes. > > Cheers, > S. > > > > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: Stephen Farrell [mailto:stephen.farrell@xxxxxxxxx] > >> Sent: Wednesday, December 24, 2014 6:15 AM > >> To: Black, David; paul.hoffman@xxxxxxxx; mike@xxxxxxxxxxxxx; General Area > >> Review Team (gen-art@xxxxxxxx); ops-dir@xxxxxxxx > >> Cc: ietf@xxxxxxxx; http-auth@xxxxxxxx > >> Subject: Re: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07 > >> > >> > >> Hi David, > >> > >> Sorry for the slow response, end of year rush and all that... > >> > >> And thanks for the review, responses inline and 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 15/12/14 23:25, Black, David wrote: > >>> This is a combined Gen-ART and OPS-Dir review. Boilerplate for both > follows > >> ... > >>> > >>> I am the assigned Gen-ART reviewer for this draft. For background on > >>> Gen-ART, please see the FAQ at: > >>> > >>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > >>> > >>> Please resolve these comments along with any other Last Call comments > >>> you may receive. > >>> > >>> I have reviewed this document as part of the Operational directorate's > ongoing > >>> effort to review all IETF documents being processed by the IESG. These > comments > >>> were written primarily for the benefit of the operational area directors. > >>> Document editors and WG chairs should treat these comments just like any > other > >>> last call comments. > >>> > >>> Document: draft-ietf-httpauth-hoba-07 > >>> Reviewer: David Black > >>> Review Date: Dec XX, 2014 > >>> IETF LC End Date: Dec 24, 2014 > >>> > >>> Summary: This draft is on the right track, but has open issues > >>> described in the review. > >>> > >>> This draft specifies a signature-based authentication mechanism for HTTP > >>> that is based on asymmetric (public-private) key pairs without using > >>> certificates. A different key pair is used by each user for each for > >>> each host ("web-origin", see [RFC6454]), and each signature is based > >>> on a server-generated challenge. > >>> > >>> The draft is generally well-written and clear on the authentication > >>> mechanics, but has weaknesses in specifying the environment that > >>> surrounds use of this mechanism. Some of these issues are basic things > >>> that anyone working on web technology or applied crypto "just knows", > >>> but even the obvious needs to be stated when it's integral to security. > >>> > >>> -- Major issues: -- > >>> > >>> [1] Challenge size and predictability > >>> > >>> In the ABNF: > >>> > >>> challenge = 1*base64urlchars > >>> > >>> I did not see any other discussion of minimum length of challenge > >>> or amount of entropy in the challenge. For the latter, do the challenges > >>> need to be unpredictable? I would think so. > >>> > >>> I think a requirement on minimum challenge size and a recommendation on > >>> minimum amount of entropy would be good ideas. > >> > >> Fair point. And you're right that this is assumed and ought be > >> explicit, so good catch. > >> > >> OLD: > >> > >> o challenge: MUST be a base64url encoded challenge value that the > >> server chose to send to the client > >> > >> NEW: > >> > >> o challenge: MUST be a base64url encoded challenge value that the > >> server chose to send to the client. The challenge MUST be chosen > >> so that it is infeasible to guess, and SHOULD be indistinguishable > >> from (the base64url encoding of) an at least 128-bit long random > >> string. > >> > >>> > >>> [2] Challenge verification and reuse > >>> > >>> This sentence on p.6 strikes me as subtly dangerous: > >>> > >>> The challenge however is sent over > >>> the network so as to make it simpler for a server to be stateless. > >>> (One form of stateless challenge might be a ciphertext that the > >>> server decrypts and checks, but that is an implementation detail.) > >>> > >>> The draft elsewhere asserts or assumes that challenge reuse can be > >>> prevented by the server or be time-bounded by max-age, and relies on > >>> those reuse limits for security properties, e.g., as in this sentence > >>> near the end of Section 6.1: > >>> > >>> Note that replay of registration (and other HOBA) messages is quite > >>> possible. That however can be counteracted if challenge freshness is > >>> ensured. > >>> > >>> The sentence quoted from p.6 appears to allow (or even encourage) > >>> stateless servers to implement rather weak checks on not only challenge > >>> reuse, but also challenge validity (e.g., what if the challenge validity > >>> test were "challenge mod 1024 == 7" ?). > >>> > >>> Allowing such weak checks could enable an attacker to choose or influence > >>> the choice of challenge values, which could be useful (e.g., for > >>> differential cryptanalysis attack on the hash function), as the > >>> attacker (client) already controls the nonce. > >>> > >>> As part of this, the server needs to check whether a challenge presented > >>> on one connection or session has been reused on another. I think the > >>> following sentence in section 3 is intended to prevent this, but it's > >>> weakened by the "stateless" language above: > >>> > >>> The challenge MUST be > >>> unique for every HTTP 401 response in order to prevent replay > >>> attacks from passive observers. > >>> > >>> Explicit server checks for challenge reuse ought to be REQUIRED, and > >>> the above use of "stateless" needs to be qualified. > >> > >> Hmm. I think that HOBA ought not REQUIRE full replay protection > >> in all cases, that is, it SHOULD be possible to deploy a server > >> that is vulnerable to some replay. The reason is that we're trying > >> to displace passwords here and I believe (without much hard evidence > >> I'll grant you) that we'd lose some deployment chances if we were > >> to insist on every single challenge being fresh. > >> > >> So I'd argue for no-change here, but would welcome further discussionm > >> evidence or suggestions for text that's not going to be so onerous > >> as to weaken our chances of getting this deployed. > >> > >> > >>> > >>> [3] Web origin checks > >>> > >>> I did not see text mandating that TLS (server certificate), HTTP (accessed > >>> URL) and HOBA (signature input) use the same web origin, and stating that > >>> the server has to check/enforce this. Did I miss something? > >>> > >>> I realize that this is an obvious requirement, but it does need to be > >>> stated. > >> > >> Fair enough, I agree folks have been known to not implement even the > >> most obvious things:-) I added the text below to section 3: > >> > >> The server MUST check that the same web origin is used in all of the > >> server's TLS server certificate, the URL being accessed and the HOBA > >> signature. If any of those checks fail, the server treats the > >> signature as being cryptographically incorrect. > >> > >>> > >>> [4] TLS requirement level > >>> > >>> TLS is only a "SHOULD" requirement for HOBA, not a "MUST" requirement - > >>> first paragraph in Section 8.1 (Privacy Considerations). > >>> > >>> If TLS is not a "MUST" requirement, at least a discussion of man-in-the- > >>> middle (MITM) attacks seems to be in order. There's no need for an > >> extensive > >>> discussion of all of the security properties of TLS, but MITM attacks are > >>> definitely worth a mention, and that could be complemented by a pointer to > >>> suitable HTTP/TLS security considerations text elsewhere. > >> > >> I think that's covered where we note the potential for replay, which > >> is what a MitM would/could do in this case. That is noted in both > >> section 3 and in 6.1 and in section 8. I think we have it covered to > >> be honest. > >> > >>> > >>> [5] Section 5.3 - unrecognized key > >>> > >>> Paragraphs 4 and 5 in this section don't seem to belong here, and appear > to > >>> be written in a somewhat loose fashion, particularly around user > >> verification. > >>> A server that does what is suggested here could have significant security > >>> weaknesses. > >> > >> Which specific weaknesses do you mean? > >> > >>> > >>> I strongly recommend replacing those two paragraphs with a short sentence > >> that > >>> says: > >>> - if a kid is unrecognized or the server otherwise determines > >>> that the CPK is not to be used for this HTTP authentication, > >>> - then the Registration (see 6.1) and/or Associating Additional Keys to > >>> an Exiting Account (see 6.2) processes MAY be used instead of > >>> treating this situation as an authentication failure. > >>> > >>> and moving all discussion of user verification into Sections 6.1 and 6.2. > >> > >> Sorry, I don't think that is needed at all. The current text simply > >> reflects the kind of thing that we think deployments will do and will > >> need to do and I don't see what specific weaknesses you are claiming > >> might ensue. I'd be happy to note any such of course. > >> > >> Also, from my reading your suggested text has the same impact and > >> only differs in using a 2119 MAY instead of could, might etc. But if > >> you meant it to differ more substantively you'll need to explain that > >> to me some more. > >> > >>> > >>> -- Minor issues: -- > >>> > >>> [A] ABNF encoding of alg > >>> > >>> In section 2, I see: > >>> > >>> alg = 1*2DIGIT > >>> > >>> o alg: specifies the signature algorithm being used encoded as an > >>> ASCII character as defined in Section 9.3. > >>> > >>> Section 9.3 specifies a single digit. How does that become 1*2DIGIT ? > >> > >> Huh? The current algs only use one digit, but the abnf allows for > >> more. Nothing odd there that I can see. > >> > >>> I suggest: "as an ASCII character" -> "as one or two ASCII digits based > >>> on the IANA registry established by Section 9.3" > >> > >> I think it's ok as is. > >> > >>> This may seem like a nit, but any imprecision in signature algorithm > >>> input can lead to interoperability problems. > >> > >> Yes it can. But we're not being imprecise that I can see. > >> > >>> > >>> [B] Section 5.3 - CPK vs. kid > >>> > >>> In the authentication phase, the server extracts the CPK from the > >>> signing phase and decides if it recognizes the CPK. If the server > >>> recognizes the CPK, the server may finish the client authentication > >>> process. > >>> > >>> That seems wrong. IIUC, the HOBA client sends: > >>> > >>> HOBA-RES = kid "." challenge "." nonce "." sig > >>> > >>> If so, I don't understand how the server extracts a CPK from that. > >> > >> Via the kid yes. > >> > >>> > >>> I suspect that what was intended is that the server extracts a key > >> identifier > >>> (kid) and then determines a) whether it knows a CPK for that kid and b) > >> whether > >>> it allows use of that kid/CPK for this authentication. At least a) seems > to > >>> be indicated by this text in Section 3: > >>> > >>> The server MUST check the cryptographic correctness of the signature > >>> based on a public key it knows for the kid in the signatures, > >> > >> I'm not seeing an actionable issue that needs a change. > >> > >>> > >>> [C] RSA signature algorithm > >>> > >>> Section 7 says: > >>> > >>> RSA is defined in > >>> Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS]. > >>> > >>> Section 8.2 of RFC 3447 specifies RSASSA-PKCS1-v1_5. At a minimum, that > >>> algorithm name should be stated here (which is a nit). > >> > >> Disagree (also as a nit:-) > >> > >>> The minor issue is > >>> whether that is the signature algorithm that's wanted, on which I'll defer > >>> to the crypto experts on that (e.g., I seem to recall a negative saag > >>> comment on PKCS 1.5 mechanisms in the past couple of months). > >> > >> Yes, it's fine for security and is correct for interop/deployment > >> reasons. PKCSv1.5 encryption is what's less desirable if not done > >> well and attempting to mandate PSS here would be a bad plan. > >> > >>> > >>> [D] Javascript local storage. > >>> > >>> The first paragraph of Section 8.2 on this topic concludes with: > >>> > >>> It's not clear that we > >>> introduce unique threats from which clear text passwords don't > >>> already suffer. > >>> > >>> That's at odds with the use of "all" in this sentence in the abstract: > >>> > >>> 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. > >>> > >>> One of those two paragraphs needs some editing. > >> > >> I don't think so actually, the first quoted sentence above is in the > >> context of a web site with XSS vulnerabilities. Omitting that context > >> would make for bad text, but the immediately preceding sentence is > >> fairly explicit on that. > >> > >> (In passing, I did edit the top of that para a bit, since using the > >> WebCrypto API is now possible so a tweak was needed.) > >> > >>> > >>> -- Nits/editorial comments: -- > >>> > >>> This is buried near the end of section 6.1 > >>> > >>> Note that replay of registration (and other HOBA) messages is quite > >>> possible. That however can be counteracted if challenge freshness is > >>> ensured. > >>> > >>> That's not a good place for these two sentences. HOBA registration > >>> messages don't contain a challenge, and the general discussion of > >>> replay attacks belongs under Security Considerations, not Registration. > >> > >> They do contain a challenge in the header, though not in the body. > >> I think the sentence is ok where it is. > >> > >>> > >>> In Section 9.4 and 9.5, I see the following proposed as part of IANA > >>> registry contents: > >>> > >>> an unformatted string, at the user's/UA's whim > >>> > >>> I get the point, but it's still not appropriate for an IANA registry > >>> - remove ", at the user's/UA's whim". > >> > >> I whimsically disagree:-) IANA shouldn't be against whimsy. > >> > >>> Appendix A appears to assume that human-memorable passwords are stored in > >>> the clear in server databases. It should also briefly discuss the use > >>> of one-way functions, especially computationally intensive ones, to > >>> generate stored password verifiers. HOBA is still superior by comparison, > >>> as the one-way functions only increase the difficulty of dictionary > >>> attack, whereas dictionary attack on HOBA keys is pointless when > >>> sufficiently large keys are used. > >> > >> I'd prefer to not get into more analysis of passwords, and even hashed > >> passwords are essentially guessable. > >> > >>> > >>> idnits 2.13.01 found the references to W3C's web site (www.w3.org) in > >>> Section 4, e.g., > >>> > >>> 389 One element is required for HOBA-js: localStorage (see http:// > >>> 390 www.w3.org/TR/webstorage/) from HTML5 can be used for > persistent key > >>> 391 storage. > >>> > >>> I think idnits can be ignored, even though the "right way" to fix this is > to > >>> move each URL to a reference and cite the reference in Section 4. > >>> > >>> OTOH, idnits did not complain about the normative reference to RFC 20 ;-). > >> > >> Heh:-) > >> > >>> > >>> --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- > >>> > >>> Most of these questions are n/a because this draft describes an extension > >>> to HTTP authentication, and RFC 5706's concerns would apply primarily to > >>> HTTP and HTTP authentication. > >>> > >>> A.1.1 Has deployment been discussed? > >>> > >>> Yes, section 6 discusses how a user would deploy this for her access to > web > >>> servers. > >>> > >>> A.1.4. Have the Requirements on other protocols and functional > >>> components been discussed? > >>> > >>> Yes, the discussion of how this functions within HTTP is sufficient. > >>> > >>> Major issues [3] and [4] fall into this category, but in both cases, > >>> I think they're probably text oversights that are easy to fix. > >>> > >>> A.2.7 Is security management discussed? > >>> > >>> Not really, but this is an Experimental RFC. I would expect that the > >>> experimental use of HOBA will yield insight into server key database > >>> structure/management, key lifecycle management (e.g., revocation), > >>> account management techniques/processes, etc. > >>> > >>> A.3. Documentation > >>> > >>> I do not expect significant operational impact. > >>> > >>> Section 10 notes the existence of two implementations of HOBA-JS and > >>> one implementation of HOBA-http. That's a good start for an experiment. > >> > >> And now there's a 3rd! > >> > >> Thanks again for the fine review, > >> S. > >> > >> > >>> > >>> Thanks, > >>> --David > >>> ---------------------------------------------------- > >>> David L. Black, Distinguished Engineer > >>> EMC Corporation, 176 South St., Hopkinton, MA 01748 > >>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > >>> david.black@xxxxxxx Mobile: +1 (978) 394-7754 > >>> ---------------------------------------------------- > >>> > >>> > >>>