Subject: EXTERNAL-CHANNEL

From: Simon Josefsson <[email-masked]>
Date: Tue, 05 Aug 2008 20:43:50 +0200

All,

Below is the announcement of a document that describes a variant of the
EXTERNAL mechanism that can transfer a channel bindings.  It will
hopefully make client-side authentication via TLS more easily usable
from SASL.  Comments and feedback are appreciated.  Before I seek an AD
to proceed with individual publication, is this something the WG wants
to adopt?

/Simon

[email-masked] writes:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : SASL Mechanism for External Authentication using Channel Bindings: EXTERNAL-CHANNEL
> 	Author(s)       : S. Josefsson
> 	Filename        : draft-josefsson-sasl-external-channel-00.txt
> 	Pages           : 10
> 	Date            : 2008-08-05
>
> This document describes a way to perform end-user authentication in
> the Simple Authentication and Security Layer (SASL) framework which
> re-use an external security layer (such as the Transport Layer
> Security (TLS) protocol) that may have already completed end-user
> authentication.  In comparison with the existing EXTERNAL mechanism,
> this mechanism offers a way to cryptographically bind the
> authentication to the security layer via a channel binding.  The
> EXTERNAL-CHANNEL mechanism alleviates the a priori assumptions made
> by the design of the EXTERNAL mechanism.
>
> See <http://josefsson.org/external-channel/> for more information.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-josefsson-sasl-external-channel-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Chris Newman <[email-masked]>
Date: Tue, 05 Aug 2008 18:37:54 -0700

I do not understand the value of passing the channel binding within this 
context.  I must be missing something.  Let me explain my thinking so you 
can spot my error.

My understanding of channel bindings is they are used to tie the 
authentication to the security layer to detect man-in-the-middle attacks 
(where the MITM decrypts & re-encrypts all traffic between client & 
server).  Passing a channel binding in the clear without an 
authentication-related hash covering it doesn't do anything as a MITM can 
simply modify the channel binding.

If the authentication and security layer are done at the same level of the 
protocol stack and that level is implemented correctly, then channel 
bindings are implicit at that layer of the stack and provide no value at 
higher levels of the stack.

