Subject: [http-auth] Channel binding

From: Yaron Sheffer <[email-masked]>
Date: Thu, 16 Dec 2010 08:44:49 +0200

Hi Henry,

I agree that channel bonding (a.k.a. binding) is essential for this type 
of solution. But unfortunately it is not a complete solution. Look at 
the following scenario:

1. Client connects to server with unauthenticated TLS (e.g. DHE).
2. Client received a login page.
3. Client uses the login page for mutual-auth HTTP authentication, e.g. SRP.
4. Client receives indication of successful authentication, 
cryptographically bound to the TLS channel (the shared DH key).

This is all very well, except that when the login page is used, it is 
still completely unauthenticated, and it might well send your precious 
password to evil-guy.com. It can be devious enough to BOTH send your 
password away and also correctly authenticate you. At best you will know 
that the HTML page was bogus after the fact, when the cryptographic hash 
fails to check.

Thanks,
Yaron
> Date: Wed, 15 Dec 2010 16:41:58 -0800
> From: "Henry B. Hotz"<[email-masked]>
> Subject: Re: [http-auth] The Mutual Auth Draft
> To: Tim<[email-masked]>
> Cc: "[email-masked]"<[email-masked]>
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Dec 15, 2010, at 1:19 PM, Tim wrote:
>
>> But I think in general, if users are vulnerable to SSL/TLS
>> man-in-the-middle attacks, they are probably susceptible no matter
>> what you do, given current browser implementations.
> Not if the http-auth is bonded to the TLS channel.  Then the http-auch could detect the MITM and fail.  The new, incompatible Microsoft extensions to Negotiate do this.
>
> With channel bonding, you *could* base your trust of the TLS channel entirely on a properly-implemented mutual auth at the http layer and solve all the problems with the 100+ pre-trusted CAs.  I know one Microsoft developer who is considering if the CA warnings from the TLS negotiation in IE can be postponed until after the HTTP-Negotiate handshake is complete so they can be suppressed if they aren't relevant.
>
> This is what I mean when I say that channel bonding is necessary for anything we do at the HTTP layer to be a significant improvement over the status quo.
>
> The only alternative would be some kind of security layer in http (which would make TLS unnecessary).
>
>> Now, stepping back, if we truly wanted to say that authentication
>> should not be based in HTML forms, then we need to ditch the idea
>> of customization completely.  This involves changing user and
>> developer behavior, which is hard.
> +1, but I think it's necessary.  See other email.
>
> Fallback to a current style login form is clearly unavoidable for now.
>
>> Moving the login fields up next to the URL bar, as suggested by the
>> Mutual auth folks, might be a solid benefit to security, by mitigating
>> the fake popup problem I mention, but it isn't yet clear what other
>> tricks might be possible.  (Note that in the past, browsers have
>> commonly had vulnerabilities where HTML content could overlay
>> URL/status bars, though most of these have probably been fixed.)
> ------------------------------------------------------
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> [email-masked], or [email-masked]

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 15 Dec 2010 23:19:42 -0800

Channel bonding must be done in both directions (mutual auth, not necessarily in the sense of the draft by that name), and the user must not use a "login page" but some kind of prompt in the window chrome.  Then the scenario is secure.

I seem to be an extremest on these points, but I think anything short of them doesn't get us meaningful improvement over the current situation.  At least nobody is *calling* me an extremest.

On Dec 15, 2010, at 10:44 PM, Yaron Sheffer wrote:

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

---

From: Marsh Ray <[email-masked]>
Date: Thu, 16 Dec 2010 02:50:42 -0600

On 12/16/2010 01:19 AM, Henry B. Hotz wrote:
> Channel bonding must be done in both directions (mutual auth, not
> necessarily in the sense of the draft by that name),

Except of course for cases where one or both endpoints are intentionally 
anonymous. Which could possibly be some interesting applications.

In my mind, another essential characteristic of true mutual auth is that 
neither side is forced to "front money". I.e., like the zero-knowledge 
schemes and very much unlike this top selling certificate authority 
(godaddy.com) that foolishly puts a username and password login box on 
their unencrypted home page.

