Subject: RE: PANA threat evaluation draft.

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 24 Oct 2002 14:06:02 -0700

> 
> Mohan,
> 
> If a security association established as a result of mutual 
> authentication is not cryptographycally bound to the device 
> identifier or something that needs to be protected, a class 
> of MiTM attack that Subir mentioned is still possible.  This 

I just read your draft. At least this problem seems specific to
TLS here. Is it because that from the TLS protected packet, one can
say that the packet came from BoB (because of the key that
is being shared with BoB), but not BoB at IP address X. 
Is that correct ? At least I don't see how this can happen if 
Ipsec was used because the Ipsec SA would be bound
to the Identity, normally the IP address exchanged when the
Ipsec SA was established (I am just using Ipsec as an example
to understand the problem here) In PANA over TLS, following
happens I think (please correct me if I am wrong) :

1) PaC and backend authentication server mutually authentiate
   each other. Assume Full TLS authentication for now. Let's also
   assume that we can secure the channel between PaC and PAA
   by deriving the keys. At this step none other than PaC
   and PAA would know about these keys.

2) EAP exchange takes place on this secure channel according to
   the draft.  I would assume that this is a bunch of request/response
   exchanges between PaC, PAA and the authentication server. A man
   in the middle cannot modify the EAP data without being detected as
TLS
   provides integrity for the EAP data portion. A potential possibility
   is the replay of some old EAP messages, for which we need replay
protection
   which may not be available with EAP today.

   At the end, when the EAP success is sent to the PaC, we need a way to
   authorize the PaC i.e we need to know the IP address/MaC address. As
   TLS does not protect the IP headers, we can't learn these values
   successfully from the IP header. Thus, we need it part of the
exchange
   which is what device identifier exchange does I guess.

Is that correct understanding (simplified) of PANA over TLS ?

> is also desribed in the PANA over TLS draft (it defines 
> Device Identifier protection mechanism for this purpose), and 
> a similar issue is also being discussed in the EAP WG.
> 
I just started reading the issues. If you are still talking about
EAP success/failure issue, I am still trying to understand all
the details of that issue. 

-mohan

> BTW, I'm not sure whether IKE is free from any kinds of MiTM attacks.
> 
> Yoshihiro Ohba
> 
> 
> On Wed, Oct 23, 2002 at 10:11:47AM -0700, Mohan Parthasarathy wrote:
> > 
> > Subir,
> > 
> > > 
> > > 
> > > Mohan,
> > > Here is a quick comment:
> > > 
> > > Requirement 3:
> > > 
> > > Are you assuming that layer-2 security exists here? If 
> not, then by
> > > mutual authentication you may not be able to avoid some 
> MITM attacks. 
> > >
> > There is no assumption about layer 2 in this case.
> > 
> > > For example, an AP can come in between PaC and PAA and forward the
> > > PaC's credentials by simply changing the IP/MAC address. Once 
> > > authentication is successful (mutual authentication is performed) 
> > > AP disconnects the PaC and gains the access. 
> > > 
> > How does mutual authentication succeed in this case ?  PaC and AS 
> > share a secret (could be in the form of pre-shared key, certificates
> > etc.) which is not known to anybody else and they verify 
> the identity 
> > of each other by generating and verifying a hash. For example, IKE 
> > provides mutual authentication.
> 
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 24 Oct 2002 17:46:39 -0400

Mohan,

On Thu, Oct 24, 2002 at 02:06:02PM -0700, Mohan Parthasarathy wrote:
> Is that correct ? 

Yes.

> At least I don't see how this can happen if 

I'm not sure this issue is specific to TLS.  I'd like to know whether
similar MiTM attack is possible for IKE when the Identity is not bound
to IP address but to FQDN or USER_FQDN.  

> Is that correct understanding (simplified) of PANA over TLS ?

Yes.

> the details of that issue. 

No, I'm not talking about EAP success/failure issue.  It is related to
"EAP Issue 40: Man-in-the-middle attacks on EAP method sequence"
(please see attached email).  Bernard commented me that a similar
cryptographic binding would be also necessary between TLS (or PANA)
session and EAP session.

