eap Mailing List: RE: Issue 208: Physical Security

[Joseph Salowey (jsalowey]

The modifications look good.

Thanks,

Joe

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba [at] internaut.com] 
> Sent: Tuesday, December 23, 2003 6:28 PM
> To: Joseph Salowey
> Cc: eap [at] frascone.com
> Subject: RE: [eap] Issue 208: Physical Security
> 
> 
> > [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.
> 
> I agree.  In looking at the Security Considerations section 
> 7, it occurs to me that the role of this section is really 
> just to outline potential threats as well as the security 
> claims that address these threats.  Just as the IPsec 
> documents do not specify when ESP/AH are to be used, or even 
> when IKE is required for dynamic keying, it seems 
> inappropriate to me for RFC 2248bis to attempt to prescribe 
> what kinds of EAP methods are appropriate for use in each situation.
> 
> At IETF 56, Erik Nordmark talked about future documents which 
> will provide that kind of guidance, and requested that IEEE 
> 802.11i provide such a document for publication as an 
> Informational RFC, based on the liason letter of March 2003. 
> I think it is worth making it clear in the Section 7 that we 
> are relying on those future documents and therefore do not 
> need to provide guidance on those requirements within RFC 2284bis.
> 
> Otherwise, it seems likely that we could become bogged down 
> in a never-ending applicability discussion.
> 
> Here is my proposed resolution of Issue 208, taking this into account:
> 
> In Section 3.1, change:
> 
> " [3] Lower layer security. EAP assumes that lower layers 
> either provide physical security (e.g., wired PPP or IEEE 802 
> links) or support per-packet authentication, integrity and 
> replay protection. EAP SHOULD NOT be used on physically 
> insecure links (e.g., wireless or the Internet) where 
> subsequent data is not protected by per-packet 
> authentication, integrity and replay protection."
> 
> To:
> 
> " [3] Lower layer security. EAP does not require
> lower layers to provide security services such as
> per-packet confidentiality, authentication, integrity and 
> replay protection. However, where these security services are 
> available, EAP methods supporting Key Derivation (see Section 
> 7.2.1) can be used to provide dynamic keying material. This 
> makes it possible to bind the EAP authentication to 
> subsequent data and protect against security threats such as 
> data modification, spoofing, or replay (see Section 7.1 for details)."
> 
> 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. 
> It is desirable to provide assurance that the entities 
> transmitting data are the same ones that successfully 
> completed EAP authentication. To accomplish this, it is 
> necessary for the lower layer to provide per-packet 
> integrity, authentication and replay protection and to bind 
> these per-packet services to the keys derived during EAP 
> authentication. Otherwise it is possible for subsequent data 
> traffic to be hijacked or replayed."
> 
> In Section 5.1, change:
> 
> "Identity Requests and Responses are not protected, so
> from a privacy perspective it is preferable for an EAP method 
> to include its own protected identity exchange."
> 
> To:
> 
> "Identity Requests and Responses are sent in cleartext, so
> from a privacy perspective it is preferable for an EAP method 
> to include an identity exchange that supports authentication, 
> integrity and replay protection and confidentiality."
> 
> Change Section 7 to:
> 
> "7. Security Considerations
> 
> This section defines a generic threat model and security 
> terms and describes the security claims section required in 
> EAP method specifications.
> 
> Since the specific threats applicable to a given environment 
> may differ, this section only attempts to provide a general 
> outline of potential threats and the corresponding EAP method 
> security claims mitigating those threats.
> 
> It is expected that the generic threat model and 
> corresponding security claims will used to define EAP method 
> requirements for use in specific environments. An example of 
> such a requirements analysis is provided in [IEEE80211iReq]."
> 
> Add as an informative reference:
> 
> "[IEEE80211iReq]
> Kerry, S., "Input the IETF EAP Working Group on Methods and 
> Key Strength", IEEE 802.11 liason letter, 
> http://www.ietf.org/IESG/LIAISON/LS-ieee-80211.txt, March 2003."
> 
> In Section 7.1, change:
> 
> "On physically insecure networks, it is possible for an 
> attacker to gain access to the physical medium. This enables 
> a range of attacks, including the following:"
> 
> To:
> 
> "EAP was developed for use with dialup PPP [RFC1661] and was 
> later adapted for use in wired IEEE 802 networks [IEEE-802] 
> in [IEEE-802.1X]. Subsequently EAP has been proposed for use 
> on wireless LAN networks, and over the Internet. In all these 
> situations it is possible for an attacker to gain access to 
> the link. For example, attacks on telephone infrastructure 
> are documented in [DECEPTION].
> 
> An attacker with access to the link may carry out a number of 
> attacks, including:"
> 
> In Section 7.1, change:
> 
> "Where EAP is used over wired networks, an attacker typically 
> requires access to the physical infrastructure in order to 
> carry out these attacks. However, where EAP is used over 
> wireless networks, EAP packets may be forwarded by 
> authenticators (e.g., pre-authentication) so that the 
> attacker need not be within the coverage area of an 
> authenticator in order to carry out an attack on it or its 
> peers. Where EAP is used over the Internet, attacks may be 
> carried out at an even greater distance."
> 
> To:
> 
> "Depending on the lower layer, these attacks may be carried 
> out without requiring physical proximity. where EAP is used 
> over wireless networks, EAP packets may be forwarded by 
> authenticators (e.g., pre-authentication) so that the 
> attacker need not be within the coverage area of an 
> authenticator in order to carry out an attack on it or its 
> peers. Where EAP is used over the Internet, attacks may be 
> carried out at an even greater distance."
> 
> In Section 7.2, delete:
> 
> "[a] Intended use. This includes a statement of whether the 
> method is intended for use over a physically secure or 
> insecure network, as well as a statement of the applicable 
> lower layers."
> 
> In Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 delete the 
> Intended Use claim.
> 
> In Section 7.5, change:
> 
> "In the case of PPP and IEEE 802 wired links, it is assumed 
> that such attacks are restricted to attackers who can gain 
> access to the physical link. However, where EAP is run over 
> physically insecure lower layers such as wireless (802.11 or 
> cellular) or the Internet (such as within protocols 
> supporting PPP, EAP or Ethernet Tunneling), this assumption 
> is no longer valid and the vulnerability to attack is greater.
> 
> To protect EAP messages sent over physically insecure lower 
> layers, methods providing mutual authentication and key 
> derivation, as well as per-packet origin authentication, 
> integrity and replay protection SHOULD be used."
> 
> To:
> 
> "To protect EAP messages against modification or spoofing, 
> methods supporting protected ciphersuite negotiation, mutual 
> authentication and key derivation as well as integrity and 
> replay protection are recommended. See Section 7.2.1 for 
> definition of these security claims."
> 
> In Section 7.6, change:
> 
> "In order to protect against dictionary attacks, 
> authentication algorithms resistant to dictionary attack (as 
> defined in Section 7.2) SHOULD be used where EAP runs over 
> lower layers which are not physically secure."
> 
> To:
> 
> "In order to protect against dictionary attacks, 
> authentication methods resistant to dictionary attacks (as 
> defined in Section 7.2.1) are recommended."
> 
> In Section 7.7, change:
> 
> "With EAP methods supporting one-way authentication, such as 
> EAP-MD5, the peer does not authenticate the authenticator. 
> Where the lower layer is not physically secure (such as where 
> EAP runs over wireless media or the Internet), the peer is 
> vulnerable to a rogue authenticator. As a result, where the 
> lower layer is not physically secure, a method supporting 
> mutual authentication is RECOMMENDED."
> 
> To:
> 
> "With EAP methods supporting one-way authentication, such as 
> EAP-MD5, the peer does not authenticate the authenticator, 
> making the peer vulnerable to attack by a rogue 
> authenticator. Methods supporting mutual authentication (as 
> defined in Section 7.2.1) address this vulnerability."
> 
> In Section 7.11, change:
> 
> "As a result, as noted in Section 3.1, where EAP is used over 
> a physically insecure lower layer, per-packet authentication, 
> integrity and replay protection SHOULD be used, and 
> per-packet confidentiality is also recommended."
> 
> To:
> 
> "To protect against modification or snooping of data, it is 
> recommended that EAP methods supporting mutual 
> authentication, and key derivation (as defined by Section 
> 7.2.1) be used, along with a lower layers providing 
> per-packet confidentiality, authentication, integrity and 
> replay protection. "
> 
> Change Section 7.12 to:
> 
> "There are reliability and security issues with link
> layer indications in PPP, IEEE 802 LANs and IEEE 802.11 wireless LANs:
> 
> [a] PPP. In PPP, link layer indications such as LCP-Terminate 
> (a link failure indication) and NCP (a link success 
> indication) are not authenticated or integrity protected. 
> They can therefore be spoofed by an attacker with access to the link.
> 
> [b] IEEE 802. IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames 
> are not authenticated or integrity protected. They can 
> therefore be spoofed by an attacker with access to the link.
> 
> [c] IEEE 802.11. In IEEE 802.11, link layer
> indications include Disassociate and Deauthenticate frames 
> (link failure indications), and the first message of the 
> 4-way handshake (link success indication). These messages are 
> not authenticated or integrity protected, and although they 
> are not forwardable, they are spoofable by an attacker within range.
> 
> In IEEE 802.11, IEEE 802.1X data frames may be sent as Class 
> 3 unicast data frames, and are therefore forwardable. This 
> implies that while EAPOL-Start and EAPOL-Logoff messages may 
> be authenticated and integrity protected, they can be spoofed 
> by an authenticated attacker far from the target when 
> "pre-authentication" is enabled.
> 
> In IEEE 802.11 a "link down" indication is an unreliable 
> indication of link failure, since wireless signal strength 
> can come and go and may be influenced by radio frequency 
> interference generated by an attacker. To avoid unnecessary 
> resets, it is advisable to damp these indications, rather 
> than passing them directly to the EAP. Since EAP supports 
> retransmission, it is robust against transient connectivity losses."
> 
> 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 lower 
> layer lower layer security services such as per-packet 
> confidentiality, authentication, integrity and replay 
> protection will be enabled, a secure association protocol 
> SHOULD be run between the peer and authenticator in order to 
> provide mutual authentication between the peer and 
> authenticator; guarantee liveness of transient session keys; 
> provide protected ciphersuite and capabilities negotiation 
> for subsequent data; and synchronize key usage."
> 
> 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. 
> 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."
>