I think this issues has been raised in the past, does anyone on the list have any specific scenarios where EAP header protections are important? If not the requirement can be downgraded or removed entirely.
With respect to making one method look like another, some systems such as 802.1X-2004, do not make use of the MSK/EMSK. Does this introduce a problem? I can't really think an exploitable attack outside of denial of service at this point. In addition, more and more systems are moving towards some type of cryptographic verification in the lower layer so this might not being an ongoing problem. Joe > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Bernard Aboba > Sent: Wednesday, June 25, 2008 11:47 PM > To: emu@ietf.org > Subject: [Emu] Review of Requirements for an Tunnel Based EAP Method > > Overall, this document is in very good shape. Kudos to the authors. > > A comment on EAP header protection (Section 4.2.3) and Type > code modification (Section 6.3): > > 4.2.3. EAP Header Protection > > > A tunnel method SHOULD provide protection of the outer EAP header > information when possible to make sure the outer EAP header is not > modified by the intermediaries. > > 6.3. Outer EAP Method Header > > There are several existing EAP methods which use a similar packet > format to EAP-TLS. Often for the initial portions of the exchange > the execution of the method is identical except for the method ID. > Protection of the outer EAP header helps to avoid vulnerabilities > that may arise when an attacker attempts to modify packets to make > one EAP message look like one from a different method. > > [BA] The EAP header defined in RFC 3748 looks like this: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Code | Identifier | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type ... > +-+-+-+-+ > > Section 6.3 refers to modification of the Type field which > can potentially enable an attacker to make one TLS-based EAP > method look like another one. It's worth noting that such an > attack can be addressed without necessarily requiring EAP > header protection, as described in Section 4.2.3. > > For example, a Type field modification attack will only > enable an EAP peer to subsequently connect to an > authenticator if the peer and server were able to derive the > same MSK/EMSK. > > To prevent such an attack, it is highly desirable for > TLS-based EAP methods to utilize key derivation formulas > unique to the method. As an example, EAP-TLS and EAP-TTLSv0 > utilize different key derivation formulas: > > EAP-TLS: > Key_Material = TLS-PRF-128(master_secret, "client EAP encryption", > client.random || server.random) > EAP-TTLSv0: > Keying Material = TLS-PRF-128(master_secret, > "ttls keying material", client_random || > server_random) > > Assuming that this approach is taken, the Type modification > threat described in Section 6.3 can be addressed without EAP > header protection. > > Given this, it seems to me that EAP header protection is > really about protection of the Code, Identifier > and Length fields of the EAP header. However, the behavior > of these fields is fairly rigidly specified > in RFC 3748, so that a well written implementation should > only be vulnerable to DoS attack, which would be the case > even if EAP header protection were implemented. > > For example, an attacker modifying the Code field might be > able to cause an EAP peer or server to drop the packet. > However, the same thing would happen if EAP header protection > were implemented, and the packet failed the MIC check. > > > Via modification of the Identifier field, it might be > possible to cause the peer or server to abort the EAP session > in progress. However, in TLS-based methods, failure of TLS > integrity check is also a terminal error, so that I'm not > sure if anything is gained here either. > > > Modification of the Length field might have as its objective > the inducement of a buffer overflow on either the peer or the > server, so it's aims are somewhat more nefarious than attacks > on the Code or Identifier fields. However, implementation of > EAP header protection would not be likely to address such an > implementation bug since the MIC could not be computed until > the EAP packet was fully received, by which time the buffer > overflow would have already occurred. > > > In summary, I am not clear that EAP header protection as > described in Section 4.2.3 really brings much value beyond > addressing the EAP Type Code attack described in Section 6.3. > I would therefore recommend that this section be deleted, or > at least justified in more depth. > > > > > > > > > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
