Subject: [Emu] Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Jan 2012 15:33:35 -0500

I'd like to thank Margaret Wasserman for coming up with a series of
proposed attacks that lead to the following comments.

In the context of implementing channel binding and a system that takes
advantage of it, I've been focusing on MITM attacks. I'd like to give a
example of the sorts of attacks that are worrying me.  I thought these
were supposed to be solved by crypto binding, but I no longer think that
existing implementation of crypto binding are strong enough.

First, in a channel binding world, some NASes are significantly more
trusted than others. In my ABFAB world that's especially true.

We have clients using EAP-TTLS as a tunnel method with some inner
password method (MSCHAPv2, some PAKE method, whatever. We'll assume that
it generates a key.) We're adding support the EAP-TTLS for channel
binding. That's realistic and is consistent with the approach we've been
trying to standardize. We want the tunnel methods to support channel
binding and perform the channel binding exchange there so we don't have
to modify all EAP methods. NEA needs something similar for data they
plan to transport over EAP.

Consider a compromised print server. It would like to impersonate
someone's bank. (In an ABFAb world, EAP is used for things other than
network access. I can construct a network access version of this attack
if you'd like too.)

The print server  impersonates the bank enough to get the client to
connect to it. It then starts authentication. We're using ABFAB to
authenticate the client to the server and the server to the client. The
user indicates their home realm in an identity response. 
The print server, like the bank is a valid participant in the AAA
fabric. So it sends an access-request to the home EAP server and gets a
method request.

In this attack the home EAP server uses TTLS. However the print server
wants to MITM the TTLS tunnel.  So, while the print server sends the
first TTLS packet towards the client, it sends a EAP NACK towards the
home EAP server requesting the appropriate inner password method.

So, we start to establish a EAP tunnel between the client and the print
server and an inner method between the client and the home EAP server.
Things will fail if the client validates the tunnel certificate.

However if the client goes forward,  then the authentication will
succeed at the inner method level.

Then, assuming we're using TTLSv1, the client will do crypto
binding. Intuitively you'd kind of think that crypto binding would help
here; I'll discuss in a bit whether it's supposed to. It's quite clear
it doesn't though. Crypto binding uses the MSK of the inner method for
the binding. However, as part of the access-accept, the home EAP server
discloses the MSK to the print server.  So, the print server has the
material it needs to perform crypto binding and the generate the final
MSK.

Then the client performs channel binding to confirm that it's talking to
the bank. The print server  is happy to tell the client that the print
server is in fact a bank, so the attack succeeds.

For the most part, this is a classic compound authentication attack. If
the inner method had not been offered outside the tunnel, the attack
generally would not be possible. If different credentials are used, when
the method is used inside a tunnel vs outside the attack is not
possible. As stated earlier, this particular instance of the attack  is
not possible if the client verifies the TTLS certificate. There are also
ABFAB-specific mitigations that do not generally apply to network
access.

However, the client does have a secure connection to the home EAP
server. Intuitively, we do not actually need to require checking the
certificate to provide security against this. If the credential is weak
and can be attacked with a passive dictionary attack, then other attacks
may be possible if the client does not check the certificate. However if
we're using a good PAKE method as an inner method and only using the
tunnel for carrying tunneled attributes such as channel binding, there's
absolutely no reason the security of the system needs to depend on that
certificate check. Whether we like it or not, there are a lot of clients
out there that have weak validation of certificates for EAP tunnel
methods.

Intuitively, crypto binding is supposed to solve MITM attacks with
compound authentication. Certainly as I've discussed this issue with
some folks in the EAP community they've started out thinking that crypto
binding was supposed to solve this sort of thing.
Let's go back to RFC 3748  and see what we actually specified for crypto
binding though:

   Cryptographic binding
         The demonstration of the EAP peer to the EAP server that a single
	       entity has acted as the EAP peer for all methods executed within a
	             tunnel method.  Binding MAY also imply that the EAP server
		           demonstrates to the peer that a single entity has acted as the EAP
			         server for all methods executed within a tunnel method.  If
				       executed correctly, binding serves to mitigate man-in-the-middle
				             vulnerabilities.

