eap Mailing List: RE: Issue 208: Physical Security

[Joseph Salowey (jsalowey]

> -----Original Message-----
> From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] 
> On Behalf Of Alper Yegin
> Sent: Friday, December 19, 2003 12:34 PM
> To: Bernard Aboba
> Cc: eap [at] frascone.com
> Subject: Re: [eap] Issue 208: Physical Security
> 
> 
> 
> 
> > How about this?
> 
> This looks good, except at couple of points below.
> 
> > In Section 3.4, change:
> > 
> > " After EAP authentication is complete, the peer will typically 
> > transmit data to the network via the authenticator. In order to 
> > provide assurance that the peer transmitting data is the 
> same entity 
> > that successfully completed EAP authentication, the lower 
> layer needs 
> > to bind per-packet integrity, authentication and replay 
> protection to 
> > the original EAP authentication, using keys derived during EAP 
> > authentication. Alternatively, the lower layer needs to be 
> physically 
> > secure. Otherwise it is possible for subsequent data traffic to be 
> > hijacked or replayed.
> > 
> > As a result of these considerations, EAP SHOULD be used only when 
> > lower layers provide physical security for data (e.g., wired PPP or 
> > IEEE 802 links), or for insecure links, where per-packet 
> > authentication, integrity and replay protection is provided."
> > 
> > To:
> > 
> > " After EAP authentication is complete, the peer will typically 
> > transmit data to the network via the authenticator. In order to 
> > provide assurance that the peer transmitting data is the 
> same entity 
> > that successfully completed EAP authentication, the lower 
> layer needs 
> > to bind per-packet integrity, authentication and replay 
> protection to 
> > the original EAP authentication, using keys derived during EAP 
> > authentication.  Otherwise it is possible for subsequent 
> data traffic 
> > to be hijacked or replayed."
> 
> 
> I'd drop the "using keys derived during EAP authentication." 
> part. I can rely on physical security for the binding.

[Joe] I don't think this part should be removed.  You might make it
conditional, but then we must explain when it can be relaxed.  I think
there is some threat model in the document already that requires this.

> 
> > In Section 7.13, change:
> > 
> > " [c] Where EAP is used over lower layers which are not physically 
> > secure, after completion of the EAP conversation, a secure 
> association 
> > protocol SHOULD be run between the peer and authenticator 
> in order to 
> > provide mutual authentication; guarantee liveness of the 
> TSKs; provide 
> > protected ciphersuite and capabilities negotiation; synchronize key 
> > usage."
> > 
> > To:
> > 
> > "[c] After completion of the EAP conversation, where the 
> lower layer 
> > supports security services such as per-packet confidentiality, 
> > authentication, integrity and replay protection, a secure 
> association 
> > protocol SHOULD be run between the peer and authenticator 
> in order to 
> > provide mutual authentication; guarantee liveness of 
> transient session 
> > keys; provide protected ciphersuite and capabilities 
> negotiation; and
> > synchronize key usage."
> 
> I think, we should either:
> - change "SHOULD" to "MAY" or "can"; or
> - "where the lower layer security services such as per-packet 
> confidentiality, authentication, integrity and replay 
> protection will to be enabled"
> 
> > 
> > In Section 7.14, change:
> > 
> > "   EAP does not support cleartext password authentication.  This
> >  omission is intentional.  Where EAP is carried over physically  
> > insecure lower layers, including wireless LANs 
> [IEEE-802.11] or the  
> > Internet, use of cleartext passwords would allow the 
> password to be  
> > captured by an attacker with access to the lower layer.
> > 
> >  Since protocols encapsulating EAP, such as RADIUS 
> [RFC3579], may not  
> > provide confidentiality, even where the lower layer is physically  
> > secure, EAP frames may be subsequently encapsulated for transport  
> > over the Internet where they may be captured by an attacker."
> > 
> > To:
> > 
> > "EAP does not support cleartext password authentication.
> 
> I don't think this is an "EAP support" issue. This is just a 
> matter of defining an "EAP method". Unless we explicitly 
> forbid design of such a method, we should remove the above 
> statement. I don't think this is for EAP specification to 
> decide. [I understand why it's a bad idea to have cleartext 
> passwords, but the above statement is confusing the role of 
> EAP, EAP methods, etc.]
> 
> > This
> > omission is intentional.  Use of cleartext passwords would 
> allow the 
> > password to be captured by an attacker with access to the link.
> > 
> > Since protocols encapsulating EAP, such as RADIUS 
> [RFC3579], may not 
> > provide confidentiality, EAP frames may be subsequently 
> encapsulated 
> > for transport over the Internet where they may be captured by an 
> > attacker."
> > 
> 
> Thanks.
> 
> Alper
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>