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