So, from that definition it's clear that cryptographic binding doesn't
always provide a solution. In particular, this attack is concerned with
situations where multiple servers are involved (and should not be)
rather than situations where multiple clients are involved. 
Proving to the client only one server is involved is an optional
facility in cryptographic binding.
Still, it looks that even in the time of RFC 3748 like people thought
that there are cases where we'd want to prove to a client that there was
no MITM server.
It seems like  if that optional facility is provided  then we ought to
avoid this attack.

It's unfortunate that RFC 3748 doesn't name the optional facility where
cryptographic binding provides defense against MITM servers. I'll call
that mutual cryptographic binding.

I'd like to step away from EAP-TTLS and focus on
draft-ietf-emu-eap-tunnel-method. If we're going to fix something or
document security considerations, let's do it for things we're
standardizing first.

I'm left with a number of questions:

1) Is mutual cryptographic binding important?

2) What do the tunnel method requirements say about this?

3) Does the tunnel method document intend to provide mutual
cryptographic binding? Does it succeed? Should it?

4) What protocol changes should we make?

5) What security considerations should we document?

Sot

       Discussion: 1) Is mutual cryptographic binding important?

So, we're starting to do a lot of new things with tunnels and EAP. We're
exchanging channel bindings. We're exchanging NEA information. And we're
defining extensible tunnel methods where it seems likely that people
will propose adding new facilities.
In today's EAP for network access situations, the client doesn't
actually get much out of the authentication. A lot of the value of EAP
is proving the identity of the peer to the EAP server and indirectly the
NAS.
However, channel bindings, some NEA deployments and other potential uses
of EAP increase the importance of the exchange to clients.
That is, there's a lot more value in a NAS attacking a client in the
future than there is today.

Channel bindings are of particular note in this regard because they
allow clients to distinguish NASes.

At the same time we're  talking about standardizing anonymous
provisioning (Dan's comments) and otherwise doing things that  create
cases where we don't expect clients to validate tunnel
certificates. We're also doing things that makes certificate validation
easier in some cases. But even if we want to ignore deployments where
people simply don't validate certificates today, that doesn't completely
make this issue go away. This is consistent with use case 3.9 in the
tunnel method requirements draft.

Let's also think for a moment about peer-side certificate
validation. It's not actually enough to simply validate that a
certificate is is traced back to a trust anchor. It's actually critical
to validate the name of the certificate (or validate a fingerprint). I
think it's quite common for peers to be deployed in a configuration that
does not check that the presented certificate is linked to a single
known and trusted EAP server. So, I think clients that do not validate
certificates are quite real.

For these reasons, I think this issue will be of increasing importance
in the future.

 Discussion: 2) What do the tunnel method requirements say about this?

If you take a look at the bottom of page 6 in tunnel method
requirements, there is a discussion of MITM attacks. From that
discussion, it sounds like cryptographic binding is believed to be an
adequate defense against tunnel MITM attacks for sufficiently strong
inner methods. The actual requirement for cryptographic binding is
defined in section 4.6.3. That section goes into a lot of detail about
how to implement cryptographic binding, but doesn't address the question
of who is expected to be able to verify the cryptographic binding or
what keys are involved. However reading that section again it sounds
like the EAP tunnel method is intended to support cryptographic binding
adequate to provide defense against tunnel MITM attacks.

It's still kind of ambiguous what was intended.  Certainly, section 3.9
implies that the tunnel method needs to be secure when for example the
tunnel method is used to add channel binding to an otherwise secure
inner EAP method even when server certificates are not validated.

Discussion: 3) Does the tunnel method document intend to provide mutual
cryptographic binding? Does it succeed? Should it?

Take a look at section 4.9.2 and 5.3 in draft-ietf-emu-eap-tunnel-method
for the cryptographic binding in the current draft.
That section seems to be trying to authenticate the server to the
client. There is a copy of the server's compound MAC that is sent to the
client.
Unfortunately, though, the MAC is protected by a combination of MSKs and
the phase 1 keying information according to section 5.3.
So, the tunnel method is vulnerable to this class of attack.

do we want to fix it?  I think so.  There's one catch. It gets in the
way of terminating the tunnel at a different endpoint than the inner EAP
method.  Supporting that does not seem to be a requirement. I cannot
find any use cases in section 3 of the tunnel method requirements
document that requires support for termination.  Section 6.4 of the
tunnel method requirements discusses the security problems that can
result with such termination and hints but does not require that clients
be able to determine whether termination at different endpoints  has
happened.

So, I think tunnel termination at different endpoints than the inner
method is at best second-class.  I'd prefer to start from the assumption
that it is not requirement.  If the WG gets a consensus that it is a
requirement, then I'd prefer to adopt a solution to these MITM issues
that prohibits termination at different endpoints by default (in favor
of stronger security) but that allows a permissive client to accept no
cryptographic binding of servers in appropriately limited circumstances.
I'll note that a lot of use cases such as channel binding where the
tunnel method is considered without certificate verification are
entirely inappropriate if the inner method is terminated at a different
place than the tunnel method.

Discussion: 4) technical changes

The easiest fix seems to be to use the EMSK rather than the MSK to
produce the key for the compound MAC. We may want to consider using the
EMSK to enfluence both the MSK and EMSK for the overall EAP tunnel
method.  I believe that if the key is not known to the attacker the
construction in section 4.9.2 and 5.3 provides mutual cryptographic
binding. I believe that the EMSK of the inner method should not be known
to the attacker because the EMSK is not disclosed beyond the EAP server.

Discussion: 5) Security Considerations

I think we should actually clearly document the difference between
mutual cryptographic binding and cryptographic binding.
I think we should discuss cases where the mutual cryptographic binding
is important--namely cases where the client trusts the tunnel especially
when it does not otherwise validate the tunnel.

If there are cases where we provide cryptographic binding but not mutual
cryptographic binding, we should carefully discuss the risks.

                            Acknowledgements

I'd like to thank Margaret Wasserman and Jari Arkko for help in
reviewing my analysis. I'd especially like to thank Margaret for finding
several attack situations in this space.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Thu, 12 Jan 2012 11:47:22 +0100

Sam Hartman wrote:
> the binding.

  RFC 5281 (TTLS) says:

   Keying material for the subsequent data connection between client and
   access point (Master Session Key / Extended Master Session Key
   (MSK/EMSK); see Section 8) is generated based on secret information
   developed during the TLS handshake between client and TTLS server.

> However, as part of the access-accept, the home EAP server

  I don't see how.  The print server MUST use the MSK from it's TLS
session for crypto bindings.  The MSK (if any) received from the home
server isn't used for anything.

  On top of that, the client will verify that any random data
(challenges, etc.) are generated from the MSK derived from the TLS session:

   When a challenge-based authentication mechanism is used, both client
   and TTLS server use the pseudo-random function to generate as many
   octets as are required for the challenge, using the constant string
   "ttls challenge", based on the master secret and random values
   established during the handshake:

  If the inner EAP session is forwarded to a home server, it will
generate random challenges for methods like CHAP, MS-CHAP, EAP-MD5 and
EAP-MSCHAPv1.  The client will check the challenges against the data it
derives from the PRF.  The data will be different, and the client MUST
discard it as being invalid.

> ... So, I think clients that do not validate

  Yes.  This also includes clients which validate the certificate based
on user input.  The users are known to just "click through" any
certificate warnings.

> ... However reading that section again it sounds

  Yes.

> So, the tunnel method is vulnerable to this class of attack.

  I disagree, due to the discussion above.

  This attack is possible only if the keys are derived from the inner
tunnel data, instead of the outer TLS session.

  Both TTLS and the expired PEAP draft require the MSK to be derived
from the outer TLS session.  So I find it hard to see how this attack
applies.

> that it is not requirement.

  I agree.

> place than the tunnel method.

  I'll have a separate response on this topic.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 12 Jan 2012 12:21:34 +0100

> fabric. So it sends an access-request to the home EAP server and gets a

  As a variant to this attack, if the print server send *NON* EAP
requests to the home server, then this will work.  The print server will
MITM the connection, terminate the TLS tunnel, and do cryptographic
bindings.  The inner authentication will be handled by the home server,
and the client will be unaware.

  The simplest use-case is PAP.  There is no challenge, so crypto
bindings don't apply,

  The next use-case is CHAP.  Crypto bindings apply, but most AAA
servers will accept *both* the challenge and response in the same
request.  This means that the MITM server can calculate the challenge
using crypto bindings, and send it to the home server.  The home server
will then authenticate the user.

  MS-CHAPv1 has the same issue as CHAP.  MS-CHAPv2 does not, but it can
be trivially converted to MS-CHAPv1.  Most AAA servers will accept both
v1 and v2.

  EAP-MD5 and EAP-MSCHAP don't have this issue.  But they can be
trivially converted to CHAP / MS-CHAPv1.  So they have the same issues
as CHAP / MS-CHAPv1.

  So there are many cases where the cryptographic bindings offer *no*
guarantee that the server which terminates the TLS tunnel is the same
one which authenticates the end user.  MITM attacks are not only
possible, they are widely deployed.

  MITM attacks have real-world use cases, where a legacy AAA server is
"upgraded" to support EAP, by placing an EAP-aware server in front of
it, and applying the protocol conversion outlined above.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 12 Jan 2012 12:36:31 +0100

This is the third message in my response to Sam's long post.  This
topic: channel bindings.

> place than the tunnel method.

  How do we want to solve that problem?

  The current crypto bindings tie the inner tunnel authentication to the
TLS MSK.  We can't use the TLS MSK to sign the channel binding data, as
a MITM server could just sign it, and never send it to the home server.

  The only solution I can think of is to tie the channel binding data to
the authentication credentials.  This could be done by using an HMAC
over the channel binding data, using a key derived from the users
authentication credentials.

  The client could then sign the channel binding data using this HMAC.
The home server could verify it, and sign its response using the same
method.  The client would then verify the response.  This method still
allows MITM attacks, but ensures that the home server has seen the
channel binding data.

  We could also key the HMAC using a key derived from *both* the TLS MSK
and from the users authentication credentials.  This would ensure that
MITM attacks are impossible.

  I'm interested in seeing a wider discussion of these topics.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Jan 2012 10:33:31 -0500

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan> Sam Hartman wrote:
    >> binding. Intuitively you'd kind of think that crypto binding
    >> would help here; I'll discuss in a bit whether it's supposed
    >> to. It's quite clear it doesn't though. Crypto binding uses the
    >> MSK of the inner method for the binding.

    Alan>   RFC 5281 (TTLS) says:

    Alan>    Keying material for the subsequent data connection between
    Alan> client and access point (Master Session Key / Extended Master
    Alan> Session Key (MSK/EMSK); see Section 8) is generated based on
    Alan> secret information developed during the TLS handshake between
    Alan> client and TTLS server.

RFc 5281 does not provide cryptographic binding.

    >> discloses the MSK to the print server.  So, the print server has
    >> the material it needs to perform crypto binding and the generate
    >> the final MSK.

    Alan>   I don't see how.  The print server MUST use the MSK from
    Alan> it's TLS session for crypto bindings.  The MSK (if any)
    Alan> received from the home server isn't used for anything.

In RFC 5281 there is no cryptographic binding, so the attack trivially
succeeds without using the inner MSK.

    Alan>   On top of that, the client will verify that any random data
    Alan> (challenges, etc.) are generated from the MSK derived from the
    Alan> TLS session:

    Alan>    When a challenge-based authentication mechanism is used,
    Alan> both client and TTLS server use the pseudo-random function to
    Alan> generate as many octets as are required for the challenge,
    Alan> using the constant string "ttls challenge", based on the
    Alan> master secret and random values established during the
    Alan> handshake:

    Alan>   If the inner EAP session is forwarded to a home server, it
    Alan> will generate random challenges for methods like CHAP,
    Alan> MS-CHAP, EAP-MD5 and EAP-MSCHAPv1.  The client will check the
    Alan> challenges against the data it derives from the PRF.  The data
    Alan> will be different, and the client MUST discard it as being
    Alan> invalid.

As I read RFC 5281, the implicit challenge described in section 11.1 is
only used if  one of the implicit (non-EAP) tunneled authentications is
used, as described say in section 11.2.2.
However if EAP is used as described in 11.2.1, then the implicit
challenge in 11.1 is not used.
Using it would be a layering violation.
The implicit challenge described in 11.1 in RFc 5281 does not permit the
specific attack I described.
It inherently permits a different set of MITM attacks though, under
which the attacker controls the challenge.

    >> ... So, I think clients that do not validate certificates are
    >> quite real.

    Alan>   Yes.  This also includes clients which validate the
    Alan> certificate based on user input.  The users are known to just
    Alan> "click through" any certificate warnings.

Right.

    >> ... However reading that section again it sounds like the EAP
    >> tunnel method is intended to support cryptographic binding

    Alan>   Yes.

    >> Unfortunately, though, the MAC is protected by a combination of
    >> MSKs and the phase 1 keying information according to section 5.3.

    Alan>   I disagree, due to the discussion above.

The discussion above is very TTLS specific.
My point definitely applies unmodified to
draft-ietf-emu-eap-tunnel-method

    Alan>   This attack is possible only if the keys are derived from
    Alan> the inner tunnel data, instead of the outer TLS session.

No.

The attacker controls the outer TLS session. The attacker knows the MSK.
The keys need to be derived from something the attacker does not know in
order to avoid an attack.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 12 Jan 2012 19:29:42 +0200

Hi Sam, 

let us start with the problem description: You claim that EAP peer implementations use PK-based authentication but do not do certificate validation. This obviously introduces attacks (regardless of channel bindings, or crypto bindings). 

Any evidence that this is really a problem? And if it is a problem why that cannot be fixed with a software update. If you chose a specific EAP method then you obviously have to deploy the necessary credentials and parameters at both end points in order for it to work. 

Ciao
Hannes

PS: You are sometimes a bit relaxed with your terminology. Whenever you talk about client and server you need to qualify that further because there are multiple clients and servers involved in this three party exchange. 

On Jan 11, 2012, at 10:33 PM, Sam Hartman wrote:

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Jan 2012 13:02:28 -0500

>>>>> "Hannes" == Hannes Tschofenig <[email-masked]> writes:

    Hannes> Hi Sam, let us start with the problem description: You claim
    Hannes> that EAP peer implementations use PK-based authentication
    Hannes> but do not do certificate validation. This obviously
    Hannes> introduces attacks (regardless of channel bindings, or
    Hannes> crypto bindings).

    Hannes> Any evidence that this is really a problem? And if it is a
    Hannes> problem why that cannot be fixed with a software update. If
    Hannes> you chose a specific EAP method then you obviously have to
    Hannes> deploy the necessary credentials and parameters at both end
    Hannes> points in order for it to work.

As I went on to say, with the case of the eap tunnel method we're
specifying here, usecase 3.9 of the requirements document requires that
the method be secure if the inner method is sufficiently secure even if
certificates are not checked.

---

From: Joe Salowey <[email-masked]>
Date: Thu, 12 Jan 2012 10:16:38 -0800

Back when we were looking at the crypto binding problem, a MITM in the infrastructure was not part of the threat model.  We had some discussion of this, but we decided were able to get away with just using the MSK and that this would be easier for deployment since the EMSK wasn't really available at the time. 

With the Channel Bindings work the considerations in the threat model have changed somewhat.   It seems that taking this into consideration now may be appropriate.   Before deciding whether mutual cryptographic binding is important I think we need to make sure we understand the threat model that we are assuming since we currently have a gap.  We may find that just modifying the crypto-binding to use a key derived from the EMSK to provide mutual crypto binding may not solve the general problem of a MITM in the middle of the infrastructure.  

Is the characterization of the attacker someone that is part of the infrastructure and can impersonate a valid NAS/Proxy to the the AAA server?  

It seems that we are trying to minimize the threat that the attacker is able to impersonate the AAA server.  Are there other attacks?   Since part of the infrastructure is already compromised there are some threats we can not affect.  

I do think this needs to be discussed in the security considerations in the tunnel method even if we decide it is not important to fix.   It probably should also be discussed in the channel bindings document as well.  

Joe

---

From: Hao Zhou <[email-masked]>
Date: Thu, 12 Jan 2012 13:42:37 -0500

Ditto. 

The attack crypto-binding was originally designed is to prevent MITM
endpoint, not an MITM in the AAA infrastructure. The case described here is
legit AAA client acting as the EAP server, in fact no different than a legit
AAA server with an inner method server, other than the client is not
verifying the EAP server cert. Once this basic trust is compromised, there
might be other attacks. Using EMSK might not work, as many legacy methods
doesn't even have EMSK, and it will also prevent existing AAA server with
inner method working.

I do agree we need to document this in the security section, especially the
limitation of current crypto-binding and this potential attack.

On 1/12/12 1:16 PM, "Joe Salowey" <[email-masked]> wrote:

> Back when we were looking at the crypto binding problem, a MITM in the
> infrastructure was not part of the threat model.  We had some discussion of
> this, but we decided were able to get away with just using the MSK and that
> this would be easier for deployment since the EMSK wasn't really available at
> the time. 
> 
> With the Channel Bindings work the considerations in the threat model have
> changed somewhat.   It seems that taking this into consideration now may be
> appropriate.   Before deciding whether mutual cryptographic binding is
> important I think we need to make sure we understand the threat model that we
> are assuming since we currently have a gap.  We may find that just modifying
> the crypto-binding to use a key derived from the EMSK to provide mutual crypto
> binding may not solve the general problem of a MITM in the middle of the
> infrastructure.  
> 
> Is the characterization of the attacker someone that is part of the
> infrastructure and can impersonate a valid NAS/Proxy to the the AAA server?
> 
> It seems that we are trying to minimize the threat that the attacker is able
> to impersonate the AAA server.  Are there other attacks?   Since part of the
> infrastructure is already compromised there are some threats we can not
> affect.  
> 
> I do think this needs to be discussed in the security considerations in the
> tunnel method even if we decide it is not important to fix.   It probably
> should also be discussed in the channel bindings document as well.
> 
> Joe
>

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Jan 2012 14:11:51 -0500

>>>>> "Joe" == Joe Salowey <[email-masked]> writes:

    Joe> Back when we were looking at the crypto binding problem, a MITM
    Joe> in the infrastructure was not part of the threat model.  We had
    Joe> some discussion of this, but we decided were able to get away
    Joe> with just using the MSK and that this would be easier for
    Joe> deployment since the EMSK wasn't really available at the time.
    Joe> With the Channel Bindings work the considerations in the threat
    Joe> model have changed somewhat.  It seems that taking this into
    Joe> consideration now may be appropriate.  Before deciding whether
    Joe> mutual cryptographic binding is important I think we need to
    Joe> make sure we understand the threat model that we are assuming
    Joe> since we currently have a gap.  We may find that just modifying
    Joe> the crypto-binding to use a key derived from the EMSK to
    Joe> provide mutual crypto binding may not solve the general problem
    Joe> of a MITM in the middle of the infrastructure.

    Joe> Is the characterization of the attacker someone that is part of
    Joe> the infrastructure and can impersonate a valid NAS/Proxy to the
    Joe> the AAA server?

That's a true characterization of the attacker, but I think it is very
misleading.  first, it's easy to dismiss: the infrastructure is secure,
why are you worrying about this.  Second, it tends to get wrapped around
treating all infrastructure compromises the same, which I think will not
be productive.  Finally, it fails to account for the change in value of
the system that is leading to the threat model change.

I think the common elements in these attacks are:

1) The client trusts some parts of the infrastructure more than others.

2) The client uses information from the infrastructure to make decisions
and cares about which infrastructure component it is from.

Here are some examples of this:

In NEA, there are components responsible for generating posture policy
and giving clients posture assessment that are more trusted.  A client
might reasonably care about a compromise of these components more than a
compromise of some access point.

In channel bindings, the client explicitly wants to separate the
infrastructure into trust classes. That's basically the primary thing
channel bindings do. The client wants to make decisions about whether to
use a service and on how to use a service based on what service it
is. Explicit in the channel binding design is that some services might
benefit from impersonating other services and channel bindings is part
of a technical means to prevent that.  I think that is inherently a
threat model change requiring that one NAS not be able to impersonate
another.

--Sam

---

From: Joe Salowey <[email-masked]>
Date: Thu, 12 Jan 2012 13:56:06 -0800

I agree that not all infrastructure attacks are the same.   I wasn't trying to be misleading. What is important is that we are clear about what we are attempting and claiming to solve and what the assumptions are.  

THere are somethings we may not be able to protect against.  For example we may not be able to protect against a rogue NAS that is part of the infrastructure that is misbehaving but still operating within its authorized parameters or under the authorized parameters of some intermediate compromised proxy.   I think this is the point that Glen was bringing up in the meeting Taiwan.  

FWIW, I think we should take this into consideration in the tunnel method.  The EMSK is defined for most methods now.  One concern is that some implementations may not export it yet.   Another concern is that we understand what we are really fixing and we don't over or under sell it.  

Cheers,

Joe

---

From: Alan DeKok <[email-masked]>
Date: Fri, 13 Jan 2012 10:55:54 +0100

> RFc 5281 does not provide cryptographic binding.

  Well, then I either misunderstand 5281, or I misunderstand what crypto
binding is.  I thought that crypto binding was used to bind the results
of chained key generating methods together or to an encompassing tunnel.

  Which is what is done in 5281.

> succeeds without using the inner MSK.

  There is no inner MSK with TTLS or PEAP.  (PAP, CHAP, MS-CHAP,
EAP-MD5, or EAP-MSCHAP in the inner tunnel)

> challenge in 11.1 is not used.

  OK.  I had misremembered that part.

> order to avoid an attack.

  OK.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Jan 2012 11:00:56 -0500

>> RFc 5281 does not provide cryptographic binding.

    Alan>   Well, then I either misunderstand 5281, or I misunderstand
    Alan> what crypto binding is.  I thought that crypto binding was
    Alan> used to bind the results of chained key generating methods
    Alan> together or to an encompassing tunnel.

This is most of crypto binding.
The additional thing crypto binding needs to do is to chain these keys
together  in a manner that detects man-in-the-middle attacks.
I can't find anything in RFC 5281 that does that.
In fact, RFc 5281 is explicitly designed to permit man-in-the-middle
attacks, on the grounds that the TTLS server may be different from the
AAA server/EAP server.

There's a discussion of  crypto binding in RFC 5281  that specifically
says there is none but points to some proposals for the future.

TTLSv1 does appear to have crypto binding based on code analysis  when
you're using an inner EAP method that generates an MSK.
TTLSv1 neither tries to nor has mutual crypto binding.

    >> In RFC 5281 there is no cryptographic binding, so the attack
    >> trivially succeeds without using the inner MSK.

    Alan>   There is no inner MSK with TTLS or PEAP.  (PAP, CHAP,
    Alan> MS-CHAP, EAP-MD5, or EAP-MSCHAP in the inner tunnel)

I think what you're saying here is there are a lot of non-keyed EAP
methods and if you use them as an inner method then you don't get an
inner MSK.  Absolutely right; if we want to defend against the sort of
attacks I was bringing up here for these methods your solution
(something based on user credentials) is the only thing that would work.

As you already said, nothing can save PAP:-)

So,  here's where I'm at in decreasing order of priority:

1) document security considerations; I think everyone can agree on this.

2) Provide mutual crypto binding for tunnels using an inner method with
an EMSK

3) Figure out if we want to do something like what you propose  using
long-term credentials for inner methods that don't have an EMSK.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 13 Jan 2012 17:14:32 +0100

> I can't find anything in RFC 5281 that does that.

  OK.  I think we're converging.

> 1) document security considerations; I think everyone can agree on this.

  Yes.  Details to come.

  At the minimum, a discussion of the certificate attacks and
provisioning would be useful.  i.e. doing provisioning when you don't
trust *anyone* is a bad idea.  Provisioning on a known / secure network
is a much better idea.

  For certificates, when user@realm authenticates, the goal is to have
an AAA server in that realm terminate the TLS tunnel.  What implications
does that have for the system?

  Yes.

> long-term credentials for inner methods that don't have an EMSK.

  That's a wider discussion for the WG.  I'd like to see more input.

  Alan DeKok.