From: Bernard Aboba Subject: [Privacy-program] EAP privacy (and privacy issues arising from SAVI). Date: June 14, 2011 7:23:40 PM GMT+01:00 To: privacy-program@iab.org The privacy issues discussed in this review overlap with a number of issues encountered in EAP identity privacy. In an EAP network authentication, there are a number of relevant identifiers: 1. The MAC address of the user. 2. The IP address of the user, typically assigned after the EAP exchange has completed. 3. The EAP network access identifier (NAI) used in the EAP-Response/Identity exchange. The NAI is defined in RFC 4282. 4. The EAP NAI used within the (potentially protected) EAP method exchange 5. Network Access Server (NAS) identifiers carried by the AAA protocol. There include: NAS-Identifier, NAS-IPv4-Address (RFC 2865), NAS-IPv6-Address (RFC 3162) and Called-Station-Id (RFC 2865, 3580). In addition to identifying the NAS, these attributes can be used to infer the user's location. 6. User identifiers carried by the AAA protocol. These include the following attributes: User-Name (RFC 2865), Calling-Station-Id (RFC 3580) EAP-Message attribute (RFC 3579), Chargeable User Identity (RFC 4372). Initially, the EAP privacy discussion focused on the threat posed by an attacker snooping on an EAP exchange to obtain the user identity included in the EAP-Response/Identity exchange. This was considered largely a security threat in that knowledge of the user name could enable an attacker to more easily mount an attack to recover the password of that user. Other privacy threats such as the exposure of data from the AAA exchange (which in the case of RADIUS, occurs in the clear) were not included in the discussion, nor was a comprehensive threat model developed. The EAP Identity exchange occurs in the clear since it is used to route the EAP packets to the AAA server prior to initiation of the EAP exchange which derives keys which can subsequently be used to encrypt the link. The EAP methods defined in RFC 3748 did not provide for EAP-method specific identities nor did they derive keys, so the EAP-Response/Identity was the only identity available to those methods. While EAP-TLS (RFC 2716) did derive keys, it did not provide for encryption of the TLS client certificate, and thus an attacker could obtain the user identity from the client certificate. RFC 5716 subsequently enabled encryption of the client certificate exchange. Since the EAP-Response/Identity is used to route the EAP exchange to the appropriate AAA server cannot be encrypted, it is not possible to provide complete anonymity -- unless the exchange utilizes a local AAA server, a domain name must be provided. Methods such as EAP-TTLSv0 (RFC 5281) enabled an "anonymous NAI" of the form "anonymous@example.com" or "anonymous" to be sent within the EAP-Response/Identity. The EAP server would then initiate an EAP method chosen by the administrator, in which the method-specific identity would be provided via an encrypted tunnel from the user to the EAP server. In such an exchange, an attacker snooping on the EAP exchange, while still potentially learning the user domain, would not know the user name, but the administrator of the AAA server would have all the information that would normally be obtained from the NAS and user (e.g. user as well as NAS information) . Note that in this model, not only would an attacker snooping the user not learn the user name, but the network operator would also not learn it. This created a potential issue for billing, because the accounting records submitted by the network operator would no longer identify the user-name initiating the session. Some existing solutions were considered. Permanent identifiers (such as Calling-Station-Id, which could contain the MAC address or originating telephone number) could still be included in accounting records, so that the network operator would still have some ability to track the user. While the AAA server could potentially pass the Class or User-Name attributes in an Access-Accept for inclusion in the accounting record this would provide user identity to the network operator. The Chargeable User Identity (RFC 4372) developed to provide information in the accounting record so that the AAA server could correlate the network operator-provided accounting info with its own records. Given the presence of permanent identifiers in user-NAS exchanges (e.g. MAC address) as well as in AAA exchanges (e.g. Calling-Station-Id), in addition to NAS identifiers akin to location data, the discussion of EAP privacy was not the last word on the issue. Subsequently in IEEE 802.11 there was discussion of issues such as "temporary" MAC addresses and MAC address spoofing. Note that in IEEE 801.11i, there is no protection against MAC address spoofing, merely binding of keys to MAC addresses. Thus an attacker can spoof a MAC address and potentially disrupt network access for another user. Subsequently IEEE 802.1ar developed a mechanism to allow proof of MAC address ownership via a certificate and EAP-TLS exchange, and such an identity certificate approach (with EAP-TLS authentication) was also used in WiMAX on network entry. The carriage of location info in clear text also became an issue of concern when it became understood that an attacker snooping on RADIUS authentication or accounting packets could obtain user location in realtime, given the wiremap data to convert NAS identifiers to location. This lead to proposals for encryption of AAA traffic (e.g. Diameter over TLS/IPsec, RADIUS over IPsec as defined in RFC 3579, RADIUS over DTLS, RADIUS over TLS, etc.). Of course, merely encrypting the traffic is not sufficient if the data itself were not protected; therefore interest also developed in storage of log data on encrypted file systems. Note that this data is often kept for substantial periods (e.g. 7 years) due to financial and other requirements. Lessons from EAP privacy 1. At no point during the EAP privacy debate was a privacy threat model developed, describing the entire system (EAP, AAA, link layer) and the threats from various entities (e.g. attacker snooping the NAS exchange, attacker snooping the AAA exchange, network operator, administrator, etc. Instead the debate occurred on a piecemeal basis across multiple documents and WGs. 2. Due to the piecemeal nature of the discussion, introduction of partial anonymity in one part of the system (e.g. user-NAS communications) resulted in issues arising for other actors (e.g. network providers, administrators). 3. The term "privacy" was never defined, nor were the goals laid out. Indeed the initial concerns seemed to be more about security than privacy, and subsequent arguments more about billing assurance than privacy. 4. Although regulatory requirements eventually loomed large in the debate, these were never referenced in any of the documents, or even comprehensively discussed. As a result, there were arguments within the IETF as well as IEEE 802 about what those requirements were real or imagined that were never put to rest (e.g. is a MAC address considered PII, and if so, in what countries? What other things in the EAP/AAA system are considered PII?). 5. The lack of a definition of privacy or goals lead to somewhat odd design decisions that were not fully justified or even discussed. This included things like leaving permanent identifiers (MAC addresses) while focusing on ephemeral user names. 6. The use of EAP and AAA data in other contexts has continued to grow. For example, this data is a very popular source of location info as provided in location configuration protocols (e.g. HELD, DHCP). It is also commonly used in response to security incidents (e.g. denying access to infected machines, detection of spoofing or bot infection, etc.). An example of where AAA privacy issues have arisen again is given below. > From: rbarnes@bbn.com > Subject: privacydir review of draft-ietf-savi-threat-scope > Date: Tue, 14 Jun 2011 12:49:33 -0400 > To: draft-ietf-savi-threat-scope@tools.ietf.org; savi-chairs@tools.ietf.org; privacydir@ietf.org; iesg@ietf.org > > Do not be alarmed. I have reviewed this document as part of the privacy directorate's ongoing effort to some IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other review comments. > > This document attempts to scope the threats that the SAVI mechanisms are intended to counter, and describe some potential approaches to countermeasures. While the document is quite thorough in its descriptions of spoofing problems and concerns related to network architecture, it reads more as a primer on spoofing and anti-spoofing than a set of constraints for a working group. This expanded focus leaves the document with at least some serious problems: > (1) It fails to scope the SAVI problem tightly enough, leaving the door open to potentially privacy-risky designs, > (2) It does not address some solution approaches that would be more privacy-friendly. > (3) It conflates anti-spoofing with attack mitigation/forensics, a much more privacy-risky activity > > > 1. > > With regard to scoping: The document discusses several points in the network architecture (Figure 1) where anti-spoofing measures can be enforced, but it never states clearly at which points the SAVI mechanism is intended to be applied. Given the considerations discussed in the document (and indeed the SAVI charter), it seems clear that there are sufficient mechanisms (BCP 38 and uRPF) for use at the various inter-network interfaces and, by extension, to links between subnets within a network. > > Thus, the document should clearly state that SAVI is limited to spoofing within a local layer-2 network, before it reaches a router. The closest the current version comes to this is the statement in Section 4.2.3 that "Much of the work of SAVI is initially targeting minimizing source address spoofing in the LAN." This statement should be tightened (e.g., by removing "Much" and "initially") and made more prominent as a constraint for the SAVI solution. > > This constraint is important from a privacy perspective because of the risk that SAVI solutions will increase the propagation of potentially private host identity information (e.g., the MAC-IP bindings prevented by RFC 4941). > > Another ambiguity that raises privacy concerns is the document's discussion of binding anchors. The document uses the phrase "binding anchor" without definition. Another SAVI document (draft-ietf-savi-framework, which is not referenced) defines a binding anchor as a "link layer property of the host's network attachment ... [which] must be verifiable in every packet that the host sends, and harder to spoof than the host's IP source address itself". > > This documents suggests that network authentication credentials, e.g., those used for 802.1X, could be suitable binding anchors. This proposal clearly contradicts the cited definition for binding anchors, since these credentials are not verifiable in packets. The use of such credentials outside of their role in AAA systems clearly creates privacy risks by increasing the exposure of what is often personally-identifying information. > > > 2. > > All of the attacks listed in Section 3 rely on a host accepting and processing spoofed packets, as opposed to spoofed packets being used to overwhelm some network-internal resources. This property would seem to indicate that the real goal for SAVI is the following: A host must not accept packets from other hosts on the same local network unless the source host has been properly assigned that address. > > Viewed from this perspective, SAVI should essentially constitute a mechanism for adding assurance to ARP/ND caches, e.g., by allowing hosts to receive information about address bindings either from each other or from an authoritative source such as a router on the link. By basing the solution at end hosts, where the information being assured already resides, the solution could avoid the privacy concern that the current network-based approaches raise. Namely, network-based solutions leak information cached in the local network into other parts of the network control plane, increasing the risk that it will be further exposed. > > > 3. > > The document mentions several times the need for greater traceability in support of attack forensics, i.e., for mechanisms that allow network administrators to identify the source of an attack. These requirements should be removed, because they are out of scope and create privacy risks. > > Anti-spoofing mechanisms are a limited subset of traceability mechanisms. They support attack mitigation/forensics by ensuring that the view of the network from DHCP lease tables and ND caches is correct. More general traceability mechanisms can involve binding addresses to other data like network access credentials and user identifiers. These data are not required for anti-spoofing, and are clearly much more privacy-sensitive than the layer-2 information used for anti-spoofing. > > > > > > > > > _______________________________________________ Privacy-program mailing list Privacy-program@iab.org https://www.iab.org/mailman/listinfo/privacy-program