Subject: [http-auth] Comments on draft-ietf-httpauth-hoba-01

From: Yaron Sheffer <[email-masked]>
Date: Fri, 26 Jul 2013 08:25:24 +0200

Thank you for publishing this protocol. I enjoyed especially the 
implementation hints, and the protocol parts (registration etc.) that go 
beyond plain authentication.

- You mention that the credentials are not susceptible to phishing . But 
the protocol doesn't do mutual authentication. So the *user* is in fact 
susceptible, but of course the attacker will not be able to steal the 
user's credentials.
- TBS string: I suggest that this string should have separators between 
scheme, hostname and port. Otherwise you different URLs will map into 
the same signature.
- 3: " to prevent replay attacks from passive observers" - sounds 
strange to me. I thought replay attacks were always active.
- General comment: in between memorizable passwords and public keys, 
there are (per-server) crypto-strength PSK. HOBA could be built around 
long PSKs with little change, and it's not clear which would have been 
better. Public keys are probably more secure during the registration 
phase. But PSK provide mutual authentication which I think adds 
significant security.
- 5.5: please also add a nonce based method. Time sync is easy nowadays. 
The replay cache is a hassle and people might decide to skip it.
- 5.6: the example is not validly URL encoded, because of the "@" character.
- Similarly when you say that a string is base64 encoded, it should be 
encoded with a URL-safe variant of base64, or the resulting base64 
should be URL encoded.
- In general, the examples hint at consumer use cases (get an SMS and 
you're in). I would like to also see enterprise cases, where e.g. an 
admin must approve your registration.
- Privacy: an easy way around it is to allow the client to change its 
CPK whenever it feels like it.
- 8.1: the second part of the last paragraph is in general incorrect. An 
attacker will get access to all of your local storage, which very likely 
will have your keys for *all* of the services you are using. So with 
respect to this attack vector, there is no difference from using passwords.

Regards,
     Yaron

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 26 Jul 2013 13:35:06 +0100

Hi Yaron,

Thanks for the review.

> susceptible, but of course the attacker will not be able to steal the

Well, I guess it depends what you call phishing I suppose, but what
we meant was that there's no way a user will ever be tricked into
typing a HOBA private key. But you are right that we need more on
the security considerations of HOBA for sure (text welcome!).

> scheme, hostname and port. Otherwise you different URLs will map into

Paul and Mike asked me that too and I didn't have a good answer.
That's just what I did in my code and even I couldn't remember
why:-)

So I suspect either I'll re-discover a reason why or else we'll
add back the syntactic sugar.

I don't see that different origins could be confused though, got
an example?

> strange to me. I thought replay attacks were always active.

Fair point.

> phase. But PSK provide mutual authentication which I think adds

IMO a PSK like beast would be sufficiently different that it ought
be a different HTTP auth scheme.

> The replay cache is a hassle and people might decide to skip it.

Reasonable point. As I said before we need to do a serious merger
of the hoba-js and hoba-http text.

> - 5.6: the example is not validly URL encoded, because of the "@"

Ack.

> encoded with a URL-safe variant of base64, or the resulting base64

Ack.

> admin must approve your registration.

Text suggestions welcome I guess. OTOH, it might be better to keep
away from enterprise related text since that always gets way too
complicated.

> CPK whenever it feels like it.

Yep. Been thinking about that a bit. Given that you'd maybe need a
newWithOld signature or something though it might not be that good
for privacy, and it might be more complex than we want to take on
for an experimental RFC. So not sure on that one.

> respect to this attack vector, there is no difference from using passwords.

Well, depends on the attacker model. I agree we need more text but
there are attackers who'd still be constrained by the same origin
policy and those'd only get the key for one origin. But yes, there
are attackers who'd get all of localStorage and we need to say
something about that.

Cheers,
S.

PS: When we get around to shooting out a -02 I'll circle back and
try say what we did related to the above, but feel free to offer
text in the meantime, if you've time. And I guess we'll discuss this
a bit in Berlin too.

> 
> Regards,
>     Yaron
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
> 
>

---

From: Michael Sweet <[email-masked]>
Date: Fri, 26 Jul 2013 09:43:24 -0400

Stephen,

On Jul 26, 2013, at 8:35 AM, Stephen Farrell <[email-masked]> wrote:
> ...

I think it is enough to give examples of what the registration page might do or ask for and to define a low-level interface that supports multi-step registration.  We don't need to do an exhaustive design of an enterprise registration scheme, we just need to allow for a (somewhat) long-lived registration process.

And FWIW, I think even an enterprise use case where an admin approves the registration would still want a PIN or something as a final confirmation of the client's (user's) identity.

>From the perspective of changing the CPK, seems like associate-start (to get the new CPK) and logout (to retire the old CPK) gets us there in the current draft.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Michael Thomas <[email-masked]>
Date: Fri, 26 Jul 2013 08:13:43 -0700

On 7/25/13 11:25 PM, Yaron Sheffer wrote:

> - General comment: in between memorizable passwords and public keys, there are (per-server) crypto-strength PSK. HOBA could be built around long 
> PSKs with little change, and it's not clear which would have been better. Public keys are probably more secure during the registration phase. But 
> PSK provide mutual authentication which I think adds significant security.
In fact for one of us (me), auto-generated psk's on the client side was the route that
led to the general HOBA idea. What became apparent is that even though there was
far less risk of the password sharing problem, the server was still carrying passwords
in some form or another, and so it would still be at risk for attacks to get them (hashed
or otherwise).

