Re: [Emu] Review of Requirements for an Tunnel Based EAP Method

["Hao Zhou (hzhou)" <hzhou at cisco.com>]

Sounds fine to me.

> -----Original Message-----
> From: Bernard Aboba [mailto:Bernard_Aboba at hotmail.com] 
> Sent: Wednesday, July 09, 2008 5:05 PM
> To: Hao Zhou (hzhou); Joseph Salowey (jsalowey); emu at 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:hzhou at cisco.com]
> Sent: Wednesday, July 09, 2008 7:24 AM
> To: Joseph Salowey (jsalowey); Bernard Aboba; emu at 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: emu-bounces at ietf.org [mailto:emu-bounces at ietf.org] On 
> Behalf Of 
> > Joseph Salowey (jsalowey)
> > Sent: Monday, July 07, 2008 2:48 PM
> > To: Bernard Aboba; emu at 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: emu-bounces at ietf.org [mailto:emu-bounces at ietf.org] On
> > Behalf Of
> > > Bernard Aboba
> > > Sent: Wednesday, June 25, 2008 11:47 PM
> > > To: emu at 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 at ietf.org
> > https://www.ietf.org/mailman/listinfo/emu
> > 
> 
> 
_______________________________________________
Emu mailing list
Emu at ietf.org
https://www.ietf.org/mailman/listinfo/emu