Subject: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07

From: "Black, David" <[email-masked]>
Date: Mon, 15 Dec 2014 23:25:14 +0000

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.

[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
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Black, David" <[email-masked]>
Date: Mon, 15 Dec 2014 23:27:36 +0000

> IETF LC End Date: Dec 24, 2014

Got everything except the header - review date is Dec 15, 2014.

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Monday, December 15, 2014 6:25 PM
> To: [email-masked]; [email-masked]; [email-masked];
> General Area Review Team ([email-masked]); [email-masked]
> Cc: [email-masked]; [email-masked]; Black, David
> Subject: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Dec 2014 11:15:08 +0000

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

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

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

> I realize that this is an obvious requirement, but it does need to be

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.

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

> A server that does what is suggested here could have significant security

Which specific weaknesses do you mean?

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

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

> on the IANA registry established by Section 9.3"

I think it's ok as is.

> input can lead to interoperability problems.

Yes it can. But we're not being imprecise that I can see.

> If so, I don't understand how the server extracts a CPK from that.

Via the kid yes.

>    based on a public key it knows for the kid in the signatures,

I'm not seeing an actionable issue that needs a change.

> algorithm name should be stated here (which is a nit).  

Disagree (also as a nit:-)

> The minor issue is

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.

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

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

> - remove ", at the user's/UA's whim".

I whimsically disagree:-) IANA shouldn't be against whimsy.

> sufficiently large keys are used.

I'd prefer to not get into more analysis of passwords, and even hashed
passwords are essentially guessable.

> OTOH, idnits did not complain about the normative reference to RFC 20 ;-).

Heh:-)

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

---

From: "Black, David" <[email-masked]>
Date: Wed, 24 Dec 2014 18:40:11 +0000

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:

> > those reuse limits for security properties,

[... snip ...]

> So I'd argue for no-change here, but would welcome further discussion

The word "stateless" is bothering me, 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.

The rest of the text on replay, including allowing some replay (e.g.,
within max-age) is fine w/me.

> > middle (MITM) attacks seems to be in order.  There's no need for an> extensive

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.

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

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

> > IIUC, the HOBA client sends:
> >

[... 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 ...]

> 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

Remove "all" - or change it to "many" or "common".

Thanks,
--David

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, December 24, 2014 6:15 AM
> To: Black, David; [email-masked]; [email-masked]; General Area
> Review Team ([email-masked]); [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07
> 
> 
> Hi David,
> 
> 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
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 26 Dec 2014 23:40:17 +0000

Hi David,

Again thanks for the follow up...

On 24/12/14 18:40, Black, David wrote:
> The word "stateless" is bothering me, 

That's HTTP for ya:-)

> as doing a good job of replay

I don't see a useful difference, but I can buy that your wording
is maybe better so I've made that change.

>    session cookie hijacking.

As above:-)

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

> 	allows for two digits for future expansion.

But that's already clear. No change made for now.

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

---

From: "Black, David" <[email-masked]>
Date: Sat, 27 Dec 2014 02:44:52 +0000

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

> Sent: Friday, December 26, 2014 6:40 PM
> >>> This is a combined Gen-ART and OPS-Dir review.  Boilerplate for both
> follows
> >> ...
> >>>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 27 Dec 2014 03:16:17 +0000

On 27/12/14 02:44, Black, David wrote:
>  in addition to
> what's noted below, -08 also addresses [B] 

Oops - yes I did make changes (which are real improvements) there
but didn't note those in my mail. Sorry for the omission - it was
simply due to window-bloat but your comment in that case was good.

Cheers,
S.