idnits 2.17.1 draft-mohanp-pana-ipsec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2003) is 7646 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'D1' is mentioned on line 94, but not defined == Missing Reference: 'D2' is mentioned on line 98, but not defined == Missing Reference: 'PANA-REQ' is mentioned on line 137, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-pana-requirements-04 ** Downref: Normative reference to an Informational draft: draft-ietf-pana-requirements (ref. 'PANAREQ') -- No information found for draft-ietf-pana - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PANA-PROT' == Outdated reference: A later version (-07) exists of draft-ietf-pana-threats-eval-03 ** Downref: Normative reference to an Informational draft: draft-ietf-pana-threats-eval (ref. 'PANA-THREATS') ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2461 (ref. 'IPV6-ND') (Obsoleted by RFC 4861) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group 3 Internet Draft 4 Document: draft-mohanp-pana-ipsec-00.txt 5 Expires: October 2003 May 2003 7 Securing the first hop in PANA using IPsec 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [i]. 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 except that the right to 16 produce derivative works is not granted. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 The PANA (Protocol for carrying Authentication for Network Access) 40 working group is developing protocol for authenticating clients to 41 the access network using IP based protocols. The PANA protocol 42 authenticates the client and also establishes a PANA security 43 association between the PANA client and PANA authentication agent at 44 the end of a successful authentication. But it does not specify any 45 mechanism for preventing service theft. This document discusses the 46 details for establishing an IPsec security association for securing 47 the link between PANA client and the enforcement point, which can be 48 used to prevent service theft. 50 Table of Contents 52 1.0 Introduction..................................................2 53 2.0 Keywords......................................................3 54 3.0 Pre-requisites for IPsec SA establishment...................3 55 4.0 Communication between PAA and EP............................3 56 5.0 IKE and IPsec details.........................................4 57 6.0 Packet Formats................................................4 58 7.0 IPsec SPD entries.............................................5 59 8.0 Double IPsec..................................................9 60 9.0 Security Considerations....................................10 61 10.0 Normative References......................................11 62 12.0 Acknowledgments.............................................11 63 14.0 Author's Addresses..........................................11 64 15.0 Full Copyright Statement....................................12 66 1.0 Introduction 68 The PANA (Protocol for carrying Authentication for Network Access) 69 working group is developing protocol for authenticating clients to 70 the access network using IP based protocols. The PANA protocol 71 authenticates the client and also establishes a PANA security 72 association between the PANA client and PANA authentication agent at 73 the end of successful authentication. The PANA protocol itself stops 74 here and does not discuss any methods for preventing service theft in 75 the access network. The service theft can be prevented by simple IP 76 address and MAC address filters, if the link between PANA client and 77 PANA agent is a non-shared medium. In the case of shared links, 78 filters are not sufficient to prevent service theft as it can be 79 easily spoofed [PANA-THREATS]. This document discusses the details 80 for establishing an IPsec security association for securing the link 81 between PANA client and the enforcement point, which can be used to 82 prevent service theft. 84 Please refer to [PANAREQ] for terminology and definitions of terms 85 used in this document. The following picture illustrates what is 86 being protected with IPsec. In Figure 1, it is assumed that PAA and 87 EP are co-located. It is also possible that they are not co-located. 88 But it does not affect the details in this draft. The IPsec security 89 association protects the traffic between PaC and EP. In IPsec terms, 90 EP is a security gateway (therefore a router) and forwards packets 91 coming from the PaC to other nodes. 93 PaC ---------------EP/PAA-+ 94 [D1] | 95 +- ----- AR 96 | 97 PaC ---------------EP/PAA-+ 98 [D2] 99 |------IPsec------| 101 Figure 1 103 First this document discusses some of the pre-requisites for IPsec SA 104 establishment. Next, it gives details on what should be communicated 105 between PAA and EP. Then, it gives the details of IKE/IPsec exchange 106 with packet formats and SPD entries. Finally, it discusses the issues 107 when IPsec is used for remote access together with local access. 109 2.0 Keywords 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [KEYWORDS]. 115 3.0 Pre-requisites for IPsec SA establishment 117 This document assumes that the following have already happened before 118 the IPSEC SA is established. 120 1) PANA client (PaC) learns the IP address of the Enforcement point 121 (EP) during the PANA exchange. 123 2) PaC learns that the network uses IPsec [IPSEC] for securing the 124 link between PaC and EP during the PANA exchange. 126 3) Pac has already acquired an IP address and PAA (and hence EP) 127 knows about the IP address of the PaC, before the IKE exchange 128 starts. 130 4.0 Communication between PAA and EP 132 If the network chooses IPsec to secure the link between PaC and EP, 133 PAA should communicate the IKE pre-shared key, the IP address of the 134 PaC and the PANA session ID to EP before the IKE exchange begins. 135 This might be just an API call, if PAA and EP are co-located. It is 136 assumed that the communication between PAA and EP is already secured 137 [PANA-REQ]. IKE pre-shared key is derived from the PANA SA, which is 138 established when PaC and PAA successfully authenticate to each other. 139 Pre-shared key is derived from the PANA SA using a prf (e.g. SHA-1). 141 5.0 IKE and IPsec details 143 IKE [IKE] MUST be used for establishing the IPsec SA. Manual keying 144 may not be possible, as the network does not know all the PaCs that 145 will be authenticating to the network, a priori. Main mode with pre- 146 shared key SHOULD be supported. Aggressive mode with pre-shared key 147 MUST be supported. or aggressive mode with pre-shared key. PaC and EP 148 SHOULD use its IP address as the client identifier in main mode and 149 PANA session ID [PANA-PROT] as the payload of ID_KEY_ID in aggressive 150 mode for establishing the Phase I SA. 152 After Phase I SA is established, quick mode exchange is performed to 153 establish an ESP transport mode IPsec SA for protecting the traffic 154 between PaC and EP. The packets are still tunneled between PaC and EP 155 as described later. But there is just one SA on the PaC for all the 156 traffic flow between PaC and EP. The next few sections discuss about 157 the packet formats and SPD entries. 159 6.0 Packet Formats 161 Following acronyms are used in this section. 163 EP's address is denoted by EP-ADDR. 164 PaC's address is denoted by PAC-ADDR. 165 The node with which the PaC is communicating is denoted by END-ADDR. 167 Following is the packet format on the wire for packets sent from PaC 168 to EP: 170 IPv4/IPv6 header (source = PAC-ADDR, 171 destination = EP-ADDR) 172 ESP header 173 IPv4/IPv6 header (source = PAC-ADDR, 174 destination = END-ADDR) 176 In case of IPv6, the outer IP header's addresses SHOULD be the link- 177 local address of PaC and EP. 179 Following is the packet format on the wire for packets sent from EP 180 to PaC: 182 IPv4/IPv6 header (source = EP-ADDR, 183 destination = PAC-ADDR) 184 ESP header 185 IPv4/IPv6 header (source = END-ADDR, 186 destination = PAC-ADDR) 188 In case of IPv6, the outer IP header's addresses SHOULD be the link- 189 local address of PaC and EP. 191 7.0 IPsec SPD entries 193 Following acronyms are used in this section. 195 EP's address is denoted by EP-ADDR. 196 PaC's address is denoted by PAC-ADDR. 197 PaC's link-local address is denoted by PAC-LINK-LOCAL 198 EP's link-local address is denoted by EP-LINK-LOCAL 200 The SPD entries given below affect the traffic destined to EP-ADDR. 201 If PAA and EP share the same IP address, then the traffic destined to 202 PAA will also be affected. This implies that some of the control 203 traffic, which is already protected using PANA SA will be protected 204 with IPsec also. This can be avoided (if needed) by configuring 205 bypass IPsec policy for packets that does not need protection. 207 7.1 IPv4 SPD entries 209 PaC's SPD OUT: 210 IF source = PAC-ADDR & destination = EP-ADDR & 211 protocol = IP-in-IP 212 THEN USE ESP TRANSPORT SA 214 PaC's SPD IN: 215 IF source = EP-ADDR & destination = PAC-ADDR & 216 protocol = IP-in-IP 217 THEN USE ESP TRANSPORT SA 219 EP's SPD OUT: 220 IF source = EP-ADDR & destination = PAC-ADDR & 221 protocol = IP-in-IP 222 THEN USE ESP TRANSPORT SA 224 EP's SPD IN: 225 IF source = PAC-ADDR & destination = EP-ADDR & 226 protocol = IP-in-IP 227 THEN USE ESP TRANSPORT SA 229 PaC configures an IP-in-IP tunnel [IP-TUN] interface and configures a 230 default route entry pointing at the IP-IP tunnel interface. There are 231 only two routes to other nodes. There is a direct route to EP and a 232 default route pointing at the tunnel interface. We denote the tunnel 233 interface by PAC-EP-TUN interface in the following discussion. This 234 tunnel interface adds the encapsulating header . Similarly, EP configures IP-IP tunnel interface for each PaC 236 and there is one route for each PaC pointing at the right tunnel 237 interface. The tunnel interface in EP adds the encapsulating header 238 . 240 It is assumed that PaC has two interfaces. First one represents the 241 actual physical attachment to the network e.g., Ethernet interface 242 and the second one is the tunnel interface PAC-EP-TUN interface. 243 Following steps describe the packet processing in detail on a PaC. 245 1. An IPv4 packet is sent to destination "DEST". 247 2. None of the SPD rules matches the packet. Note that even if "DEST" 248 is EP-ADDR, the protocol normally does not match unless the 249 application is using raw sockets. 251 3. IP stack looks up the route. The default route matches and the 252 route points at the PAC-EP-TUN interface. The tunnel encapsulates 253 the packet and the encapsulated packet re-enters IP stack. 255 4. Now, the packet matches the above SPD rule and the packet is 256 protected using ESP transport mode SA. If an ESP transport mode SA 257 is not found, IKE is triggered to setup the SA. 259 Similar steps happen on the EP also. 261 7.2 IPv6 SPD entries 263 The IPv6 SPD entries are slightly different from IPv4 to prevent the 264 neighbor discovery [IPV6-ND] packets from being protected with IPsec. 265 Due to the current limitation in specifying the proper selectors for 266 neighbor discovery packets, the following selectors, bypasses IPsec 267 for link-local traffic. All traffic destined to global address is 268 always sent to the default router i.e, the global prefix is not 269 considered to be on-link. 271 Pac's SPD OUT: 273 IF source = ::/128 & destination = any 274 THEN BYPASS 276 IF source = fe80::/10 & destination = any 277 THEN BYPASS 279 IF source = any & destination = fe80::/10 280 THEN BYPASS 282 IF source = PAC-LINK-LOCAL & destination = EP-LINK-LOCAL 283 & protocol = IPv6-in-IPv6 284 THEN USE ESP TRANSPORT SA 286 PaC's SPD IN: 288 IF source = ::/128 & destination = any 289 THEN BYPASS 291 IF source = fe80::/10 & destination = any 292 THEN BYPASS 294 IF source = any & destination = fe80::/10 295 THEN BYPASS 297 IF source = EP-LINK-LOCAL & destination = PAC-LINK-LOCAL 298 & protocol = IPv6-in-IPv6 299 THEN USE ESP TRANSPORT SA 301 EP's SPD OUT: 303 IF source = ::/128 & destination = any 304 THEN BYPASS 306 IF source = fe80::/10 & destination = any 307 THEN BYPASS 309 IF source = any & destination = fe80::/10 310 THEN BYPASS 312 IF source = EP-LINK-LOCAL & destination = PAC-LINK-LOCAL 313 & protocol = IPv6-in-IPv6 314 THEN USE ESP TRANSPORT SA 316 EP's SPD IN: 318 IF source = ::/128 & destination = any 319 THEN BYPASS 321 IF source = fe80::/10 & destination = any 322 THEN BYPASS 324 IF source = any & destination = fe80::/10 325 THEN BYPASS 327 IF source = PAC-LINK-LOCAL & destination = EP-LINK-LOCAL 328 & protocol = IPv6-in-IPv6 329 THEN USE ESP TRANSPORT SA 330 PaC configures an IPv6-in-IPv6 tunnel [IPV6-TUN] interface and 331 configures a default route entry pointing at the tunnel interface. We 332 denote this by PAC-EP-TUN6 interface in the following discussion. The 333 tunnel interface adds the encapsulating header . Following the conceptual model in section 5.1 of 335 [IPV6-ND], PaC would maintain the following. 337 1) Neighbor Cache : This contains the entry for EP and entries for 338 link-local addresses of other PaC's on the link. 339 2) Destination Cache : This contains the entry for EP and entries 340 for link-local addresses of other PaC's on the link. 341 3) Prefix List : This list contains the link-local prefix alone. 342 4) Default Router List : This list contains the EP alone. 344 Similarly, EP configures IPv6-in-IPv6 tunnel interface for each PaC 345 and there is one route for each PaC pointing at the right tunnel 346 interface. The tunnel interface in EP adds the encapsulating header 347 . All packets that are not 348 destined to a link-local address are sent to the default router (EP). 349 This can be achieved by turning off the "L" bit in the router 350 advertisement. Following steps describe the packet processing in 351 detail. 353 It is assumed that PaC has two interfaces. First one represents the 354 actual physical attachment to the network e.g., Ethernet interface 355 and the second one is the tunnel interface PAC-EP-TUN6 interface. 356 Following steps describe the packet processing in detail on a PaC. 358 1. An IPv6 packet is sent to destination "DEST6". 360 2. If the packet has a source address of all zeroes e.g. duplicate 361 address detection, then IPsec is bypassed irrespective of the 362 destination address. These packets are sent out directly on the 363 physical interface. 365 3. If source or DEST6 is link-local unicast or multicast, then IPsec 366 is bypassed. Route lookup will return a route pointing at the 367 physical interface through which the packets will be sent out. 369 4. At this step, none of the SPD rules match the packet. Note that 370 even if "DEST" is "EP-ADDR", the protocol normally does not match 371 unless the application is using raw sockets. 373 5. IP stack looks up the route. The default route matches and the 374 route points at the PAC-EP-TUN6 interface. The tunnel encapsulates 375 the packet and the encapsulated packet re-enters IP stack. 377 6. Now, the packet matches the SPD rule and the packet is protected 379 using ESP transport mode SA. If an ESP transport mode SA is not 380 found, IKE is triggered to setup the SA. 382 Similar steps happen on the EP also. 384 8.0 Double IPsec 386 If the PaC uses IPsec for secure remote access, there will be 387 separate SPD entries protecting the traffic to/from remote network. 388 In this case, IPsec needs to be applied twice, once for protecting 389 the remote access and once for protecting the local access. Following 390 are the differences when IPsec is used for remote access. 392 1) PaC's SPD OUT entry will have the following additional rules. 394 IF source = REMOTE-PAC-ADDR and DST = REMOTE-NET 395 THEN USE ESP TUNNEL SA 396 endpoints: REMOTE-PAC-ADDR � REMOTE-GW 398 where is the address in remote network. 399 is the subnet representing the remote 400 network. 401 is the external address of the remote 402 security gateway. 403 There is a corresponding entry in the security gateway 404 of the remote network, which is not shown here. 406 2) There is a route for reaching REMOTE-NET through the PAC-EP- 407 TUN/PAC-EP-TUN6 interface (see section 7.0). 409 Following steps describe the SA establishment and packet processing 410 in detail. 412 1) PaC completes the PANA authentication exchange successfully and 413 creates the PANA SA. 415 2) PaC initiates the IKE exchange with the EP and establishes a ESP 416 transport mode IPSec SA. 418 3) PaC sends packet to destination DEST. If DEST is part of remote 419 network, the SPD rule will 420 match which in turn triggers the SA establishment process. 422 4) If SA does not exist, it will trigger the IKE packet to be sent to 423 the REMOTE-GW. If SA exists go to step (9) 424 5) IKE packets enter IP and IPsec is bypassed using socket options or 425 explicit bypass rules. The route entry for matches and 426 hence gets encapsulated through the tunnel. The tunnel adds an 427 extra IP header. 429 6) The tunneled packet gets protected using the IPsec SA created in 430 step (2). Note that it is possible that the transport mode SA does 431 not exist at this stage. In that case, IKE will be triggered and 432 the packet will be sent to the EP address. This packet will not get 433 encapsulated and will bypass IPsec and establish the IPsec SA with 434 EP. 436 7) EP on receiving the packet from PaC, will decapsulate the packet 437 and match with the selectors. As it will match successfully, the 438 packet will be forwarded to the remote network. 440 8) Step (4) to step (6) will happen till the IPsec SA for the remote 441 network is established. 443 9) Any packet to the remote network will follow the same path as the 444 IKE packet described above. The packet will be protected using ESP 445 tunnel mode SA and then a transport mode SA. 447 In IPv4, the packet sent by PaC on the wire has the following format. 449 IP [source = PAC-ADDR, destination = EP-ADDR] 450 ESP [Transport mode SA to EP] 451 IP [source = PAC-ADDR, destination = EP-ADDR] 452 ESP [Tunnel mode SA to REMOTE-NET] 453 IP [source = REMOTE-PAC-ADDR, destination = REMOTE-NET] 454 TCP/UDP 456 In IPv6, the final packet will be similar except the final IP header 457 on the packet will use link-local address. 459 9.0 Security Considerations 461 This document discusses the use of IPsec in the context of PANA to 462 prevent service theft in the access network. As IPsec cannot specify 463 traffic selectors based on ICMP code types, the selectors defined in 464 this document will bypass IPsec for all link-local traffic. This may 465 be a problem in some cases. EP should be configured with an SPD rule 466 to bypass IPsec for IKE traffic destined from PAC-ADDR to EP-ADDR and 467 PAC-LINK-LOCAL to EP-LINK-LOCAL. It may give rise to some 468 vulnerabilities as any node can send traffic to port 500 (which need 469 not be IKE traffic) and EP will not enforce IPsec for such packets. 470 Note that there are no rules to bypass IPsec policy for IKE packets 471 destined to remote network on EP, as they are protected by the SA 472 between PaC and EP. 474 10.0 Normative References 476 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 477 9, RFC 2026, October 1996. 479 2. [PANAREQ] A. Yegin et al., "Protocol for Carrying Authentication 480 for Network Access (PANA) Requirements and Terminology", draft- 481 ietf-pana-requirements-04.txt 483 3. [PANA-PROT] D.Fosberg et al., "Protocol for Carrying 484 Authentication for Network Access", draft-ietf-pana-00.txt 486 4. [PANA-THREATS] M.Parthasarathy, "PANA Threat analysis and security 487 requirements", draft-ietf-pana-threats-eval-03.txt 489 5. [KEYWORDS] S. Bradner, "Key words for use in RFCS to indicate 490 requirement levels", RFC 2119, March 1997 492 6. [IPSEC] S. Kent et al., "Security Architecture for the Internet 493 Protocol", RFC 2401, November 1998 495 7. [IKE] D. Harkins et al., "Internet Key Exchange", RFC 2409, 496 November 1998 498 8. [IPV6-ND] T. Narten et al., "Neighbor Discovery for IP version 6 499 (IPv6) ", RFC 2461, December 1998. 501 8. [IP-TUN] C. Perkins, "IP Encapsulation within IP", RFC 2003, 502 October 1996 504 9. [IPV6-TUN] A. Conta, "Generic Packet Tunneling in IPv6 505 specification", RFC 2473, December 1998. 507 12.0 Acknowledgments 509 Thanks to Francis Dupont for the interesting discussions and comments 510 on this draft. 512 14.0 Author's Addresses 514 Mohan Parthasarathy 515 Tahoe Networks 516 3052 Orchard Drive 517 San Jose, CA 95134 519 Phone: 408-944-8220 520 Email: mohanp@tahoenetworks.com 522 15.0 Full Copyright Statement 524 Copyright (C) The Internet Society (2003). All Rights Reserved. 526 This document and translations of it may be copied and furnished to 527 others, and derivative works that comment on or otherwise explain it 528 or assist in its implementation may be prepared, copied, published 529 and distributed, in whole or in part, without restriction of any 530 kind, provided that the above copyright notice and this paragraph are 531 included on all such copies and derivative works. However, this 532 document itself may not be modified in any way, such as by removing 533 the copyright notice or references to the Internet Society or other 534 Internet organizations, except as needed for the purpose of 535 developing Internet standards in which case the procedures for 536 copyrights defined in the Internet Standards process must be 537 followed, or as required to translate it into languages other than 538 English. 540 The limited permissions granted above are perpetual and will not be 541 revoked by the Internet Society or its successors or assigns. 543 This document and the information contained herein is provided on an 544 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 545 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 546 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 547 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 548 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 550 Acknowledgement 552 Funding for the RFC Editor function is currently provided by the 553 Internet Society.