However, I am a little concerned that schemes which require the server 
to store a plaintext password (or password-equivalent) may not be 
deployable by sites that must comply with standards like PCI or SAS 70. 
Auditors tend to greatly frown on anything other than properly salted 
hases on the back-end systems. My personal feeling is that no one should 
use a standard like that as an excuse not to do better. But there is a 
legitimate point there too, about half the users will be using that same 
password everywhere. (Of course, those same users' hashes would probably 
fall to a dictionary attack in under millisecond anyway).

> and the user
> must not use a "login page" but some kind of prompt in the window
> chrome.  Then the scenario is secure.

I agree it's critical that the user enters their password in the chrome 
outside the untrusted rectangle. But even that is not quite enough.

In order to be secure, the user must be completely unwilling to enter 
their password anywhere else. Even (especially) if a picture of a 
similarly-official-looking password prompt box appears within the 
untrusted rectangle.

To all non-security-oriented users, developers, and interaction 
designers, this is not a distinction that they will take seriously. 
After all, why should they optimize the UI around an interaction that 
mostly shouldn't happen? This is reasonable if you think in terms of 
efficiency, ergonomics, and everyday experience. You can tell this 
reasoning is coming through when you hear them (or yourself) saying:
"what are the _chances_ that this would actually be an attacker?"

The reason, of course, is that normal people do not go through life 
considering the possibility that they are under attack as they pursue 
ordinary activities such as surfing the web. That is a very healthy way 
to live, IMHO, and such people will probably live longer that I will.

People count on their nose to warn them of smoke and fire, their ears to 
warn them of high-speed object, and their eyes to tell them if something 
doesn't "look right". Everything else gets filed away with earthquakes: 
events that are impartially random and you can't do much about. The most 
important thing to do with those risks you can't prepare for is to make 
sure that you don't waste energy worrying about them.

But unlike most other dangers life has prepared us for, computer 
attackers cannot always be perceived through the normal senses.

This is why phishing attacks against users is so successful: it's 
trivial for the attacker to mimic all the important visual cues of a 
trusted web site.

Equally important, attackers are not statistical like earthquakes. An 
attacker is an intelligent entity. He gets to decide whether or not this 
time it's a real attack. You might reliably measure attacks to come at 
the rate of say, one attack per 1000 connection attempts. If you base 
your assumptions on only a one-in-1000 "chance" of the unauthenticated 
party being an attacker, you will lose every time.

This is also why determined attackers are always successful against 
internet apps constructed by very skilled but non-security-oriented 
developers: Such developers are typically productive in inverse 
proportion to the amount of time and energy they spend worrying about 
scenarios that  undermine their whole design model and aren't supposed 
to happen in theory anyway. If my big web app performs 1000 string 
interpolations, and attackers come 1-in-1000, then I have a million 
better things to worry about than preemptively finding that one little 
SQL injection or XSS bug.

> I seem to be an extremest on these points, but I think anything short
> of them doesn't get us meaningful improvement over the current
> situation.  At least nobody is *calling* me an extremest.

Hey, takes one to know one ;-)

Actually, we can take it one step farther:

If you agree with the point that "the user must be completely unwilling 
to enter their password anywhere else", what then?

Doesn't that imply that the safest app would have to be one that 
occasionally tries to trick the user into entering their credentials in 
an insecure place (a simulated phishing site) and then punishes the user 
in some harmless way if they fall for it?

- Marsh

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 16 Dec 2010 13:37:32 +0200

Hi Marsh,

as you can see from Yoav's earlier mail, not all password-based mutual 
auth systems require storage of the plaintext password. The original EKE 
did (and even there you can replace the password by a hashed 
"password-equivalent"). But other schemes do not.

Thanks,
     Yaron

