Subject: Re: [TLS] TLS, PKI,

From: [email-masked]
Date: Wed, 21 Jul 2010 17:11:29 -0700 (PST)

On Thu, Jul 15, 2010 at 9:08 PM, Peter Gutmann <[email-masked]> wrote:
> Kyle Hamilton <[email-masked]> writes:
>>TLS has several modes which are unsupported by the members of this list:
>>
>>2) Mutual Authentication -- it's supported by this group in the
>>protocol, *except* that very few clients who actually have certificates
>>typically don't have the marketing acumen to show just why they might be
>>useful.
>>3) The classic "server authenticates, client doesn't" issue
>
> Just to be pedantic, what you're describing in (2) isn't mutual authentication
> but unilateral authentication in both directions, which is just as phishable
> as (3) is.  Real mutual authentication is TLS-PSK and TLS-PSK.

Real mutual authentication occurs when you don't rely on the CN or any part of the Subject field, but rather when you know exactly which key belongs to whom.  I will admit, this is really a kind of pre-sharing of keys, but if you've ever seen Lotus Domino handle its PKI you'll understand why many of the options on the table are rather ridiculous to some of us.

(Nominally, DHE allows for the establishment of a perfect-forward-secrecy channel, and then the two entities within the channel take parts of the underlying channel data and prove them to each other to prove that the holders of the keys are actually the endpoints of the connection, thus preventing non-collusive MITM.)

I'm working on a key-centric view of the cryptographic universe, not a user-centric view.  In this view, human and device identities are just attributes slapped onto and strongly bound to a given public key, verifiable by another public key.  i.e., every certificate is an X.509 Attribute Certificate, and there's no concept of an X.509 Identity Certificate.  Why should there be a difference between them?  That is a question for the PKIX list, though.  As well as the X.509 committee, but they're less open to participation than the IETF process.

> (I'm sure there's some sort of standardisation variant of "a country was never
> taxed into prosperity" lurking in there, but the few variants I can think of
> don't sound like much).

How about this one: "Keep it Simple, Stupid."  (I do not mean to imply that you -- or anyone on this list, actually -- is stupid, because you are probably some of the greatest minds that the IETF has.  In my opinion, you've made some bad decisions in the past, but there's no reason to try to drag you through the coals for them.)

I have to destroy X.509 to save the pieces worth, to me, saving.
I have to destroy TLS to save the pieces worth, to me, saving.
I have to destroy PKIX to save the pieces worth, to me, saving.

There are many problems that people have with the ideas that the IETF's working groups (and the ITU neé CCITT's working groups) have put forth.  Most notably (for me at this present moment), they provide for no means to provide Attribute Certificates from Privilege Managers (per X.509 08/2005's sections 12 and 13 -- if you don't have a copy, go to http://itu.int/ and look under ITU-T -- they generally make ITU-T recommendations free while charging for ITU-R, except in certain cases where they developed their recommendations in concert with the ISO) during the initial TLS handshake.  There's also no guidance, use-case, or even support in the underlying TLS protocol for using attribute certificates as part of renegotiations.  This means that the IETF hasn't caught onto one of the biggest, most important ideas that the ITU did: the people who are authoritative for identity are not authoritative for, nor even particularly of interest to, the authority of the owner of the computer to decide his own policy as to who does what; if he wants to delegate that policy authority to someone else I must create my own protocol to do so (or use Kerberos, even though it hasn't been updated to use asymmetric crypto or anything even more advanced than DES).

There are many failures in how this WG and the others under the IETF/IESG security banner have worked together, how these separate groups apparently don't communicate how apparently relatively minor details cause drastic, major, and unintended side effects, and how updates in the underlying protocol substrata (X.509 in particular) address issues which the IETF/IESG apparently ignore.

Every major security publication in the past decade and a half has stressed the importance of an entire system being built with security in mind.  Subsystems added afterward can introduce unknown security vulnerabilities.  (An open-source social interaction software that I inherited management of had that occur, through the addition of an additional programming language that didn't take into account *all* of the rules that the current programming language used, and thus enabled an exploit which allowed for anyone to execute commands as administrators.  (Fortunately, this happened before my inheritance of the codebase, but it's a cautionary tale to me.))

The Security area of the IETF does not have anyone ensuring that things aren't getting lost in the translation from one group's product to the other.  In the face of the attacks which have occurred, it seems that the IETF is reacting slowly -- if at all effectively -- to the failure of its own specifications to provide the level of security that is expected of them.  It took... what, 8 months to decide which of three competing specifications actually provided the best ability to be secure through renegotiation?  During which time the IETF clients, the end-users, had to put up with functionality loss as vendors patched their implementations to prevent behavior which legitimately was expected by the users and administrators to be accessible, i.e. renegotiation?

-Kyle H

---

From: Marsh Ray <[email-masked]>
Date: Thu, 22 Jul 2010 00:04:56 -0500

On 07/21/2010 07:11 PM, [email-masked] wrote:
> Real mutual authentication occurs when you don't rely on the CN or any
> part of the Subject field, but rather when you know exactly which key
> belongs to whom. I will admit, this is really a kind of pre-sharing of
> keys, but if you've ever seen Lotus Domino handle its PKI you'll
> understand why many of the options on the table are rather ridiculous to
> some of us.

Sorry I still don't get it. I may be misunderstanding something here. I 
don't know how Domino does it.

I've always understood mutual authentication to mean that the auth of 
each endpoint strongly binds it to the crypto covering the data channel. 
Unlike, for example, my bank's site where server cert auth binds one end 
of the channel but an HTML form simply tunnels a plaintext password in 
the other direction.

There may, or there may not, be problems with your chain of trust or 
other parts of your signature validation process. Isn't that a separate 
issue from whether or not a connection has mutual vs. single-ended vs. 
split-bidirectional authentication?

Each endpoint could print out the DHE parameters it has exchanged and 
sign them by hand with a pen, mail them, and have them reviewed by 
handwriting analysts. Seems to me this counts as mutual authentication 
of the connection regardless of whatever limitations there may be on the 
strength of the signature validation step (nothing's perfect after all).

> (Nominally, DHE allows for the establishment of a
> perfect-forward-secrecy channel, and then the two entities within the
> channel take parts of the underlying channel data and prove them to each
> other to prove that the holders of the keys are actually the endpoints
> of the connection, thus preventing non-collusive MITM.)

But isn't that how TLS works when doing client certificate auth?

Alternatively, the client can encrypt the premaster secret to the 
(trusted) server RSA key and verify the server decrypted it correctly 
with the Finished.verify_data. The client signs all the handshake 
messages (which include parameters) and the server can verify that as well.

Sounds like mutual auth to me.

- Marsh

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 22 Jul 2010 18:13:27 +1200

Marsh Ray <[email-masked]> writes:

>[...]

Hopefully I'm understanding your comments correctly and haven't taken them out
of context, but this still isn't proper mutual auth because first one side
authenticates and then the other side authenticates.  If I can get in between
the two steps (for example via phishing) then I've defeated the whole thing.

Peter.

---

From: Marsh Ray <[email-masked]>
Date: Thu, 22 Jul 2010 02:22:25 -0500

On 07/22/2010 01:13 AM, Peter Gutmann wrote:
> Marsh Ray<[email-masked]>  writes:
>

So phishing is, for example, if I trick you into clicking on a link in 
an email that takes you to an attack site which is similar enough to the 
site that you are deceived into authenticating with your forwardable 
credentials (username, password, OTP, etc.).

A big problem, for sure.  I know I've certainly typed a right password 
into the wrong window on plenty of occasions. I get several phishing 
emails a day on this one account and they look really really genuine.

But isn't that really a conventional failure of the authentication in 
one forward direction? I.e., you were just fooled into typing your 
password into the wrong site. It's relevant to data security and auth 
issues, but is arguably out of scope for the TLS wire protocol itself.

Although TLS mutual auth is often negotiated with multiple handshakes, 
there should not be an opening for an attacker to get in between the two 
of authentication. (When properly implemented - with fully patched 
clients - standard disclaimers apply.)

Even better, this kind of mutual auth also allows either end to prove 
the nonexistence of a MitM. Otherwise the server has no choice but to 
rely on the client to do a good job of that and thus ends up trusting, 
transitively, the union of all the sets of trusted root CAs in all the 
clients from whom he accepts secure connections! I think that's a big 
categorical improvement but I don't think I've convinced everyone yet. :-)

Since you brought up phishing it got me wondering if maybe the essence 
of your usage of the term 'mututal authentication' is that the 
endpoint's credentials are somehow inherently resistant to forwarding 
attacks?  So not a password or even a OTP, but something which 
authenticates the endpoint on this specific integrity-protected connection.

- Marsh

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 22 Jul 2010 11:00:17 -0400

-----Original Message-----
From: [email-masked]

> Real mutual authentication occurs when you don't rely on the
> CN or any part of the Subject field, but rather when you know
> exactly which key belongs to whom.  I will admit, this is really
> a kind of pre-sharing of keys, but if you've ever seen Lotus Domino
> handle its PKI you'll understand why many of the options on the
> table are rather ridiculous to some of us.
> ...
> Kyle H

Authentication strength depends on both cryptography and identity
proofing (knowing exactly which credential belongs to and is possessed
by whom).  "Real" mutual authentication does not require one to ignore
Subject names, but it does require that names be both unique and
meaningful to relying parties.  Since names are public and therefore
easily copied, uniqueness requires that relying parties trust only
credentials from reliable sources.  People generally understand that
drivers licenses can be trusted only to the extent that 1) they can't be
forged and 2) the DMV won't issue two different individuals licenses
with the same number (even if there are 100 individuals named John
Smith).  They don't seem to extend the same understanding to PKI
credentials, and will believe whatever the browser vendors tell them to
believe.  That credulity is what allowed P.T. Barnum to make a living,
but it does not prevent more careful relying parties from properly using
Identity credentials to authenticate individuals by subject name.

Dave

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 24 Jul 2010 02:45:37 +1200

Marsh Ray <[email-masked]> writes:

>So phishing is, for example, if I trick you into clicking on a link in an
>email that takes you to an attack site which is similar enough to the site
>that you are deceived into authenticating with your forwardable credentials
>(username, password, OTP, etc.).

Yeah, I realised after I posted the message that I'd taken a rather web-
browser centric view of things, but then that's where the attacks are so that
seems to be the one that needs fixing the most urgently.  Obviously if you use
appropriate precautions like having both sides keep fingerprints of the peer
cert and reject anything that doesn't match then you'll be OK.

(I guess this is yet another thing we'll need to sort out in the threat- 
modelling writeup, something that works quite well if you do it one way works 
terribly if you do it slightly differently even though the underlying crypto 
mechanism is identical).

>Since you brought up phishing it got me wondering if maybe the essence of
>your usage of the term 'mututal authentication' is that the endpoint's
>credentials are somehow inherently resistant to forwarding attacks?  So not a
>password or even a OTP, but something which authenticates the endpoint on
>this specific integrity-protected connection.

... and now we need another taxonomy for the authentication types :-).  I 
think this gets back to the channel-binding problem, it's not really a 
property specific to mutual auth but should be present in any 
(properly-designed/implemented) authentication system.  In other words the 
authentication should be cryptographically bound to the channel that it's 
authenticating.  That's why I really like the EKEs, because this property 
comes for free as part of the exchange.

Peter.