Subject: [Emu] ICV in EAP-PAX

From: Thomas Otto <[email-masked]>
Date: Sat, 29 Apr 2006 12:08:26 +0200

Hi all, 
the following question arose while re-reading several specs. 

EAP-PAX computes an ICV (Integrity Check Value) as follows (Sect. 3.3)

   The ICV is computed as the MAC over the entire EAP packet, including
   the EAP header, the EAP-PAX header, and the EAP-PAX payload.  The MAC
   is keyed using the 16-octet ICK, using the MAC type specified by the
   MAC ID in the EAP-PAX header.  For packets of type PAX_STD-1,
   PAX_SEC-1, PAX_SEC-2, and PAX_SEC-3, where the MK has not yet been
   derived, the MAC is keyed using a zero-octet NULL key.
   If the ICV field is incorrect, the receiver MUST silently discard the
   packet.

But RFC 3748 days in Section 3.1 

       [...] EAP methods may not
       include a MIC, or if they do, it may not be computed over all the
       fields in the EAP packet, such as the Code, Identifier, Length,
       or Type fields.   [...]

So, is the ICV of EAP-PAX compliant to RFC 3748 at all? 

And which additional security is obtained through the ICV ? 

(Compare the packet-wise MAC to the strategy of TLS: There, it suffices
to compute at the end a checksum (by means of the Finished messages) 
over the whole handshake messages to ensure the handshake's
integrity).  

We should discuss whether the ICVs are allowed and/or makes sense.
(... I remember EAP-SAKE also computes an ICV over the whole packet ...)

Thomas

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 29 Apr 2006 07:55:01 -0700

>So, is the ICV of EAP-PAX compliant to RFC 3748 at all?

Yes, it is compliant.  The text above was meant to convey that not all EAP 
methods will be able to cover the entire EAP packet in their MAC.

>And which additional security is obtained through the ICV ?

The ability to protect against modification of the EAP header fields 
including Code, Identifier, Length and Type.

>over the whole handshake messages to ensure the handshake's

The problem with the approach taken by TLS-based methods is that they are 
vulnerable to Type substitution attacks.  For example, it is possible to 
take a TLS packet sent as part of EAP-TLS, EAP-TTLS, PEAP, TLS-PSK, etc. and 
change the Type field, making it seem like it is a packet of another Type.  
If done as part of the initial Request/Response exchange, it is possible to 
fool the EAP Peer into accepting a proposal of a wrong Type.  If only one 
packet has its Type changed, according to the EAP state machine RFC 4137, 
such an attack would cause the entire EAP exchange to fail.

However, if all the packets coming from the server have their Type changed, 
it may be possible for the entire TLS exchange to conclude successfully 
without the peer figuring out that the wrong Type has been used.  If the TLS 
session cache is shared by all TLS-based methods, and the peer does not tie 
together the TLS Session-ID with the Type used, it would be possible for the 
peer to successfully resume a session created by EAP-TLS within an EAP-TTLS 
or PEAP conversation, without even realizing that it was actually an EAP-TLS 
resumption.