Sounds fine to me.
> -----Original Message----- > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 09, 2008 5:05 PM > To: Hao Zhou (hzhou); Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Review of Requirements for an Tunnel Based > EAP Method > > Given this, the requirement could be rephrased to highlight > the items that need to be protected (type code, version > numbers, etc.), while dropping the EAP Header protection > requirement. > > -----Original Message----- > From: Hao Zhou (hzhou) [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 09, 2008 7:24 AM > To: Joseph Salowey (jsalowey); Bernard Aboba; emu@ietf.org > Subject: RE: [Emu] Review of Requirements for an Tunnel Based > EAP Method > > 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
