Network Working Group R. Marin Lopez(Ed.) Internet-Draft Y. Ohba Expires: August 28, 2006 TARI J. Bournelle GET/INT February 24, 2006 PANA bootstrapping IEEE 802.11 security draft-marin-pana-ieee80211doti-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract PANA (Protocol for carrying Authentication for Network Access) is a link-layer agnostic transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. PANA framework defines two types of security associations which can Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 1] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 be bootstrapped as a consequence of PANA execution: IP layer security is established with IPsec by using IKE and link-layer security with WPA/IEEE 802.11i in PSK mode. This document is focused on how PANA can bootstrap link layer security through IEEE 802.11i and exposes issues which can be raised as a consequence of this interaction. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. 802.11i Overview . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. RSNA Architecture . . . . . . . . . . . . . . . . . . . . 6 4.2. 802.11i phases . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Security Capabilities Discovery . . . . . . . . . . . 6 4.2.2. Authentication . . . . . . . . . . . . . . . . . . . . 7 4.2.3. Key Management . . . . . . . . . . . . . . . . . . . . 7 4.2.4. Data protection . . . . . . . . . . . . . . . . . . . 7 5. PANA bootstrapping 802.11i . . . . . . . . . . . . . . . . . . 8 5.1. Case 1:PANA over IEEE 802.1X Uncontrolled Port . . . . . . 8 5.2. Case 2:PANA over non-RSN Access Point . . . . . . . . . . 9 6. Capability Discovery Issue . . . . . . . . . . . . . . . . . . 11 6.1. Capability Discovery problem description . . . . . . . . . 11 6.2. Announcing PANA bootstrapped Access Points . . . . . . . . 12 7. Pre-Shared Key (PSK) Derivation . . . . . . . . . . . . . . . 13 8. PANA-assisted IEEE 802.11i pre-authentication . . . . . . . . 14 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.2. Key Installation . . . . . . . . . . . . . . . . . . . . . 15 9. Implementation Considerations . . . . . . . . . . . . . . . . 16 9.1. PANA Agent . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Access Point . . . . . . . . . . . . . . . . . . . . . . . 17 9.3. PaC and IEEE 802.11i Supplicant . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11.1. PANA over 802.1X Uncontrolled Port . . . . . . . . . . . . 20 11.2. PSK Installation . . . . . . . . . . . . . . . . . . . . . 20 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 13.1. Normative References . . . . . . . . . . . . . . . . . . . 22 13.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 2] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 3] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 2. Introduction PANA (Protocol for carrying Authentication for Network Access)[I- D.ietf-pana-pana] is a link-layer agnostic transport for Extensible Authentication Protocol (EAP) [RFC3748] to enable network access authentication between clients and access networks. PANA is run between two entities, the PANA client (PaC) which asks for network access and PANA agent (PAA) which acts as authenticator. Note that PAA can interact with a backend authentication server to carry out authentication process. Upon successful authentication a PANA security association can be established between PaC and PAA. Additionally and thanks to a key generated during authentication process (MSK), PANA allows to bootstrap a security association between client (PaC) and one (or several) access device (Enforcement Point) which enforces network access control (e.g. an access router or an access point). The PANA framework document [I-D.ietf-pana-framework] defines two types of security associations that can be bootstrapped as a consequence of PANA execution. IP layer security which is established with IPsec by using IKE and link layer security with WPA/ IEEE 802.11i which is established by using the PSK mode. Note that PANA bootstrapping IP security is already defined in [I-D.ietf-pana- ipsec]. This document specifies how PANA can bootstrap link-layer security through IEEE 802.11i and exposes issues which can be raised as a consequence of this interaction. Figure 1 summarizes scenarios 1,2 and 4 in [RFC4058] considered in this document. Note that PAA can be located several IP hops away from AP/EP. +-----+ |AP/EP|----+ +-----+ | +---+ +-----+ | /===========\ +-----+ |PaC| |AP/EP|----+--|IP network |---| PAA | +---+ +-----+ | \===========/ +-----+ +-----+ | |AP/EP|----+ +-----+ Figure 1: PANA Model for IEEE802.11i Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 4] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 3. Terminology Enforcement Point (EP). A node on the access network where per- packet enforcement policies (i.e., filters) are applied on the inbound and outbound traffic of access devices. Pairwise Master Key (PMK). Key used as root key in IEEE 802.11i. It can be obtained after EAP authentication or it acquires PSK's value. PANA Protocol for Carrying Network Authentication for Network Access PANA Client (PaC). A mobile node (MN) using a PANA protocol implementation to authenticate itself to the network. In the document this mobile node will also be called non-AP station (non-AP STA) or supplicant to follow IEEE 802.11i terminology. PANA Authentication Agent (PAA). The protocol entity in the access network whose responsibility is to verify the credentials provided by a PANA client (PaC) and authorize network access. Pre-Shared Key (PSK). The IEEE 802.11i protocol specifies that a pre shared key can be owned by supplicant and authenticator and used as PMK. RSN Robust Security Network. RSN Information Element (RSN IE). Robust Security Network Information Element. For additional information and terminology please refer to [I-D.ietf- pana-pana] and [802.11i]. Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 5] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 4. 802.11i Overview The 802.11i [802.11i] is based on 802.1X [802.1X] for the authentication and the notion of controlled and uncontrolled port and on 802.11 functions to protect data frames. It defines the notion of RSNA which stands for Robust Security Network Association. As such, in an RSNA, all non-AP stations (non-AP STAs) utilizes 802.1X to access services. After the authentication phase, 802.11i uses the 4-way handshake mechanism to establish cryptographic key and negotiation of protocols to protect layer 2 frames. CCMP and TKIP are examples of those protocols and can be used for this purpose. In this document, Independent Basic Service Set (IBSS) is not considered since we consider that all non-AP STAs are associated with access points. 4.1. RSNA Architecture A RSNA relies on 802.1X port access entity (PAE). The access point (AP) is a PAE which implement the EAP authenticator role. It may rely on an Authentication Server where EAP server is co-located. On the other hand, the non-AP STA always implements the supplicant PAE role and thus is an EAP client. In RSNA, the 802.1X port determines if a data traffic is allowed on a 802.11 link. A port is composed by a controlled port and an uncontrolled port. The controlled port blocks general data traffic until the authentication procedure (based on 802.1X) completes successfully. 4.2. 802.11i phases The 802.11i process can be divided in 4 phases: Security Capabilities Discovery, Authentication, Key Management and Data protection. 4.2.1. Security Capabilities Discovery The discovery phase permits for STAs to learn security capabilities of the AP. For this purpose, the AP advertises in Beacon and Probe Response its SSID (which may help the non-AP STA to provide right credentials) and its RSN Information Elements (RSN IE). RSN IE contains enabled authentication suites, enabled unicast and multicast suites. After receiving RSN IE, the non-AP STA enters the Authentication Phase and sets it to Open System Authentication. This is for compatibility with 802.11. Then it sends an Association Request containing RSN IE chosen. If security parameters are correctly negotiated, the AP replies with an Association Response with a Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 6] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 Success. At this time, the non-AP STA knows the SSID, the authentication and cipher suites used in the network. The non-AP STA and AP have established a 802.11 channel and they can start authentication. 4.2.2. Authentication Two authentication mechanisms are possible in 802.11i: either 802.1X or pre-shared key (also named PSK mode). In PSK mode, the pre-shared key is directly used as a PMK for the 4-way handshake. The STA and the AP must be provided with this key. With 802.1X/EAP, the AP acts as an EAP authenticator. EAP server can be co-located in the AP or in a AAA server. In the second case a AAA protocol such as RADIUS [RFC2865] is used between AP and AAA server. The non-AP STA and the AP uses the uncontrolled port for 802.1X. At the end of the 802.1X protocol, the non-AP STA and the AP share a key called PMK (Pairwise Master Key). 4.2.3. Key Management During this phase, the non-AP STA and the AP uses the 4-way handshake to derive a fresh Pairwise Transient Key (PTK). The AP uses the KCK and KEK portions of PTK to distribute the GTK (Group Transient Key). 4.2.4. Data protection The non-AP STA has been successfully authenticated and shares a fresh derived key with the AP. The 802.11i specifies two protocols in order to secure general data traffic: CCMP and TKIP. Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 7] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 5. PANA bootstrapping 802.11i This section describes two cases to bootstrap link-layer security in IEEE 802.11i Access Points. Note that proposed alternatives can be used in physical Access Points and Virtual Access Point (VAP).A Virtual Access Point (see [aboba-vap-2003]) is a logical entity which exits within a physical Access Point(AP). A physical AP can support several Virtual Access Points. Each Virtual Access Point(VAP) might advertise either different SSID and capability set or same SSID with different capability set. In general terms, Virtual Access Points can be seen as totally independent APs. That is, with different capabilities, SSID, MAC addresses, IP addresses, AAA clients configuration and connected to different VLANs. Thus, from this point, Access Point(AP) term is used to refer to both Virtual Access Point and physical Access Point. 5.1. Case 1:PANA over IEEE 802.1X Uncontrolled Port [I-D.ietf-pana-framework] describes how PANA can bootstrap WPA/IEEE 802.11i security when PANA is processed by IEEE 802.1X Uncontrolled Port. Note that [802.11i] does not prohibit that higher-layer data traffic to be received and processed on the IEEE 802.1X Uncontrolled Ports. This feature allows processing certain restricted IP-based traffic (such as ARP, IPv6 neighbour discovery, DHCP, and PANA) on IEEE 802.1X Uncontrolled Port prior to client authentication. If AP implements this feature, a set of steps needed for PANA to bootstrap WPA/IEEE 802.11i security are described in [I-D.ietf-pana- framework]. For informative purposes, these steps are described following: 1. The PaC associates with the AP. 2. The PaC configures a Pre-PANA Address (PRPA) by using a method defined in [I-D.ietf-pana-framework] and then runs PANA (over Uncontrolled Port) 3. Upon successful authentication, the PaC obtains a separate PSK for each AP controlled by the PAA as well as the information on the available Post-PANA Address (POPA) configuration methods. 4. The AP initiates IEEE 802.11i 4-way handshake to establish a PTK (Pair-wise Transient Key) with the PaC, by using the PSK (Controlled Port is set to Authorized state). 5. The PaC obtains a POPA when necessary using one of the available POPA configuration methods(over Controlled Port). Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 8] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 5.2. Case 2:PANA over non-RSN Access Point One Wireless IP provider may require a PANA authentication to bootstrap link-layer security for a set of Access Points which do not allow PANA over IEEE 802.1X Uncontrolled Port. To do that, at least one additional AP is needed which is connected to an unauthenticated VLAN meanwhile others are connected an authenticated VLAN. The former and latter AP(s) are referred to unauthenticated AP and authenticated AP(s), respectively. If a PaC does not have a PSK with one authenticated AP, it runs PANA on the unauthenticated AP to obtain the MAC address of the authenticated AP(s) and derives the PSK valid for the AP(s). Once the PSK is obtained, the PaC associates with the authenticated AP with performing 4-way handshake. It configures a (potentially new) post-PANA IP address and starts sending and receiving data traffic. Future PANA exchanges are carried on the IEEE 802.1X Controlled Port of the authenticated AP just like any other data traffic. +--------------+ |non-RSN AP1 | Unauthenticated |(open-access) |---- VLAN \ | | \+-------+ +---+ +--------------+ |PAA/AR/| |PaC| |DHCP |--- Internet +---+ +--------------+ |Server | | RSN AP2 | /+-------+ |(WPA PSK mode)|---- Authenticated / | | VLAN +--------------+ Figure 2: PANA over non-RSN AP Specifically, when a PaC does not have a PSK with an authenticated AP, the following procedure is taken: 1. The PaC associates with the unauthenticated AP. 2. The PaC configures a PRPA through some mechanism(i.e., DHCP or Neighbour Discovery) and then runs PANA by using the address. 3. Upon successful authentication, the PaC obtains a distinct PSK for each authenticated VAP controlled by the PAA. 4. Then, the PaC associates with an authenticated VAP, with performing 4-way handshake to establish a PTK (Pair-wise Transient Key) between the PaC and authenticated VAP, by using Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 9] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 the dynamically generated PSK. 5. If the PaC is required to configure a new IP address (POPA) as signalled by the PAA at the end of successful authentication, it should configure POPA by using any proposed method by PAA. Note that, typically, unauthenticated AP will be connected to a different IP network than authenticated AP(s). Thus, PRPA will no longer valid in the authenticated AP and PaC will need to carry out PANA-Update-Request(PUR)/PANA-Update-Answer(PUA) exchange to update the new IP address(POPA) configured through authenticated AP. Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 10] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 6. Capability Discovery Issue 6.1. Capability Discovery problem description PANA framework explains in section 10.2.3 how a PaC can discover an AP supporting PSK bootstrapped by PANA. This is known as Capability Discovery problem. However it only describes the problem in terms of the Case 1, that is, PANA is run over Uncontrolled Port (see Section 5.1). To analyze this problem, [I-D.ietf-pana-framework] considers next classification: a) AP without IEEE 802.11i: There is no IEEE 802.11i link-layer security on this AP b) AP with IEEE 802.11i using PSK mode bootstrapped from PANA: The clients are required to perform PANA authentication which allows the PaC to bootstrap a dynamic PSK to access this AP. c) AP with IEEE 802.11i using native PSK mode: AP and PaC must share a statically configured PSK to access this AP. d) AP with IEEE 802.11i using 802.1X/EAP mode: The clients are required to perform IEEE 802.1X/EAP authentication for this AP. As PANA framework describes, PaC may not distinguish between a Type b) and a Type c) AP because in both cases RSN IE announces PSK mode is requested to access to the network. Thus, PaC does not directly know from this information whether it can use PANA or not to bootstrap a PSK. To discover that, PANA framework describes a default mechanism which consists on PaC tries to associate with the AP. If either the PaC receives a disassociation frame or AP immediately starts 4-way handshake after association, PaC can consider network as Type (c). Otherwise the network is Type (b). This mechanism is applied when AP allows restricted IP traffic over Uncontrolled Port(Case 1). However considering that another way to bootstrap PSK by PANA is possible (Case 2), it is needed to generalize the Capability Discovery mechanism described in [I-D.ietf- pana-framework] Thus, for convenience, Type b) AP is now partitioned into Type b1) and Type b2) where b1) supports Case 1 and b2) supports Case 2. Type b1), b2) and c) are indistinguishable from Beacon/Probe Response frame. On one hand, if PaC is associated with AP and does not receive the first 4-way handshake message, it is Type b1). However if 4-way handshake starts, it is Type c). On the other hand, if the Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 11] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 PaC is immediately disassociated then AP is Type b2) or Type c). To distinguish between them, the PaC needs to associate with an another (open access) AP and to run PANA to obtain the list of EPs of Type b2). Whether there is no answer from PAA or PANA is run but no link- layer security is required, AP was Type c). 6.2. Announcing PANA bootstrapped Access Points As it has been explained in Section 6, PaC may not distinguish between different types of APs (a PSK is statically configured or PANA can be used to bootstrap PSK). This leads PaC to associate to that AP and, in some cases, to try to get an IP address and run PANA to discover it. However this mechanism is costly in terms on time which is critic when PaC is a mobile. Thus it would be beneficial to have some mechanism to indicate the PaC that the AP can be accessed through a PSK bootstrapped by PANA. Such an indication may carry information as to whether the AP allows to bootstrap link-layer security by using PANA (Type b) or more specific information as to whether it can be done through IEEE 802.1X Uncontrolled Port (Type b1) or through an open AP (Type b2) Several ways might be used for achieving this objective. For example by adding a new value in Authentication and Key Management (AKM) Suite Selector included in RSN IE. Currently, the IEEE 802.11i defines PSK and 802.1X/EAP modes. This new value would inform to PaC that AP supports a new mode where PANA can be run over IEEE 802.1X Uncontrolled Port (Type b1). Alternatively, IEEE 802.11u (see [802.11u]) or some external information service might also be used for discovering both Type b1 and/or Type b2. Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 12] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 7. Pre-Shared Key (PSK) Derivation If PANA is used to bootstrap IEEE 802.11i security, a PSK must be installed in the AP(EP) right after the PANA authentication. In PSK mode,[802.11i] establishes that PSK acts as PMK in the 4-way handshake and therefore PSK must be 32 bytes length. On the other hand, PaC-EP-Master-Key is the key to be used by a secure association protocol for bootstrapping link-layer or IP layer security between the PaC and EP In terms of this document, the PaC-EP-Master-Key can be used to create PSK. In particular, PaC-EP-Master-Key generated during PANA authentication has a length of 64 bytes. Thus it is needed to truncate PaC-EP-Master-Key to obtain a PSK: PSK = The first 32 bytes of PaC-EP-Master-Key Each EAP re-authentication generates a new AAA-Key. As a consequence a new PaC-EP-Master-Key is generated and thus PSK also changes. The [I-D.ietf-eap-keying] document requires that all keys derived from AAA-key to be deleted when the AAA-key expires thus the new PSK must replace the old one. When new PSK is installed in the AP 4-way handshake MUST be run immediately. Since the PSK is dynamically bootstrapped from AAA-Key instead of statically configured, a lifetime is associated to the PSK. [I-D.ietf-pana-pana] specifies that the lifetime of PaC-EP-Master-Key (and thus PSK) is bounded by the lifetime of the PANA SA. In turn, the PANA SA lifetime is bounded by the AAA-Key lifetime. In conclusion, PSK lifetime is bounded to AAA-Key lifetime. Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 13] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 8. PANA-assisted IEEE 802.11i pre-authentication 8.1. Overview One limitation in IEEE 802.11i pre-authentication is that it only works when APs are connected to the same distribution system (DS). As a consequence, pre-authentication between APs which belong to different administrative domains is not possible. Another limitation in IEEE 802.11i pre-authentication is that this mechanism involves a full EAP authentication with each candidate AP. It implies very much signalling each time STA moves and thus increases time that PaC has to be associated to the current AP before to do the handover to the candidate AP.(Note that IEEE 802.11r [802.11r] specification already introduces a change to avoid this problem defining a new key hierarchy and where EAP authentications in each movement are not needed). To overcome these limitations, this section describes a mechanism of IEEE 802.11i pre-authentication assisted by PANA. In fact [I-D.ietf- pana-preauth] describes how PANA can be used by a PaC to establish a PANA security association (pre-authentication SA) with other PAA (Preparing PAA) meanwhile it has another PANA SA with other PAA (Active PAA). If APs controlled by Preparing PAA cannot communicate with those controlled by Active PAA, IEEE 802.11i pre-authentication cannot be executed. However by using procedure explained in [I-D.ietf-pana-preauth], PaC can start pre-authentication with Preparing PAA to install PSKs in the APs managed by it. In this way, if PaC decides to move to new AP, 4-way handshake can be started just after association with the new AP. Following, the process is described with much detail: 1. PaC looks for candidates APs. These candidates can belong to one of different types of networks described in Section 6.For those AP where PSK is needed, PaC could have already PSKs for a subset of them. For the others, PaC can try to bootstrap a PSK. 2. Through some mean (out of the scope of this document), PaC discovers Preparing PAA's IP address which manages those APs with whom PaC has not a PSK. 3. PaC starts a pre-authentication with Preparing PAA through current AP. 4. After pre-authentication, PAA is able to generate PSKs for its APs for that PaC. Also PaC can derive the same keys. Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 14] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 5. PaC finally moves to candidate AP to execute 4-way handshake It is worth mentioning that this solution is independent of types APs and cases to run PANA. 8.2. Key Installation [I-D.ietf-pana-preauth] describes two authorization phases that should be also considered during key installation. The first, when PaC is authenticated with Preparing PAA named pre-authorization phase and the second one (named post-authorization phase) when PaC moves and PUR-PUA exchange happens with Preparing PAA (that becomes Active PAA). If PSK installation in the APs is done during pre- authorization or post-authorization phase is a matter of network policies. However depending on if AP is able to allow restricted type of traffic over uncontrolled port or not, the moment of the key installation can be different. If candidate AP allows PANA traffic before 4-way handshake, PaC can send PUR to PAA to execute post-authorization phase before 4-way handshake is started by AP. With this, PAA can decide to do key installation during pre-authorization or with post-authorization. If candidate AP does NOT allow PANA execution before, necessarily 4-way handshake must be executed before post-authorization phase and therefore PAA needs to install the key during pre-authorization phase. Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 15] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 9. Implementation Considerations 9.1. PANA Agent After a successful PANA authentication, PAA must install the PSK in AP. This process MUST be done just after receiving a valid PANA- Binding-Answer(PBA) from PaC. Furthermore, PAA must know AP's IP address. Typically, this information will be pre-configured in the PAA. However PAA could not know to what specific AP, the PaC is attached (i.e. let suppose solicited PAA discovery). This is because any message from PaC informs to PAA where it is currently attached (after authentication PaC sends a PBA message without any EP-Device-Id AVP). One way to solve this is keys to be installed in all APs managed by PAA. In fact, this is the implicit method assumed in PANA. However, this could have some scalability issues when many APs are under control of PAA and/or many PaC are connected to APs. This is also particularly problematic in pre-authentication (see Section 8) if PSKs for all APs in the realm of the PAA are installed during pre- authorization phase. It is important to note after pre-authorization phase a PaC could not move to one of APs controlled by a Preparing PAA but however keys have already been installed. Additionally, this could happen in several Preparing PAAs. Basically, this key installation method is based on a pre-emptive key installation mechanism. That is, to install keys when it is not still needed. The advantage of this key installation method is that it provides the needed PSK for a particular PaC to AP before PaC is already attached, reducing the time to execute security association protocol and to gain network access. The disadvantage appears when PAA controls many APs, because PAA is allocating resources for the PSK and associated parameters in the APs before PaC uses them. The allocated resources increase as a consequence of number of PaCs attached to APs. An optimization is that the PAA may install only PSKs in APs belonging to the same subnet. It means to use pre-emptive key installation only in a subset of APs (those ones in the same subnet) controlled by PAA. PAA is able to know what subnet PaC is connected during PANA authentication. Additionally, if PaC moves to another subnet and changes IP address, it sends a PUR which gives information to PAA about new PaC's subnet. In the PUA, PAA sends the set of APs of that subnet where PSKs will be installed. Alternatively, AP may inform to PAA when a PaC is associated (note that IEEE 802.11 defines an SNMP association notification for this purpose). If PAA has a session with PaC, PAA derives in that moment Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 16] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 a PSK for that AP and that PaC and sends it to AP. This would be a mechanism of on-demand key installation (this mechanism is also useful in the case of pre-authentication in Section 8). The advantage of this method is that it will allow to allocate resources for the PSK in the AP only when it is really needed. The disadvantage of this method is that it will introduce a delay (this could be higher when PAA is placed to several IP hops from AP) in the PSK provisioning when the client is already attached to AP and waiting for 4-way handshake to gain network access. Note that PAA may also run some algorithm to determine the most likely APs where PaC will move and then sending the PSK to that APs (pre-emptive key installation). If the prediction fails and PaC moves to another AP where PSK has not been installed then on-demand key installation as described here can be used. 9.2. Access Point Typically AP will look for a PSK for PaC after association. If it is not found, AP will disassociate PaC. When PSK is bootstrapped by PANA, AP waits for a PSK from PAA although it does not violate that principle. . If PSK is not installed as a consequence of unsuccessful authentication AP will disassociate PaC because it did not find the PaC's PSK. The second one is that IEEE 802.11i MIB does not define a PSK per each user but a global PSK whose value can be modified. However in [802.11i] it is said that one implementation may support different PSKs for different users. Although no MIB object is explicitly defined to set the PSK lifetime, dot11RSNAConfigPMKLifetime object (see [802.11i]) might be used for this purpose. Regarding The Uncontrolled Port implementation, an IP filter to analyze when a data frame contains ARP, PANA, DHCP or IPv6 neighbour discovery must be developed. It can lead to modification at driver level. Additionally driver must duplicate ARP,DHCP and IPv6 neighbour discovery broadcast traffic from the DS from both controlled and uncontrolled port. 9.3. PaC and IEEE 802.11i Supplicant An interface is needed between PaC and Supplicant implementations. This interface is used to enforce a set of PSKs to the Supplicant after PANA authentication. Because 4-way handshake might be started by AP just after receiving PSK from PAA, PaC must enforce the bootstrapped PSK in the Supplicant before this event happens. Thus PaC must do this task before sending PBA because PAA will install PSK after receiving PBA. Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 17] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 Additionally, because in some cases 4-way handshake can be delayed by AP until completion PANA authentication, Supplicant should increase the wait time until receiving the first message in 4-way handshake. Finally note that the Supplicant implementation should allow that no pre-configured PSK and associated parameters are installed when the Supplicant is initialized. Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 18] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 10. IANA Considerations This document has no actions for IANA. Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 19] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 11. Security Considerations 11.1. PANA over 802.1X Uncontrolled Port PANA bootstrapping link-layer security in IEEE 802.11i networks through 802.1X Uncontrolled Port implies to restricted allow IP traffic over IEEE 802.1X that port. Allowed IP traffic are PANA, DHCP, ARP and IPv6 neighbour discovery. Filters checking this specific type of specific traffic should be considered weak because it is unauthenticated traffic. Additionally, AP can receive broadcast/multicast traffic from DS. Typically this broadcast traffic will be encrypted by GTK Security Association In terms of this document, certain type of broadcast/ multicast traffic must be allowed over uncontrolled port and it should not be processed by GTK security association. However this broadcast traffic can also needed for authenticated PaCs. It is true that also authenticated PaCs can use the non secured broadcast traffic however it is expected that authenticated PaC uses controlled port. As the AP cannot distinguish if the broadcast traffic is useful for either unauthenticated or authenticated PaCs, it must be sent for both ports. This is the case of ARP, DHCP and IPv6 neighbour discovery. This might be considered an issue, however this situation happens with only three protocols 11.2. PSK Installation If IEEE 802.11 association notification is used as trigger of PSK installation, the key installation process is based on non- authenticated information. That is, AP informs about just associated PaC's MAC address but it cannot assure if that PaC spoofed the MAC address of another PaC. Note that, fake PaC will not able to access network but it makes PSK installation procedure to be executed. Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 20] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 12. Acknowledgments TBD. Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 21] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 13. References 13.1. Normative References [802.11i] Institute of Electrical and Electronics Engineer, "Supplement to Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security", IEEE std. 802.11i, July 2004. [802.1X] Institute of Electrical and Electronics Engineer, "IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control", IEEE std. 802.1X-2004. [I-D.ietf-pana-framework] Jayaraman, P., "PANA Framework", draft-ietf-pana-framework-05 (work in progress), July 2005. [I-D.ietf-pana-pana] Forsberg, D., "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-10 (work in progress), July 2005. [I-D.ietf-pana-preauth] Ohba, Y., "Pre-authentication Support for PANA", draft-ietf-pana-preauth-00 (work in progress), October 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 13.2. Informative References [802.11r] Institute of Electrical and Electronics Engineer, "Draft Amendment to STANDARD FOR Information Technology - Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements. Part 11:Wireless Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 22] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Amendment 8: Fast BSS Transition", IEEE std. 802.11r. [802.11u] Institute of Electrical and Electronics Engineer, "IEEE P802.11u: Interworking with External Networks. TGu Requirements.", IEEE std. 802.11u, November 2005. [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-09 (work in progress), January 2006. [I-D.ietf-pana-ipsec] Parthasarathy, M., "PANA Enabling IPsec based Access Control", draft-ietf-pana-ipsec-07 (work in progress), July 2005. [RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, "Protocol for Carrying Authentication for Network Access (PANA) Requirements", RFC 4058, May 2005. [aboba-vap-2003] Aboba, B., "IEEE P802.11 Wireless LAN: Virtual Access Points", IEEE P802.11, May 2003. Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 23] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 Authors' Addresses Rafael Marin Lopez Toshiba America Research,Inc 1 Telcordia Dr. Piscataway, NJ 08854 USA Email: rmlopez@tari.toshiba.com Yoshihiro Ohba Toshiba America Research,Inc 1 Telcordia Dr. Piscataway, NJ 08854 USA Email: yohba@tari.toshiba.com Julien Bournelle GET/INT 9 rue Charles Fourier Evry, 91011 France Email: julien.bournelle@int-evry.fr Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 24] Internet-Draft PANA bootstrapping IEEE 802.11 security February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Marin Lopez(Ed.), et al. Expires August 28, 2006 [Page 25]