On 12/16/2010 10:50 AM, Marsh Ray wrote:
> Except of course for cases where one or both endpoints are 
> intentionally anonymous. Which could possibly be some interesting 
> applications.
>
> In my mind, another essential characteristic of true mutual auth is 
> that neither side is forced to "front money". I.e., like the 
> zero-knowledge schemes and very much unlike this top selling 
> certificate authority (godaddy.com) that foolishly puts a username and 
> password login box on their unencrypted home page.
>
> deployable by sites that must comply with standards like PCI or SAS 
> 70. Auditors tend to greatly frown on anything other than properly 
> salted hases on the back-end systems. My personal feeling is that no 
> one should use a standard like that as an excuse not to do better. But 
> there is a legitimate point there too, about half the users will be 
> using that same password everywhere. (Of course, those same users' 
> hashes would probably fall to a dictionary attack in under millisecond 
> anyway).
>
> [...]

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 16 Dec 2010 10:45:01 -0600

On Thu, Dec 16, 2010 at 08:44:49AM +0200, Yaron Sheffer wrote:
> Hi Henry,
> 
> I agree that channel bonding (a.k.a. binding) is essential for this
> type of solution. But unfortunately it is not a complete solution.
> Look at the following scenario:
> 
> This is all very well, except that when the login page is used, it
> is still completely unauthenticated, and it might well send your
> precious password to evil-guy.com. It can be devious enough to BOTH
> send your password away and also correctly authenticate you. At best
> you will know that the HTML page was bogus after the fact, when the
> cryptographic hash fails to check.

This is all true today anyways, if you think that the "PKI" we use today
isn't all that trustworthy.

(Note that channel binding is NOT about enabling DHE (though that is a
nice side effect) nor does it require the use of DHE.  I don't think you
were saying that, but others might think you were.)

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 16 Dec 2010 10:52:28 -0600

On Wed, Dec 15, 2010 at 11:19:42PM -0800, Henry B. Hotz wrote:
> necessarily in the sense of the draft by that name), and the user must
> not use a "login page" but some kind of prompt in the window chrome.
> Then the scenario is secure.

Is "bonding" some sort of compromise to avoid terminology conflict
with EAP?  To me "channel bonding" sounds like NIC bonding -- it sounds
as if one is trying to treat two parallel channels as one.

> situation.  At least nobody is *calling* me an extremest.

My view is that it'd be ok for there to be a login page with one
element, presented however the service likes, that can be used to start
authentication.  Everything else should be under user and browser
control.  Things that fall under "everything else" in the previous
sentence:

 - credential selection
 - credential acquisition (typing in passwords, PINs, whatever)
 - secure attention paths by which the user can determine the
   authentication status of a [potentially full-screen] page

EXCEPTION: I don't mind making an exception for logins to IdPs, where
those could happen as a traditional HTML form POST, but here I'd really
like the browser to not just rely on the PKI but to actually learn IdPs'
certificates.  Why don't I mind this?  Because I don't mind POSTing
forms if there's very few places to post them to and very few passwords
to POST that way -- for me one of the biggest problems here is the
multiplicity of passwords that users must remember, write down, or
ensure are all the same.

Nico
--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 16 Dec 2010 09:48:49 -0800

> as if one is trying to treat two parallel channels as one.

I seem to have been saying "bonding" when I should have been saying "binding".  Apologies.

> multiplicity of passwords that users must remember, write down, or

Speaking as a purist, I can disagree.  (Why is an IDp less likely to be vulnerable to spoofing/hijacking/whatever than anything else?)  I understand your rationale though.  Pragmatically, it will be a long time before we can get where we should be.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 16 Dec 2010 12:06:57 -0600

> I seem to have been saying "bonding" when I should have been saying

But you're not the only one -- y'all had me wondering if there was a
movement to rename the term...

> Speaking as a purist, I can disagree.  (Why is an IDp less likely to
> be vulnerable to spoofing/hijacking/whatever than anything else?)  I
> understand your rationale though.  Pragmatically, it will be a long
> time before we can get where we should be.

My exception is there for pragmatic reasons as well, though I have more
such reasons than the one you give.  Migration time is one reason (yours
and mine), but also there's the fact that (I think) any authentication
mechanism not based on storing secret keys on smartcards is going to
have weaknesses somewhat comparable to the vulnerability of the user to
IdP impersonation (which has reasonable mitigations) -- and I don't
think universal smartcard deployment is something we can count on.

Nico
--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 16 Dec 2010 10:42:07 -0800

> think universal smartcard deployment is something we can count on.

