PANA Working Group Internet Draft <M. Parthasarathy> Document: draft-mohanp-pana-ipsec-00.txt <Tahoe Networks> Expires: October 2003 May 2003 Securing the first hop in PANA using IPsec Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [i]. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The PANA (Protocol for carrying Authentication for Network Access) working group is developing protocol for authenticating clients to the access network using IP based protocols. The PANA protocol authenticates the client and also establishes a PANA security association between the PANA client and PANA authentication agent at the end of a successful authentication. But it does not specify any mechanism for preventing service theft. This document discusses the details for establishing an IPsec security association for securing <Parthasarathy> Expires September 2003 [Page 1]
PANA and using IPsec May 2003 the link between PANA client and the enforcement point, which can be used to prevent service theft. Table of Contents 1.0 Introduction..................................................2 2.0 Keywords......................................................3 3.0 Pre-requisites for IPsec SA establishment...................3 4.0 Communication between PAA and EP............................3 5.0 IKE and IPsec details.........................................4 6.0 Packet Formats................................................4 7.0 IPsec SPD entries.............................................5 8.0 Double IPsec..................................................9 9.0 Security Considerations....................................10 10.0 Normative References......................................11 12.0 Acknowledgments.............................................11 14.0 Author's Addresses..........................................11 15.0 Full Copyright Statement....................................12 1.0 Introduction The PANA (Protocol for carrying Authentication for Network Access) working group is developing protocol for authenticating clients to the access network using IP based protocols. The PANA protocol authenticates the client and also establishes a PANA security association between the PANA client and PANA authentication agent at the end of successful authentication. The PANA protocol itself stops here and does not discuss any methods for preventing service theft in the access network. The service theft can be prevented by simple IP address and MAC address filters, if the link between PANA client and PANA agent is a non-shared medium. In the case of shared links, filters are not sufficient to prevent service theft as it can be easily spoofed [PANA-THREATS]. This document discusses the details for establishing an IPsec security association for securing the link between PANA client and the enforcement point, which can be used to prevent service theft. Please refer to [PANAREQ] for terminology and definitions of terms used in this document. The following picture illustrates what is being protected with IPsec. In Figure 1, it is assumed that PAA and EP are co-located. It is also possible that they are not co-located. But it does not affect the details in this draft. The IPsec security association protects the traffic between PaC and EP. In IPsec terms, EP is a security gateway (therefore a router) and forwards packets coming from the PaC to other nodes. <Parthasarathy> Expires October 2003 [Page 2]
PANA and using IPsec May 2003 PaC ---------------EP/PAA-+ [D1] | +- ----- AR | PaC ---------------EP/PAA-+ [D2] |------IPsec------| Figure 1 First this document discusses some of the pre-requisites for IPsec SA establishment. Next, it gives details on what should be communicated between PAA and EP. Then, it gives the details of IKE/IPsec exchange with packet formats and SPD entries. Finally, it discusses the issues when IPsec is used for remote access together with local access. 2.0 Keywords 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 [KEYWORDS]. 3.0 Pre-requisites for IPsec SA establishment This document assumes that the following have already happened before the IPSEC SA is established. 1) PANA client (PaC) learns the IP address of the Enforcement point (EP) during the PANA exchange. 2) PaC learns that the network uses IPsec [IPSEC] for securing the link between PaC and EP during the PANA exchange. 3) Pac has already acquired an IP address and PAA (and hence EP) knows about the IP address of the PaC, before the IKE exchange starts. 4.0 Communication between PAA and EP If the network chooses IPsec to secure the link between PaC and EP, PAA should communicate the IKE pre-shared key, the IP address of the PaC and the PANA session ID to EP before the IKE exchange begins. This might be just an API call, if PAA and EP are co-located. It is assumed that the communication between PAA and EP is already secured [PANA-REQ]. IKE pre-shared key is derived from the PANA SA, which is <Parthasarathy> Expires October 2003 [Page 3]
PANA and using IPsec May 2003 established when PaC and PAA successfully authenticate to each other. Pre-shared key is derived from the PANA SA using a prf (e.g. SHA-1). 5.0 IKE and IPsec details IKE [IKE] MUST be used for establishing the IPsec SA. Manual keying may not be possible, as the network does not know all the PaCs that will be authenticating to the network, a priori. Main mode with pre- shared key SHOULD be supported. Aggressive mode with pre-shared key MUST be supported. or aggressive mode with pre-shared key. PaC and EP SHOULD use its IP address as the client identifier in main mode and PANA session ID [PANA-PROT] as the payload of ID_KEY_ID in aggressive mode for establishing the Phase I SA. After Phase I SA is established, quick mode exchange is performed to establish an ESP transport mode IPsec SA for protecting the traffic between PaC and EP. The packets are still tunneled between PaC and EP as described later. But there is just one SA on the PaC for all the traffic flow between PaC and EP. The next few sections discuss about the packet formats and SPD entries. 6.0 Packet Formats Following acronyms are used in this section. EP's address is denoted by EP-ADDR. PaC's address is denoted by PAC-ADDR. The node with which the PaC is communicating is denoted by END-ADDR. Following is the packet format on the wire for packets sent from PaC to EP: IPv4/IPv6 header (source = PAC-ADDR, destination = EP-ADDR) ESP header IPv4/IPv6 header (source = PAC-ADDR, destination = END-ADDR) In case of IPv6, the outer IP header's addresses SHOULD be the link- local address of PaC and EP. Following is the packet format on the wire for packets sent from EP to PaC: IPv4/IPv6 header (source = EP-ADDR, destination = PAC-ADDR) ESP header <Parthasarathy> Expires October 2003 [Page 4]
PANA and using IPsec May 2003 IPv4/IPv6 header (source = END-ADDR, destination = PAC-ADDR) In case of IPv6, the outer IP header's addresses SHOULD be the link- local address of PaC and EP. 7.0 IPsec SPD entries Following acronyms are used in this section. EP's address is denoted by EP-ADDR. PaC's address is denoted by PAC-ADDR. PaC's link-local address is denoted by PAC-LINK-LOCAL EP's link-local address is denoted by EP-LINK-LOCAL The SPD entries given below affect the traffic destined to EP-ADDR. If PAA and EP share the same IP address, then the traffic destined to PAA will also be affected. This implies that some of the control traffic, which is already protected using PANA SA will be protected with IPsec also. This can be avoided (if needed) by configuring bypass IPsec policy for packets that does not need protection. 7.1 IPv4 SPD entries PaC's SPD OUT: IF source = PAC-ADDR & destination = EP-ADDR & protocol = IP-in-IP THEN USE ESP TRANSPORT SA PaC's SPD IN: IF source = EP-ADDR & destination = PAC-ADDR & protocol = IP-in-IP THEN USE ESP TRANSPORT SA EP's SPD OUT: IF source = EP-ADDR & destination = PAC-ADDR & protocol = IP-in-IP THEN USE ESP TRANSPORT SA EP's SPD IN: IF source = PAC-ADDR & destination = EP-ADDR & protocol = IP-in-IP THEN USE ESP TRANSPORT SA PaC configures an IP-in-IP tunnel [IP-TUN] interface and configures a default route entry pointing at the IP-IP tunnel interface. There are only two routes to other nodes. There is a direct route to EP and a default route pointing at the tunnel interface. We denote the tunnel interface by PAC-EP-TUN interface in the following discussion. This <Parthasarathy> Expires October 2003 [Page 5]
PANA and using IPsec May 2003 tunnel interface adds the encapsulating header <SRC=PAC-ADDR, DST=EP- ADDR>. Similarly, EP configures IP-IP tunnel interface for each PaC and there is one route for each PaC pointing at the right tunnel interface. The tunnel interface in EP adds the encapsulating header <SRC=EP-ADDR, DST=PAC-ADDR>. It is assumed that PaC has two interfaces. First one represents the actual physical attachment to the network e.g., Ethernet interface and the second one is the tunnel interface PAC-EP-TUN interface. Following steps describe the packet processing in detail on a PaC. 1. An IPv4 packet is sent to destination "DEST". 2. None of the SPD rules matches the packet. Note that even if "DEST" is EP-ADDR, the protocol normally does not match unless the application is using raw sockets. 3. IP stack looks up the route. The default route matches and the route points at the PAC-EP-TUN interface. The tunnel encapsulates the packet and the encapsulated packet re-enters IP stack. 4. Now, the packet matches the above SPD rule and the packet is protected using ESP transport mode SA. If an ESP transport mode SA is not found, IKE is triggered to setup the SA. Similar steps happen on the EP also. 7.2 IPv6 SPD entries The IPv6 SPD entries are slightly different from IPv4 to prevent the neighbor discovery [IPV6-ND] packets from being protected with IPsec. Due to the current limitation in specifying the proper selectors for neighbor discovery packets, the following selectors, bypasses IPsec for link-local traffic. All traffic destined to global address is always sent to the default router i.e, the global prefix is not considered to be on-link. Pac's SPD OUT: IF source = ::/128 & destination = any THEN BYPASS IF source = fe80::/10 & destination = any THEN BYPASS IF source = any & destination = fe80::/10 THEN BYPASS IF source = PAC-LINK-LOCAL & destination = EP-LINK-LOCAL <Parthasarathy> Expires October 2003 [Page 6]
PANA and using IPsec May 2003 & protocol = IPv6-in-IPv6 THEN USE ESP TRANSPORT SA PaC's SPD IN: IF source = ::/128 & destination = any THEN BYPASS IF source = fe80::/10 & destination = any THEN BYPASS IF source = any & destination = fe80::/10 THEN BYPASS IF source = EP-LINK-LOCAL & destination = PAC-LINK-LOCAL & protocol = IPv6-in-IPv6 THEN USE ESP TRANSPORT SA EP's SPD OUT: IF source = ::/128 & destination = any THEN BYPASS IF source = fe80::/10 & destination = any THEN BYPASS IF source = any & destination = fe80::/10 THEN BYPASS IF source = EP-LINK-LOCAL & destination = PAC-LINK-LOCAL & protocol = IPv6-in-IPv6 THEN USE ESP TRANSPORT SA EP's SPD IN: IF source = ::/128 & destination = any THEN BYPASS IF source = fe80::/10 & destination = any THEN BYPASS IF source = any & destination = fe80::/10 THEN BYPASS IF source = PAC-LINK-LOCAL & destination = EP-LINK-LOCAL & protocol = IPv6-in-IPv6 THEN USE ESP TRANSPORT SA <Parthasarathy> Expires October 2003 [Page 7]
PANA and using IPsec May 2003 PaC configures an IPv6-in-IPv6 tunnel [IPV6-TUN] interface and configures a default route entry pointing at the tunnel interface. We denote this by PAC-EP-TUN6 interface in the following discussion. The tunnel interface adds the encapsulating header <SRC=PAC-LINK-LOCAL, DST=EP-LINK-LOCAL>. Following the conceptual model in section 5.1 of [IPV6-ND], PaC would maintain the following. 1) Neighbor Cache : This contains the entry for EP and entries for link-local addresses of other PaC's on the link. 2) Destination Cache : This contains the entry for EP and entries for link-local addresses of other PaC's on the link. 3) Prefix List : This list contains the link-local prefix alone. 4) Default Router List : This list contains the EP alone. Similarly, EP configures IPv6-in-IPv6 tunnel interface for each PaC and there is one route for each PaC pointing at the right tunnel interface. The tunnel interface in EP adds the encapsulating header <SRC=EP-LINK-LOCAL, DST=PAC-LINK-LOCAL>. All packets that are not destined to a link-local address are sent to the default router (EP). This can be achieved by turning off the "L" bit in the router advertisement. Following steps describe the packet processing in detail. It is assumed that PaC has two interfaces. First one represents the actual physical attachment to the network e.g., Ethernet interface and the second one is the tunnel interface PAC-EP-TUN6 interface. Following steps describe the packet processing in detail on a PaC. 1. An IPv6 packet is sent to destination "DEST6". 2. If the packet has a source address of all zeroes e.g. duplicate address detection, then IPsec is bypassed irrespective of the destination address. These packets are sent out directly on the physical interface. 3. If source or DEST6 is link-local unicast or multicast, then IPsec is bypassed. Route lookup will return a route pointing at the physical interface through which the packets will be sent out. 4. At this step, none of the SPD rules match the packet. Note that even if "DEST" is "EP-ADDR", the protocol normally does not match unless the application is using raw sockets. 5. IP stack looks up the route. The default route matches and the route points at the PAC-EP-TUN6 interface. The tunnel encapsulates the packet and the encapsulated packet re-enters IP stack. <Parthasarathy> Expires October 2003 [Page 8]
PANA and using IPsec May 2003 6. Now, the packet matches the SPD rule <SRC=PAC-LINK-LOCAL, DST=EP- LINK-LOCAL, protocol = IPv6-in-IPv6> and the packet is protected using ESP transport mode SA. If an ESP transport mode SA is not found, IKE is triggered to setup the SA. Similar steps happen on the EP also. 8.0 Double IPsec If the PaC uses IPsec for secure remote access, there will be separate SPD entries protecting the traffic to/from remote network. In this case, IPsec needs to be applied twice, once for protecting the remote access and once for protecting the local access. Following are the differences when IPsec is used for remote access. 1) PaC's SPD OUT entry will have the following additional rules. IF source = REMOTE-PAC-ADDR and DST = REMOTE-NET THEN USE ESP TUNNEL SA endpoints: REMOTE-PAC-ADDR REMOTE-GW where <REMOTE-PAC-ADDR> is the address in remote network. <REMOTE-NET> is the subnet representing the remote network. <REMOTE-GW> is the external address of the remote security gateway. There is a corresponding entry in the security gateway of the remote network, which is not shown here. 2) There is a route for reaching REMOTE-NET through the PAC-EP- TUN/PAC-EP-TUN6 interface (see section 7.0). Following steps describe the SA establishment and packet processing in detail. 1) PaC completes the PANA authentication exchange successfully and creates the PANA SA. 2) PaC initiates the IKE exchange with the EP and establishes a ESP transport mode IPSec SA. 3) PaC sends packet to destination DEST. If DEST is part of remote network, the SPD rule <SRC=REMOTE-PAC-ADDR,DST=REMOTE-NET> will match which in turn triggers the SA establishment process. 4) If SA does not exist, it will trigger the IKE packet to be sent to the REMOTE-GW. If SA exists go to step (9) <Parthasarathy> Expires October 2003 [Page 9]
PANA and using IPsec May 2003 5) IKE packets enter IP and IPsec is bypassed using socket options or explicit bypass rules. The route entry for <REMOTE-NET> matches and hence gets encapsulated through the tunnel. The tunnel adds an extra IP header. 6) The tunneled packet gets protected using the IPsec SA created in step (2). Note that it is possible that the transport mode SA does not exist at this stage. In that case, IKE will be triggered and the packet will be sent to the EP address. This packet will not get encapsulated and will bypass IPsec and establish the IPsec SA with EP. 7) EP on receiving the packet from PaC, will decapsulate the packet and match with the selectors. As it will match successfully, the packet will be forwarded to the remote network. 8) Step (4) to step (6) will happen till the IPsec SA for the remote network is established. 9) Any packet to the remote network will follow the same path as the IKE packet described above. The packet will be protected using ESP tunnel mode SA and then a transport mode SA. In IPv4, the packet sent by PaC on the wire has the following format. IP [source = PAC-ADDR, destination = EP-ADDR] ESP [Transport mode SA to EP] IP [source = PAC-ADDR, destination = EP-ADDR] ESP [Tunnel mode SA to REMOTE-NET] IP [source = REMOTE-PAC-ADDR, destination = REMOTE-NET] TCP/UDP In IPv6, the final packet will be similar except the final IP header on the packet will use link-local address. 9.0 Security Considerations This document discusses the use of IPsec in the context of PANA to prevent service theft in the access network. As IPsec cannot specify traffic selectors based on ICMP code types, the selectors defined in this document will bypass IPsec for all link-local traffic. This may be a problem in some cases. EP should be configured with an SPD rule to bypass IPsec for IKE traffic destined from PAC-ADDR to EP-ADDR and PAC-LINK-LOCAL to EP-LINK-LOCAL. It may give rise to some vulnerabilities as any node can send traffic to port 500 (which need not be IKE traffic) and EP will not enforce IPsec for such packets. Note that there are no rules to bypass IPsec policy for IKE packets <Parthasarathy> Expires October 2003 [Page 10]
PANA and using IPsec May 2003 destined to remote network on EP, as they are protected by the SA between PaC and EP. 10.0 Normative References 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2. [PANAREQ] A. Yegin et al., "Protocol for Carrying Authentication for Network Access (PANA) Requirements and Terminology", draft- ietf-pana-requirements-04.txt 3. [PANA-PROT] D.Fosberg et al., "Protocol for Carrying Authentication for Network Access", draft-ietf-pana-00.txt 4. [PANA-THREATS] M.Parthasarathy, "PANA Threat analysis and security requirements", draft-ietf-pana-threats-eval-03.txt 5. [KEYWORDS] S. Bradner, "Key words for use in RFCS to indicate requirement levels", RFC 2119, March 1997 6. [IPSEC] S. Kent et al., "Security Architecture for the Internet Protocol", RFC 2401, November 1998 7. [IKE] D. Harkins et al., "Internet Key Exchange", RFC 2409, November 1998 8. [IPV6-ND] T. Narten et al., "Neighbor Discovery for IP version 6 (IPv6) ", RFC 2461, December 1998. 8. [IP-TUN] C. Perkins, "IP Encapsulation within IP", RFC 2003, October 1996 9. [IPV6-TUN] A. Conta, "Generic Packet Tunneling in IPv6 specification", RFC 2473, December 1998. 12.0 Acknowledgments Thanks to Francis Dupont for the interesting discussions and comments on this draft. 14.0 Author's Addresses Mohan Parthasarathy Tahoe Networks 3052 Orchard Drive <Parthasarathy> Expires October 2003 [Page 11]
PANA and using IPsec May 2003 San Jose, CA 95134 Phone: 408-944-8220 Email: mohanp@tahoenetworks.com 15.0 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. <Parthasarathy> Expires October 2003 [Page 12]