The intent of this requirement is to protect any data sent outside the TLS data. This would include the EAP header and any method specific fields such as version number field. We know we cannot protect these data before a TLS session is established, most likely we are talking about validation afterwards.
The EAP header protection, as discussed below, might not bring much value. I am ok with removing it. Another related problem is protection or validation of version negotiation, which is usually happened outside the TLS protection. To prevent downgrade attack, we should add some requirement to make sure there is some validation of the advertised version number or any method specific data sent outside TLS of both sides. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Joseph Salowey (jsalowey) > Sent: Monday, July 07, 2008 2:48 PM > To: Bernard Aboba; emu@ietf.org > Subject: Re: [Emu] Review of Requirements for an Tunnel Based > EAP Method > > 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 > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
