Subject: Re: [eap] Re: preserving packet order in EAP

From: Alper Yegin <[email-masked]>
Date: Mon, 20 Jan 2003 23:14:05 -0800

On 1/20/03 12:46 PM, "Bernard Aboba" <[email-masked]> wrote:

> On Monday, January 20, 2003 Dan Forsberg wrote:
> 
>> EAP requires that packet order is maintained by the lower layer. My
>> concern is that EAP can't be carried by UDP or IP alone, because these
>> protocols do not preserve the packet order?
> 
> Those transports are illegal, because they don't preserve order, correct.

If UDP or ICMP is used as transport, couldn't an identifier field
in the PANA header be a solution to this problem?

> 
>> TCP/SCTP would be another option to carry EAP, but EAP detects
>> duplicates and does re-transmissions already.
> 
> Yes, those transports would be fine, providing that they provide the
> appropriate security -- namely per-packet integrity and authentication.
> 

Assuming we are talking about per-(data-)packet integrity and authentication
after the initial authentication, how is this related to the EAP
transport? Regardless of the EAP transport, that protection should
be provided by physical, link-layer or network-layer mechanisms.

alper

>> Another comment/question:
>> Isn't EAP request-response style protocol, so what are the
>> possibilites/consequences for packet order mismatch?
> 
> The issue comes up since RFC 2284 doesn't require the Identifier space to
> be monotonically increasing. That means that if a Request packet with ID 1
> were retransmitted, and arrived *after* a Request packet with ID 2, it
> could be erroneously thought by the peer to represent a new Request,
> rather than a retransmission.
> 
>> One possible solution for this problem is to require the Authenticatee to
>> remember
>> the ID numbers inside the EAP method (message id's between the initial
>> request and  Success/Failure msgs). This would imply that no EAP method
>> should produce more than 256 requests per authentication.
> 
> That would be incompatible with existing implementations, would
> impact re-authentication and would enable new DoS attacks.
> 
>> Another solution to this problem is to prohibit simultaneous *same type* of
>> authentications.
> 
> Again, that is incompatible with existing implementations, which can
> authenticate multiple users at a time.
> 
> 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

---

From: <[email-masked]>
Date: Tue, 21 Jan 2003 10:31:03 +0200

removed eap mailing list from cc.
comments below.

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: 21 January, 2003 08:52
> To: Alper Yegin
> Cc: [email-masked]; [email-masked]
> Subject: Re: [eap] Re: preserving packet order in EAP
> 
> 
> If you're saying that PANA would define its own transport 
> over UDP that
> preserved ordering, yes that would work.
> 
> It is related because otherwise you have not tied the key 
> that is derived
> in EAP to subsequent data and you have a vulnerability to 
> hijacking. So
> you might have used EAP for authentication -- but security 
> has not been
> achieved.

I don't know if I understood all, but if EAP key derivation is used to bootstrap (IKE) the per-packet protection, then this would not be the case (Alper mentioned this previously in PANA list). Similar to PIC, for example, which is vulnerable to the MitM, though.

> 
> There are also issues relating to protection of the EAP 
> exchange itself.
> Those can presumably be solved by choice of method -- but if PANA also
> does not make any recommendations in that department, then 
> that is also a
> vulnerability.
> 

EAP methods are required to clarify their security level. It would make sense for PANA to clarify what security level is needed with PANA protocol. PANA could also have security enhancing features, that require less security from EAP methods. One example could be replay and integrity protection.

- Dan

---

From: <[email-masked]>
Date: Wed, 22 Jan 2003 13:05:20 +0200

> Sent: 21 January, 2003 10:50
> To: Forsberg Dan (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [eap] Re: preserving packet order in EAP
> 
> 
> > I don't know if I understood all, but if EAP key derivation 
> is used to
> > bootstrap (IKE) the per-packet protection, then this would 
> not be the
> > case (Alper mentioned this previously in PANA list). 
> Similar to PIC, for
> > example, which is vulnerable to the MitM, though.
> 
> I think it is a bit different because in that case, the EAP 
> derived keys
> are used as a bootstrap, but the EAP exchange itself does not 
> occur within
> a tunnel. Is there a MiTM attack that is possible in such a situation?
> If this is the scheme that PANA is recommending, then I would 
> recommend a
> security analysis be done so that the properties of the 
> scheme are well
> understood from the start.
> 
> > EAP methods are required to clarify their security level. 
> It would make
> > sense for PANA to clarify what security level is needed with PANA
> > protocol.
> 
> Yes. My guess is that in wireless scenarios, PANA would probably have
> requirements equivalent to IEEE 802.11i. In wired scenarios, the
> requirements might be considerably less.
> 
> > PANA could also have security enhancing features, that require
> > less security from EAP methods. One example could be replay and
> > integrity protection.
> 
> This is where the MiTM issue rears its head. You might think 
> that because
> the lower layer provides confidentiality, integrity and 
> replay protection
> that the EAP method can be less secure. But
> draft-puthenkulam-eap-binding-01.txt shows that the opposite 
> is true --
> that without crytpographic binding (only achievable for 
> methods that are
> mutually authenticating and derive keys), a MiTM attack can 
> be mounted.
> 
> So, it wouldn't appear that lower layer security has that much
> effect on EAP method requirements.
> 

TLS requires certificate from the server (AN). PaC could use a PK to authenticate/verify the AN certificate and further authenticate the AN.

If PaC has the PK of the AAAH/AS, it can use it to encrypt the TLS session key and a shared secret (password etc.) plus random/nonce/timestamp etc. to create a cryptographic binding between the tunnel and something that the PaC and AAAH/AS only knows (shared secret). PAA would then send the TLS Session key (or hash of it) to the AAAH in a secure way. In this way weak EAP methods can also be used in a more secure way.

This requires that the AAAH can verify the data from PaC (i.e. needs to fetch the shared secret from the AS or let the AS do the verification) and that the PaC is able to use the shared secret for this purpose.

- Dan

---

From: Alper Yegin <[email-masked]>
Date: Wed, 22 Jan 2003 13:52:08 -0800

and this is the last one...
sorry for the inconvenience these out-of-order fwds created.

alper

------ Forwarded Message
From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Jan 2003 00:50:10 -0800 (PST)
To: [email-masked]
Cc: [email-masked], <[email-masked]>
Subject: RE: [eap] Re: preserving packet order in EAP

> I don't know if I understood all, but if EAP key derivation is used to
> bootstrap (IKE) the per-packet protection, then this would not be the
> case (Alper mentioned this previously in PANA list). Similar to PIC, for

I think it is a bit different because in that case, the EAP derived keys
are used as a bootstrap, but the EAP exchange itself does not occur within
a tunnel. Is there a MiTM attack that is possible in such a situation?
If this is the scheme that PANA is recommending, then I would recommend a
security analysis be done so that the properties of the scheme are well
understood from the start.

> EAP methods are required to clarify their security level. It would make

> less security from EAP methods. One example could be replay and

This is where the MiTM issue rears its head. You might think that because
the lower layer provides confidentiality, integrity and replay protection
that the EAP method can be less secure. But
draft-puthenkulam-eap-binding-01.txt shows that the opposite is true --
that without crytpographic binding (only achievable for methods that are
mutually authenticating and derive keys), a MiTM attack can be mounted.

------ End of Forwarded Message