Now a case where something akin to channel bindings would be useful is if 
the security layer and authentication were at separate layers of the 
protocol stack.  One scenario I can think of for this is if IPsec is used 
for the security layer and TLS_RSA_WITH_NULL_NULL is used for client cert 
authentication at the TLS layer.  Then a SASL mechanism which did an HMAC 
of the client cert authentication session key with the IPsec channel 
bindings would be a value add (pardon me if I didn't use quite the right 
terminology here -- I'm trying to explain intent not details).

		- Chris

---

From: Philip Guenther <[email-masked]>
Date: Wed, 6 Aug 2008 11:58:14 -0700

On Tue, 5 Aug 2008, Chris Newman wrote:
> (where the MITM decrypts & re-encrypts all traffic between client & server).
> Passing a channel binding in the clear without an authentication-related hash
> covering it doesn't do anything as a MITM can simply modify the channel
> binding.

I agree: the channel binding data must be integrity protected by the layer 
passing it for there to be an actual binding to the lower layer that's 
immune to MitM attack.

To acheive the stated goal of indicating which previous-negotiated-at-a- 
lower-layer client credentials should be used for the SASL authentication 
credentials, it appears to me that EXTERNAL-CHANNEL would only need to 
pass the channel binding unique prefix.

Or is it possible for there to be multiple applicable bindings with the 
same prefix?  IPsec in IPsec?  Is the unique prefix not actually sure to 
be unique for a full channel?

Philip Guenther

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 06 Aug 2008 21:42:47 +0200

Thanks for quick feedback.

> passing it for there to be an actual binding to the lower layer that's 

Mea culpa.  However, the MITM problem wasn't my focus.  My use case was
to make EXTERNAL more usable for re-using TLS client credentials inside
SASL; right now EXTERNAL assumes out-of-band negotiation between
administrator and user.  If EXTERNAL would pass the name of the external
channel that problem with EXTERNAL goes away, and I believe it would be
sufficient to get TLS-client-auth-propagated-to-SASL more interoperable.
I'll try to make the use-case more clear in future versions of the
document.

Perhaps channel bindings is the wrong way to achieve what I want?
Instead there could be a EXTERNAL-TLS mechanism that explicitly
reference the outer TLS channel, and protocol-wise is identical to
EXTERNAL.

The channel bindings mechanism seemed to me like a nice way to abstract
out which external security channel is intended, which would allow the
EXTERNAL-CHANNEL to be applicable to IPSec as well.  My use case would
be solved by a EXTERNAL-TLS though, and I'm not sure that many users are
interested in re-using IPSec credentials in SASL?

> pass the channel binding unique prefix.

Yes, I think so.  However, maybe there is some advantage in sending the
channel bindings as well?  I'm not sure, and would appreciate more
thinking on this.

> be unique for a full channel?

I can't think of a situation like that right now, but maybe they exist.

However, what if EXTERNAL-CHANNEL doesn't send the channel bindings in
clear, but uses it as a HMAC key on the authorization identity?
Assuming channel bindings aren't predictable and doesn't repeat, that
would provide some additional assurance, wouldn't it?  In other words,
the EXTERNAL-CHANNEL token would be:

"tls-unique " HMAC-SHA1(channel-bindings, authz-id) " " authz-id

I'm not convinced this brings significant benefits over a EXTERNAL-TLS
mechanism though, but I'd be interested to discuss the idea.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 6 Aug 2008 16:36:46 -0500

> > by the design of the EXTERNAL mechanism.

There is a contradiction here.

We have a lower-layer channel providing both, authentication and
transport protection.  Any binding between the two had better be done at
that layer, and it had better be done!

No mechanism like EXTERNAL can do any sort of cryptographic binding of
authentication and secure channel because EXTERNAL-like mechanisms have
no cryptographic key material available that is suitable for that task
(considering too that any such binding has to be difficult for MITMs to
defeat).

Nico
--

---

From: Chris Newman <[email-masked]>
Date: Wed, 06 Aug 2008 20:36:48 -0700

IPsec is presently useless to applications.  I don't see the authentication 
it provides ever being useful to applications.  However, the security layer 
it provides could be useful if there was a standardized API for an 
application to get an IPsec channel binding and a cipher suite identifier 
(or equivalent).

While I don't see the utility of making the channel for which EXTERNAL 
applies explicit, I don't object to that either.  However, EXTERNAL has 
been widely used for TLS client certificates.  So if we want to change the 
way EXTERNAL is used I'd prefer to treat EXTERNAL as 
EXTERNAL+TLS-CLIENT-CERT (just like SASL "GSSAPI" is Kerberos 5) and create 
new variants of EXTERNAL for other layers when such layers become 
deployable.  I could see EXTERNAL-PPP being possibly viable, for example.

		- Chris

--On August 6, 2008 21:42:47 +0200 Simon Josefsson <[email-masked]> 
wrote:

>>> authentication-related hash covering it doesn't do anything as a MITM
>>> can simply modify the channel binding.
>>
>> I agree: the channel binding data must be integrity protected by the
>> layer  passing it for there to be an actual binding to the lower layer
>> that's  immune to MitM attack.
>
>> lower-layer client credentials should be used for the SASL
>> authentication  credentials, it appears to me that EXTERNAL-CHANNEL
>> would only need to  pass the channel binding unique prefix.
>

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 6 Aug 2008 23:20:11 -0500

> There is a contradiction here.

Perhaps I misunderstood.  EXTERNAL-CHANNEL seems to be about telling the
server which channel the server should extract user identification
material from for the server's authorization tasks.

Of course, that presumes there can be more than one secure channel in
the stack between the client and the server.  And eventually that will
be possible: an IPsec channel and a TLS channel.  Someday hopefully even
likely.

Therefore EXTERNAL-CHANNEL could indeed be useful.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 07 Aug 2008 14:56:51 +0200

Chris Newman <[email-masked]> writes:

> applies explicit, I don't object to that either.  However, EXTERNAL
> has been widely used for TLS client certificates.

My perception is different: few if any MUAs I've used that supports TLS
client certificates offer the EXTERNAL SASL mechanism for
authentication.  The EXTERNAL specification says that the channel to use
is to be negotiated out-of-band, which makes interoperable use of
EXTERNAL difficult.

I agree that EXTERNAL sometimes is used for TLS client certificates, but
in my experience that only happens in small environments where the
administrator communicate this knowledge via some special channel.

> So if we want to change the way EXTERNAL is used I'd prefer to treat
> EXTERNAL as EXTERNAL+TLS-CLIENT-CERT (just like SASL "GSSAPI" is
> Kerberos 5) and create new variants of EXTERNAL for other layers when
> such layers become deployable.  I could see EXTERNAL-PPP being
> possibly viable, for example.

This would mean revising the EXTERNAL specification to say that it means
TLS client-side authentication.  (Note, TLS can use non-certificate
mechanisms such as OpenPGP and SRP too, so restricting it to X.509 would
be sub-optimal.)  That would work for me.

/Simon

---

From: Chris Newman <[email-masked]>
Date: Thu, 07 Aug 2008 17:12:41 -0700

> administrator communicate this knowledge via some special channel.

RFC 2595 compliant clients (both POP and IMAP) will use EXTERNAL with 
STARTTLS and client certificates.  RFC 3501 IMAP clients also have to use 
EXTERNAL with STARTTLS.  These specifications are not ambiguous on the 
topic.

Both pops and imaps are non-standard but deployed.  All imaps clients 
expect the server to do "* PREAUTH", which is fine (it just means imaps 
doesn't support admin proxy).  The pops implementations can not 
interoperate because that's an under-specified protocol.  It would be good 
if someone fixed the latter.

		- Chris

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 08 Aug 2008 11:22:34 +0200

Chris Newman <[email-masked]> writes:

> --On August 7, 2008 14:56:51 +0200 Simon Josefsson
> <[email-masked]> wrote:
> STARTTLS and client certificates.  RFC 3501 IMAP clients also have to
> use EXTERNAL with STARTTLS.  These specifications are not ambiguous on
> the topic.

The EXTERNAL specification is not clear that the TLS channel is the
intended channel, though, quoting RFC 4422:

   The EXTERNAL mechanism allows a client to request the server to use
   credentials established by means external to the mechanism to
   authenticate the client.  The external means may be, for instance, IP
   Security [RFC4301] or TLS [RFC4346] services.  In absence of some a
   priori agreement between the client and the server, the client cannot
   make any assumption as to what external means the server has used to
   obtain the client's credentials, nor make an assumption as to the
   form of credentials.  For example, the client cannot assume that the
   server will use the credentials the client has established via TLS.

RFC 2595 and RFC 3501 says that implementations MAY use EXTERNAL with
TLS client certificates.  That is correct, but it does not mean that
EXTERNAL needs to use the TLS channel's credentials.  In my perception,
this ambiguity is the primary reason why EXTERNAL doesn't work well for
TLS client certificate re-use.

I agree that it would be simpler to revise the EXTERNAL specification to
say that it is intended to re-use TLS credentials, similar to how we
have revised GSSAPI to mean Kerberos V5.  I'm not convinced it is
possible to revise EXTERNAL in this way though, maybe someone is using
EXTERNAL to refer to an external SSH connection or similar?  I would
prefer to revise EXTERNAL in this way compared to invent a new mechanism
though.  Is this a way forward that others find acceptable?

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 08 Aug 2008 12:12:19 +0100

Simon Josefsson wrote:

>EXTERNAL needs to use the TLS channel's credentials.
>
Indeed. The client has no way of knowing for sure if TLS information is 
going to be used by the server end.

>In my perception,
>EXTERNAL to refer to an external SSH connection or similar?
>
OpenLDAP uses EXTERNAL when running over a Unix domain socket with no 
TLS. It will use identity from the OS in such cases.

>I would prefer to revise EXTERNAL in this way compared to invent a new mechanism
IMHO, SASL EXTERNAL as written is underspecified. I would prefer to 
write a separate mechanism which is unambiguous.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 08 Aug 2008 14:41:05 +0200

Alexey Melnikov <[email-masked]> writes:

> Indeed. The client has no way of knowing for sure if TLS information
> is going to be used by the server end.

Furthermore, the server has no way of knowing whether the client
intended that TLS or something else should be used.

> TLS. It will use identity from the OS in such cases.

If so, re-vising EXTERNAL to mean TLS credentials appears to not work
well.

> write a separate mechanism which is unambiguous.

The question is whether the mechanism can/should be TLS-specific, or if
there is any point in re-using the channel binding mechanism which I did
in an attempt to make it more generic.

I initially thought the channel binding approach would be more generic
and make it more easy to re-use for various different channels, but I'm
beginning to doubt it is the best approach.  It may be adding too much
complexity for too little gain.

A mechanism EXTERNAL-TLS would allow the specification to be able to say
more useful things that apply only for TLS.  Mechanism such as
EXTERNAL-IPSEC or EXTERNAL-PPP or whatever could be specified if there
is interest.

/Simon

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 8 Aug 2008 15:59:16 +0200

Simon Josefsson writes:
>>> [RFC 2595 and RFC 3501 do] not mean that EXTERNAL needs to use the
>>> TLS channel's credentials.
>>

Not so.  SASL by itself cannot know that.  But the client or its user
can know if if it knows how the server picks the channel.  And that the
connection only has one reasonable channel for the server to pick.

> intended that TLS or something else should be used.

Stated that strongly, this is a bit of a strawman.  Unless the server
is set up for specific clients, it can't know what clients and their
users intend in any case.  Whatever a client is doing, it might be buggy
or the user might be clueless.  Servers just have to do what the clients
tell them, after catching what errors they can and bother to catch.

Anyway, it's not that EXTERNAL is perfect, I just think this discussion
is stating its problems somewhat misleadingly and too strongly.
Also I have no idea how much of a real-life problem EXTERNAL-CHANNEL
solves, and how much of it is theoretical?

As I see it, in this respect EXTERNAL-CHANNEL can be useful to:
- pick the right channel of several available alternatives,
- stop servers from being "too clever" - e.g. ensure authentication
  fails rather than pick a channel the user or client author didn't
  even know about,
- catch user/client errors.

And of course there is the encoded channel bindings (the b64-cb-data),
which I'll understand as soon as I've read up on channel bindings:-)

-- 
Hallvard

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 08 Aug 2008 16:20:53 +0200

Hallvard B Furuseth <[email-masked]> writes:

> users intend in any case.

That is the flaw I try to correct with EXTERNAL-CHANNEL.  With
EXTERNAL-CHANNEL, the server can know what the client intends.

> solves, and how much of it is theoretical?

I'd like to find out that as well. ;)

In my experience, EXTERNAL is under-utilized in the real-world for TLS
client credentials.  People appear to avoid EXTERNAL because its
specification says that it requires some out-of-band negotiation.

Whether this is problem with the wording of the EXTERNAL specification,
or a real technical problem in that it only transfer an authorization
identity, that is something I'd like to find out.

> - catch user/client errors.

The latter two are the use cases I believe are most realistic.

> which I'll understand as soon as I've read up on channel bindings:-)

Possibly it is of no use, and only the channel binding name is needed.
By sending a HMAC blob using the channel bindings as key you may get
some other properties, but I'm less certain there is any significant
motivation to do this.  I'm not even sure we need to depend on the
channel binding vehicle.  The EXTERNAL-CHANNEL mechanism could be
renamed to EXTERNAL-TLS and be made specific to refer to the outer TLS
channel inside the application protocol, and the client credentials
negotiated in that TLS session.

/Simon

---

From: Chris Newman <[email-masked]>
Date: Fri, 08 Aug 2008 14:44:41 -0700

EXTERNAL as specified is 100% fine as long as mutual authentication is not 
required.  If the client sees EXTERNAL, it just uses it and everything 
works.

But if mutual authentication is required, then EXTERNAL is problematic.  A 
client has to verify that the mutual authentication has occurred at the 
correct layer prior to using EXTERNAL and passing possibly sensitive data 
to the server.

So the key specification difference between "EXTERNAL" and "EXTERNAL-TLS" 
is that a client MUST NOT negotiate EXTERNAL-TLS unless client credentials 
were passed at the TLS layer and the server cert was successfully verified 
(the spec should include an example for this case).  And the server MUST 
NOT advertise EXTERNAL-TLS unless TLS client credentials were successfully 
negotiated at the TLS layer.

So I would support creation of an EXTERNAL-TLS mechanism.  Although it 
would be identical to EXTERNAL on-the-wire, I understand the semantic 
difference is valuable.  For transition purposes, I'd say a server that 
advertises EXTERNAL-TLS SHOULD also advertise EXTERNAL.

I don't support creation of a replacement for EXTERNAL that has a 
sub-negotiation to identify which external context passed client 
credentials -- I think that's a case where sub-negotiations should be 
avoided.

		- Chris

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 10 Aug 2008 12:51:58 +0200

Chris Newman <[email-masked]> writes:

> So the key specification difference between "EXTERNAL" and
> "EXTERNAL-TLS" is that a client MUST NOT negotiate EXTERNAL-TLS unless
> client credentials were passed at the TLS layer and the server cert
> was successfully verified (the spec should include an example for this
> case).  And the server MUST NOT advertise EXTERNAL-TLS unless TLS
> client credentials were successfully negotiated at the TLS layer.

This matches my intentions.

> difference is valuable.  For transition purposes, I'd say a server
> that advertises EXTERNAL-TLS SHOULD also advertise EXTERNAL.

Works fine.

> credentials -- I think that's a case where sub-negotiations should be

I'm starting to agree with this.  The negotiation can be done using the
SASL mechanism name (EXTERNAL-TLS, EXTERNAL-IPSEC, etc) instead of
inside the mechanism itself.  This lets the specification discuss things
that are TLS-specific without violating the abstraction.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 10 Aug 2008 22:09:30 -0500

