The -08 draft addresses all of the important issues in the combined Gen-ART and OPS-Dir review of the -07 version, and is a definite improvement over its -07 version. Based on discussion of item [5], there are a couple of remaining editorial nits in Section 5.3: During the authentication phase, if the server cannot determine the correct CPK, it could use HTML and JavaScript to ask the user if they are really a new user or want to associate this new CPK with another CPK. The server can then use some out-of-band method (such as a "can" -> "should" 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. Thus, logging in on a new user agent is identical to logging in with an existing account. If the server does not recognize the CPK the server might send the client through a either a join or login-new-UA (see below) process. "might" -> "should" I agree w/the draft editor that these are matters of editorial taste. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Monday, December 15, 2014 6:25 PM > To: stephen.farrell at cs.tcd.ie; paul.hoffman at vpnc.org; mike at phresheez.com; > General Area Review Team (gen-art at ietf.org); ops-dir at ietf.org > Cc: ietf at ietf.org; http-auth at ietf.org; Black, David > Subject: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07 > > 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 15, 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. > > [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. > > [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. > > [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. > > [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. > > 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. > > -- 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 ? > I suggest: "as an ASCII character" -> "as one or two ASCII digits based > on the IANA registry established by Section 9.3" > > This may seem like a nit, but any imprecision in signature algorithm > input can lead to interoperability problems. > > [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. > > 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, > > [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). 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). > > [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. > > -- 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. > > 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". > > 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. > > 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 ;-). > > --- 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. > > 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 at emc.com        Mobile: +1 (978) 394-7754 > ----------------------------------------------------