I think we still agree, I just didn't want to use too much bandwidth on the subject since I don't have a really good solution.  Best I see is http://tools.ietf.org/html/draft-ietf-krb-wg-otp-preauth-13 with soft tokens.

I've not looked at the mobile-phone proposals.

---

From: Tim <[email-masked]>
Date: Thu, 16 Dec 2010 11:12:26 -0800

> I think we still agree, ...

So yes, I think we all more or less agree on what is needed, though
each of us has our own focus areas.

Let me see if I can reframe the ideas around a task/project list of
sorts:

Un-phishable User Interface
===========================
Assertion: If official login forms can be easily mimiced visually by
malicious sites, then phishing will always be possible. 

Reasoning: This is because most users don't understand how to validate
what domain they are at, thereby destroying the utility of the SSL/TLS
PKI. While SRP/Mutual/EKE/et al protocols can guarantee protocol-level
protections against MitM attacks based on the credentials supplied by
the user, phishing-style MitM will continue to undermine this.  

Solution: The only realistic way to correct this is to move the login
interface squarely into the browser, visually.  The most logical
protocol implementations are, therefore, ones which involve moving
authentication to the HTTP and/or TLS layers so user agents can easily
interact with them.

Credential Management and Federation
====================================
Assertion: A separate user password for every site does not scale and
leads to security problems.

Reasoning: It should be obvious, but O(M*N) is clearly not working and
users tend to use the same passwords on multiple sites, store them
insecurely, or pick weak passwords because it is too hard to manage
otherwise.

Solution: In my mind there are many possible solutions, and most of
you are probably far more familiar than I am with the current (many)
efforts to solve this problem.  At a high level theoretical
standpoint, one could manage this in one of two ways: 
  * centralized password stores managed by users which interact with
    other multiple sites (can be stored in browser, stored in "the
    cloud" via federated auth, etc)

  * client certificates that can be reused on multiple sites
    (hopefully without creating privacy problems).

Each have their strengths and drawbacks.

Transitions
===========
Assertion: Adoption of more secure authentication requires low barrier
to entry for developers and users.

Reasoning: Most users and developers have only a fuzzy idea of how new
protocols might make their sites more secure and typically are willing
to invest very little energy to move to new protocols.

Solution: We have already outlined a transition plan from form+cookie
authentication to HTTP authentication utilizing XMLHttpRequest
objects and altered 401 behavior.  

However, this does not necessarily take into account possible
underlying protocol solutions which involve TLS/SRP/Certificate/other
authentication or the possibility of federation.  To allow for smooth
transitions to federated authentication, adjustments may need to be
made (soon) to the proposed XMLHttpRequest interface standard.
Recommendations to browsers on user interface changes should also take
into account future federation support. 

Finally, I think if HTTP authentication is a big part of the solution,
then some recommendations for transitioning from Basic/Digest/etc to a
better authentication protocol would be necessary.  Namely, a way to
prevent downgrade attacks either through UI indicators or through
mechanisms similar [1], or both.

Did I miss anything?
tim

1. http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-hodges-strict-transport-sec

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 16 Dec 2010 14:42:49 -0600

> I've not looked at the mobile-phone proposals.

Mobile phones are general purpose computers.  Therefore they change
nothing.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 16 Dec 2010 13:50:15 -0800

> Mobile phones are general purpose computers.  Therefore they change

No, but they are highly motivated to find a cost-effective way to deploy client x.509 certs, or something serving a similar purpose.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 16 Dec 2010 15:58:31 -0600

On Thu, Dec 16, 2010 at 01:50:15PM -0800, Henry B. Hotz wrote:
> No, but they are highly motivated to find a cost-effective way to
> deploy client x.509 certs, or something serving a similar purpose.

Oh, you mean that because they allow one to carry one's own computer
with them everywhere, they are therefore smartcard-like (and could even
have smartcards built in).  Yes, I agree, though I'm not sure when we'll
be there in terms of availability (for example, my teenage daughter has
a mobile, but my son is still too young to have one, but it's not the
case that he has no need for credentials or security).  My comment was
in regard to overall system security -- successful user OSes attract
malware.