> that are TLS-specific without violating the abstraction.

+1

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 11 Aug 2008 08:15:22 +0200

Chris Newman writes:
> difference is valuable.

Yes...

> For transition purposes, I'd say a server

_During_ transition from EXTERNAL, yes.  Afterwards, if it is
a real problem that users use EXTERNAL and get the wrong channel,
the admin may want to turn off that option.

However if it isn't a problem, one might want to stay with EXTERNAL.
When it works, it's simpler.  And if a client gets yet another user
option to tweak, that doesn't necessarily mean clients users will
tweak it right.  They might e.g. copy some config which did get it
right, and then modify just what kind of channel he actually gets
without also replacing EXTERNAL-TLS with EXTERNAL-something-else.

> credentials -- I think that's a case where sub-negotiations should be

Note that a separate channel field can be useful because the client
can pass a value which SASL does not implement.  E.g. a protocol
implementation like OpenLDAP which can use Unix domain sockets' peer ID:
That way it does not depend on the SASL implementation to implement an
EXTERNAL-UNIX-SOCKET mechanism.  Instead, the LDAP client could pass
"UNIX-SOCKET" through SASL/EXTERNAL-CHANNEL which would pass it on to
the LDAP server.

So - of the two real-life use cases I've encountered, EXTERNAL-TLS
covers half of them.  How to implement the other (EXTERNAL-UNIX-SOCKET)
is OS-dependent.  Might be unsuitable for RFCification, since it
may need to keep up with whatever various OSes come up with.

On the third hand, it does looks easier to deal with EXTERNAL-TLS than
EXTERNAL-CHANNEL("TLS").  Maybe there could be extensible mechanism
names: Reserve all mechanisms named EXTERNAL-X-* for the protocol which
uses SASL.  Include a hook in the SASL library on which the protocol
implementation can hang its own EXTERNAL-X-UNIX-SOCKET implementation.

-- 
Hallvard

---

From: Sam Hartman <[email-masked]>
Date: Mon, 11 Aug 2008 21:30:19 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:
    >> And of course there is the encoded channel bindings (the
    >> b64-cb-data), which I'll understand as soon as I've read up on
    >> channel bindings:-)

    Simon> Possibly it is of no use, and only the channel binding name
    Simon> is needed.  By sending a HMAC blob using the channel
    Simon> bindings as key you may get some other properties, but I'm
    Simon> less certain there is any significant motivation to do
    Simon> this.  I'm not even sure we need to depend on the channel
    Simon> binding vehicle.  The EXTERNAL-CHANNEL mechanism could be
    Simon> renamed to EXTERNAL-TLS and be made specific to refer to
    Simon> the outer TLS channel inside the application protocol, and
    Simon> the client credentials negotiated in that TLS session.
If you send channel bindings, the point would presumably be to
distinguish between two channels of the same type that both exist.  I
think that might be useful.  I don't think you can get any security
properties out of channel bindings without also doing an
authentication at the layer that is exchanging channel bindings.

However channel bindings can be a good name for a channel.  Note that
in some cases the name is not unique.  Also, in some cases the name
must be kept confidential.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 12 Aug 2008 12:39:13 +0200

> must be kept confidential.

Further, there are potential for confusion because of the
non-uniqueness: for example, there are channel bindings 'tls-unique' and
'tls-unique-for-telnet'.  Both applies to a TLS channel, but one is
protocol-agnostic and one is intended for use in telnet.  If telnet used
TLS and SASL, both tls-unique and tls-unique-for-telnet could be
accepted by the server to mean "the outer TLS channel".  But maintaining
this mapping appears complex and error prone.  Especially considering
the potential for future channel bindings, such as a
'tls-unique-using-prf' that use the TLS PRF instead of the TLS Finished
messages.

When is it useful to be able to identify one out of two channels of the
same type?  IPSEC may be the use-case, although I wonder whether the
client credentials used for IPSEC are ever useful for SASL applications.

At this point, I'm leaning towards renaming the mechanism to
EXTERNAL-CLIENT-TLS and specify that it refers to the outer TLS channel
as negotiated by the application protocol using a STARTTLS mechanism,
and that it is only applicable when the outer TLS channel has negotiated
client authentication (otherwise EXTERNAL is more appropriate).  That
appears simpler to specify and implement than to re-use the channel
bindings mechanism.  To sway me, I'd appreciate an example of some
useful use-case that the EXTERNAL-CLIENT-TLS approach would fail to
address but that a EXTERNAL-CHANNEL-like approach would address.

Hm.  Maybe I just realized one such example: IMAP+STARTTLS over a
TLS-VPN?  I'm not sure it is a useful example though.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Aug 2008 09:21:58 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> Sam Hartman <[email-masked]> writes:
    Simon> bindings, such as a 'tls-unique-using-prf' that use the TLS
    Simon> PRF instead of the TLS Finished messages.

Simon, I've been meaning to write this up for the channel binding
list, but since you bring it up I'll briefly describe.  A group of us
met in Dublin over lunch to discuss Kerberos FAST.  As we ran into
problems, we started comparing to other protocols.  It ended up that
one of the things we looked at was TLS, and one of the complicated
things we looked at was a channel binding using the TLS PRF.

It turns out that fails to meet the definition of channel bindings for
most TLS ciphers.  RFC 5056 requires that it be difficult for an
attacker to manipulate a connection such that two channels have the
same unique channel bindings.

As I recall, the TLS master secret (which keys the PRF) is based only
on the pre-master secret, the client random value and the server
random value.

Alice connects to a MITM.  She's going to use TLS with one of the
traditional RSA ciphers.  She doesn't check certificates because she's
relying on channel binding and some later authentication.  She really
wanted to be connecting to Bob rather than the MITM.  

In her first message she sends her client value.  The MITM connects to
Bob, sends the same client random value that Alice sent and receives
Bob's random value in the server hello.  The MITM sends a server hello
back to Alice using the same random value.  The MITM sends along a
certificate message for the certificate that the MITM knows the private key to.  

Alice encrypts the pre-master secret in the MITM's key and sends it
along.  The MITM decrypt the pre-master secret, encrypts it in Bob's
key and sends it along.  TLS establishment proceeds as normal.

Note that the channel has the same name using a unique-prf binding but
not using a unique-finish binding.  I was very surprised when I
discovered this.  I had previously believed that tls-unique and
tls-unique-prf had the same security properties.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 12 Aug 2008 16:44:03 +0200

> tls-unique-prf had the same security properties.  

Good writeup.

This was discussed before, although without the complete writeup of the
attack.  As a response I proposed a variation that combines what I
believe are the best properties of both TLS-PRF and the TLS Finished
approach in.  See earlier discussion in the SASL WG under the "TLS
channel bindings" subject:

http://thread.gmane.org/gmane.ietf.sasl/2329/focus=2330

I've updated draft-josefsson-sasl-tls-cb to implement these ideas, using
this construct:

    TLS_channel_bindings =
       PRF(SecurityParameters.master_secret,
           "channel binding",
           MD5(handshake_messages) + SHA-1(handshake_messages)) [0..31]

Thanks,
/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Aug 2008 10:43:28 -0500

Good catch.  tls-unique-using-prf is ONLY OK IF Diffie-Hellman key
agreement is used.  If RSA key transport is used then that channel
binding is subject to trivial MITM attacks.

A TLS implementation, therefore, SHOULD NOT export the
tls-unique-using-prf channel binding unless a suitable key exchange
protocol was used.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Aug 2008 11:53:27 -0500

> tls-unique-using-prf channel binding unless a suitable key exchange

Given that TLS unique CB is the only available CB type when using anon
DH suites I think that we can't merely declare TLS unique CB toxic.

Which CB to use, which CB is available, necessarily depends on knowledge
of what TLS cipher suite (or, more specifically, what key exchange
protocol) was used for the given channel.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Aug 2008 13:12:27 -0500

I was confused there for a second.  We don't have any registrations for
TLS channel bindings with this problem.  The existing unique TLS CB
types use TLS Finished messages and are not susceptible to this attack.