Yoshihiro Ohba

> > > provides mutual authentication.

Subject: RE: [eap] Issue 40: Man-in-the-middle attacks on EAP method seque nces and tunnels
From: "Puthenkulam, Jose P" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, [email-masked]
Date: Tue, 22 Oct 2002 17:24:27 -0700
List-Id: Discussion list for EAP <eap.frascone.com>

Its really good that we are trying to fix this problem in EAP if possible.
But don't we need to address the EAP key derivation framework first before
we
address this issue. The reason is that any key derivation framework we add
to EAP
will have to be designed with such a cryptographic binding capability
between
sequenced or tunnelled EAP methods.

Thanks,
jose

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Jose Puthenkulam
   Senior Software Engineer
   Emerging Platforms Lab
   Intel R & D
   Intel Corporation
   2111 NE 25th Avenue, JF2-58
   Hillsboro, OR 97124
   Tel: (503) 264 6121
   Fax: (503) 264 8154
   Email: [email-masked]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Monday, October 21, 2002 7:09 PM
To: [email-masked]
Subject: [eap] Issue 40: Man-in-the-middle attacks on EAP method sequences
and tunnels

Issue 40: Man-in-the-middle attacks on EAP method sequences and tunnels
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: October 21, 2002
Reference:
Document: RFC2284bis-06
Comment type: T
Priority: S
Section:  4.3

Rationale/Explanation of issue:
When EAP methods are used as part of a sequence or within a
tunnel, RFC 2284 does not provide a mechanism to cryptographically
bind subsequent authentication methods together.

The result of this is that neither side of the conversation
has any assurance that they are talking to the same endpoint
throughout the conversation, making EAP implementations
vulnerable to a man-in-the-middle attack. A number of existing EAP methods
are vulnerable to such an attack.

The problem occurs on the peer, where a rogue NAS could
fool a peer into authenticating to it, while acting as a
man-in-the-middle, and tunneling the peer's authentication
to another authenticator.

The vulnerability also exists on the server, where a proxy
can handle a portion of an authentication sequence while
routing other portions to other servers.

With EAP being increasingly adopted across multiple media,
including cellular, IEEE 802, and PPP, the need for such
a binding facility has become critical.

Binding requires both sides to demonstrate that they acted
as the endpoint for the sequence of authentication methods.
On the peer, this implies that the same entity acted as
the peer in each of the sequence of authentication mechanisms.
Similarly, on the authenticator, binding implies that the
same entity acted as the authenticator in each method within
the sequence.

There may be situations in which it may not be desirable for
binding to be required. For example, the server may not wish
to demonstrate binding, but may desire the client to do so.
Alternatively, the client may demand that the server demonstrate
binding. As a result, some flexibility is required within the
binding facility.

Note that there are a number of choices as to how binding
might be demonstrated:

a. Individual EAP methods may incorporate keys derived from
previous methods in order to demonstrate not only possession
of a shared secret, token or certificate, but possession of
previously derived key(s) as well. However, this approach
has the disadvantage of requiring that existing EAP methods
be modified to accomodate the binding facility. In many cases
this will not be possible since those methods are already
developed and deployed.

b. The binding facility can be provided within individual
EAP methods. This has the advantage of not requiring EAP
implementations to be upgraded, but has the disadvantage of
requiring the same facility to be developed multiple times.
This would result in overlapping effort as well as poor
interoperability among implementations.

c. The binding facility can be provided within EAP itself.
This has the advantage of enabling widespread interoperability
between implementations, and applicability to multiple EAP
methods. However, it has the disadvantage of being harder
to deploy.

Suggested changes

Add to section 7.2:
"[7] Protection against man-in-the-middle attacks. Where EAP is tunneled
within another protocol, or where a sequence of EAP method is used for
authentication, it is necessary for each endpoint to demonstrate that it
has participated in each method within the authentication sequence. If
this cannot be demonstrated then, the authentication
sequence or tunnel is vulnerable to a man-in-the-middle attack. "
Add a binding facility to EAP itself, possibly in concert with acknowleged
EAP Success/Failure.

Resolution: Discuss

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap