eap Mailing List: Re: Issue 208: Physical Security

[Alper Yegin (alper]

> 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.

> 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