I think that the larger win is not to get rid of passwords, per se, but to get rid of passwords
(or psk's) on servers so that isn't a reason to target them specifically. True enough, random
and site-different psk's get you most of the way, but it seems like just taking it to its logical
conclusion of the server only having public information for credentials is a win too. As far
as mutual auth, TLS is still our friend in many, many ways.

> - 8.1: the second part of the last paragraph is in general incorrect. An attacker will get access to all of your local storage, which very likely 
> will have your keys for *all* of the services you are using. So with respect to this attack vector, there is no difference from using passwords.

While I'm not convinced it's quite this dire, what we've concluded is that webcrypto is
definitely the route we want to go when it makes its way into browsers.

I wrote this: http://rip-van-webble.blogspot.com/2012/06/localstorage-secuity.html
going over the attacks on localstorage that I could think of. Feel free to pick it apart
because it obviously has implications far beyond HOBA :)

Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 26 Jul 2013 08:23:22 -0700

> And FWIW, I think even an enterprise use case where an admin approves the registration would still want a PIN or something as a final confirmation of the client's (user's) identity.

Right, this is why this is all non-normative text. In some use cases, the (re)enrollment
may be extremely fussy, difficult and potentially manual. It's all the standard risk/useability
tradeoff for which we're not really providing anything new.

As far enterprise-y enrollment, maybe the right thing is to move this all into a non-normative
appendix with several use cases clearly listed as examples? My intention with the hoba-js
section was more to show how a particular use case could be achieved (ie, a standard consumer-y
oriented web site which stores relatively uninteresting data from the hacker POV).

Mike

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 28 Jul 2013 09:50:06 +0200

Hi Stephen,

please see below.

Thanks,
	Yaron

> the security considerations of HOBA for sure (text welcome!).
I believe the Ultimate Reference (wikipedia, what else) supports my 
definition. Anyway, how about:

8.2 Server Authentication

HOBA is responsible for authenticating the web service client. This 
cannot present attacks by malicious hosts masquerading as the original 
server. Although such attackers will not be able to obtain the user's 
credentials, they may obtain other sensitive information. Therefore, 
HOBA MUST be used with strong server authentication.

> I don't see that different origins could be confused though, got

I suppose an easy one would be https://lot.org vs. http://slot.org.

> are attackers who'd get all of localStorage and we need to say

I agree but please clarify the text in 8.1.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 28 Jul 2013 09:58:54 +0100

Hi Yaron,

> HOBA MUST be used with strong server authentication.

I like that basically though I think s/MUST/SHOULD/ would be better.

I would however like the "MUST" if all httpauth documents incl Basic
go for "MUST run over TLS" which I'd be fine with. Maybe that'd be
a good topic for this week?

> I suppose an easy one would be https://lot.org vs. http://slot.org.

Ouch. Yep, that's a straight "gotcha" :-) Will make that change.

> I agree but please clarify the text in 8.1.

Will do,
S.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 28 Jul 2013 12:10:05 -0700

On 07/28/2013 12:50 AM, Yaron Sheffer wrote:
> HOBA is responsible for authenticating the web service client. This cannot present attacks by malicious hosts masquerading as the original server. Although such attackers will not be able to obtain the user's credentials, they may obtain other sensitive information. Therefore, HOBA MUST be used with strong server authentication.

TLS is of course goodness, but I'm not sure whether there's anything intrinsic to
HOBA that makes the situation worse. If there isn't is there really a reason to
place a requirement that is just as applicable to password based auth? If there
is, can you outline the attack and how it is unique to HOBA?

Mike

---

From: Michael Thomas <[email-masked]>
Date: Sun, 28 Jul 2013 12:21:55 -0700

> a good topic for this week?

The problem is that it's mostly an empty gesture: most credentials
are carried in HTTP POST's completely outside of standardization's
reach. If we really wanted to make a difference, we should deprecate
the http scheme.

Mike

---

From: Yoav Nir <[email-masked]>
Date: Sun, 28 Jul 2013 20:57:14 +0000

> reach. If we really wanted to make a difference, we should deprecate

Hi

<hat type="chair" position="on">

It's fine for a particular draft to list issues with using the protocol over a non-secure transport. It's even fine to say that a particular method MUST NOT be used on the Internet unless a secure transport is used. 

However, deprecating HTTP is really, really outside the scope of this working group. I don't think any working group in any area could make such a statement in an RFC without the IESG and probably the IAB weighing in. This was considered ([1]) by the httpbis working group (which is a far more fitting home for such a discussion), and by IETF 84 it was clear ([2]) that there was no consensus to make such a recommendation, even for HTTP/2.0.

Before starting this working group, we all knew that credentials are carried in POSTs, although I believe that they're mostly POSTs over HTTPS, os I don't see how deprecating HTTP (assuming the IETF has enough hubris to try dictating this to the world) would make a difference. 

</hat>

Yoav

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0251.html (section 2.2, and then a lot of other mailing list posts for the next few weeks).
[2] http://www.ietf.org/proceedings/84/minutes/minutes-84-httpbis  (look for the string "mandatory TLS")

---

From: Michael Thomas <[email-masked]>
Date: Sun, 28 Jul 2013 14:07:56 -0700

> Before starting this working group, we all knew that credentials are carried in POSTs, although I believe that they're mostly POSTs over HTTPS, os I don't see how deprecating HTTP (assuming the IET…

That's rather my point though. The http scheme is the root of the problem here, not
HOBA. At least as far as I can tell. We shouldn't be writing in MUST's for new protocols
to use https just because we know that http has a lot of brokenness. It suggests that
there *are* problems beyond the usual http ones, which is the wrong message.

Mike