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