Subject: RE: [Emu] Partial Proposed Resolution to RFC 2716bis Review

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 27 Jun 2006 15:16:09 -0700

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Saturday, June 24, 2006 7:25 PM
> To: [email-masked]
> Subject: RE: [Emu] Partial Proposed Resolution to RFC 2716bis Review
> 
> >I will add some text on this vulnerablity, which is enabled because 
> >some TLS-based methods share the same key-derivation formula.
> 
> How about this?
> 
> "4.6.  Packet Modification Attacks
> 
>    The integrity protection of EAP-TLS packets does not extend to the
>    EAP header fields (Code, Identifier, Length) or the Type or Flags
>    fields.  As a result, these fields may be modified by attacker.
> 
>    In most cases modification of the Code or Identifier 
> fields will only
>    result in a denial of service attack.  However, it may be possible
>    for an attacker to add additional data to an EAP-TLS 
> packet so as to
>    cause it to be longer than implied by the Length field.  An
>    implementation that does not check for this could be 
> vulnerable to a
>    buffer overrun.
> 
>    It is also possible for an attacker to modify the Type or Flags
>    fields.  By modifying the Type field, an attacker could cause one
>    TLS-based EAP method to be negotiated instead of another.  For
>    example, the EAP-TLS Type field (13) could be changed to indicate
>    another TLS-based EAP method.  Unless the alternative TLS-based EAP
>    method utilizes a different key derivation formula, it is possible
>    that an EAP method conversation altered by a 
> man-in-the-middle could
>    run all the way to completion without detection.  
> Unless the
>    ciphersuite selection policies are identical for all TLS-based EAP
>    methods utilizing the same key derivation formula, it may 
> be possible
>    for an attacker to mount a successful downgrade attack, causing the
>    peer to utilize an inferior ciphersuite or TLS-based EAP method."
>

[Joe] OK, I'm not sure we need to include text about the key derivation.
If it is the key derivation that is the only difference then change will
only be caught after the completion of the method if the keys are used.

> 
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/emu
> 

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 27 Jun 2006 18:13:37 -0700

>only be caught after the completion of the method if the keys are used.

The problem is that if the EAP-TLS key derivation formula is re-used in an 
another method (as it has been), then the problem may never be caught.   So 
I think we need to caution against that.