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

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 7 Jul 2008 11:48:15 -0700

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-masked] [mailto:[email-masked]] On 
> Behalf Of Bernard Aboba
> Sent: Wednesday, June 25, 2008 11:47 PM
> To: [email-masked]
> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Wed, 9 Jul 2008 10:24:08 -0400

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.

> Behalf Of Joseph Salowey (jsalowey)
> Sent: Monday, July 07, 2008 2:48 PM
> To: Bernard Aboba; [email-masked]
> 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?
> 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 
> Behalf Of 
> > Bernard Aboba
> > A comment on EAP header protection (Section 4.2.3) and Type code 
> > modification (Section 6.3):
> > 
> > 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.
> > 
> 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:   
> > Assuming that this approach is taken, the Type modification threat 
> > described in Section 6.3 can be addressed without EAP header 
> > protection.
> > 
> > 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.
> > 
> >

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 9 Jul 2008 14:05:09 -0700

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.

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Wed, 9 Jul 2008 17:09:20 -0400

Sounds fine to me.

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Wednesday, July 09, 2008 5:05 PM
> To: Hao Zhou (hzhou); Joseph Salowey (jsalowey); [email-masked]
> 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.  
> 
> 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.
> 
> > Joseph Salowey (jsalowey)
> > 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?
> systems such 
> > as 802.1X-2004, do not make use of the MSK/EMSK.
> 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
> > 
> TLS-based EAP 
> > > 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.
> > > 
> > > 
> 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.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >