idnits 2.17.1 draft-ietf-pana-ipsec-00.txt: -(452): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 (October 2003) is 7493 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 96, but not defined == Missing Reference: 'D2' is mentioned on line 100, but not defined == Missing Reference: 'PANA-REQ' is mentioned on line 143, but not defined ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) == Outdated reference: A later version (-09) exists of draft-ietf-pana-requirements-04 -- No information found for draft-ietf-pana - is the name correct? == Outdated reference: A later version (-07) exists of draft-ietf-pana-threats-eval-04 -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. 'IPV6-ND') (Obsoleted by RFC 4861) -- No information found for draft-aboba-ppext-key-problem - is the name correct? -- Duplicate reference: RFC2401, mentioned in 'IPSEC-ML', was also mentioned in 'IPSEC'. -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPSEC-ML') (Obsoleted by RFC 4301) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 8 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-ietf-pana-ipsec-00.txt October 2003 5 Expires: March 2004 7 PANA enabling IPsec based Access Control 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. This document discusses the 45 details for establishing an IPsec security association using the PANA 46 security association for enabling IPsec based access control. 48 PANA enabling IPsec based Access Control October 2003 50 Table of Contents 52 1.0 Introduction..................................................2 53 2.0 Keywords......................................................3 54 3.0 Pre-requisites for IPsec SA establisment......................3 55 4.0 IKE Pre-shared key derivation.................................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..................................................8 60 9.0 Security considerations.......................................9 61 10.0 Normative References.........................................9 62 12.0 Acknowledgments.............................................10 63 13.0 Revision log................................................10 64 14.0 Author's Addresses..........................................10 65 15.0 Full Copyright Statement....................................10 67 1.0 Introduction 69 The PANA (Protocol for carrying Authentication for Network Access) 70 working group is developing protocol for authenticating clients to 71 the access network using IP based protocols. The PANA protocol 72 authenticates the client and also establishes a PANA security 73 association between the PANA client and PANA authentication agent at 74 the end of successful authentication. The PANA authentication agent 75 (PAA) indicates the results of the authentication using the PANA- 76 Bind-Request message wherein it can indicate the access control 77 method enforced by the access network. The PANA protocol [PANA-PROT] 78 does not discuss any details of IPsec [IPSEC] SA establishment, when 79 IPsec is used for access control. This document discusses the details 80 of establishing an IPsec security association between PANA client and 81 the enforcement point. When the IPsec SA is successfully established, 82 it can be used for access control and specifically used to prevent 83 the service theft mentioned in [PANA-THREATS]. 85 Please refer to [PANAREQ] for terminology and definitions of terms 86 used in this document. The following picture illustrates what is 87 being protected with IPsec. In Figure 1, it is assumed that PAA and 88 EP are co-located. It is also possible that they are not co-located. 89 The IPsec security association protects the traffic between PaC and 90 EP. In IPsec terms, EP is a security gateway (therefore a router) and 91 forwards packets coming from the PaC to other nodes. 93 PANA enabling IPsec based Access Control October 2003 95 PaC ---------------EP/PAA-+ 96 [D1] | 97 +- ----- AR 98 | 99 PaC ---------------EP/PAA-+ 100 [D2] 101 |------IPsec------| 103 Figure 1 105 First, this document discusses some of the pre-requisites for IPsec 106 SA establishment. Next, it gives details on what should be 107 communicated between PAA and EP. Then, it gives the details of 108 IKE/IPsec exchange with packet formats and SPD entries. Finally, it 109 discusses the issues when IPsec is used for remote access together 110 with local access. 112 2.0 Keywords 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [KEYWORDS]. 118 3.0 Pre-requisites for IPsec SA establisment 120 This document assumes that the following have already happened before 121 the IPSEC SA is established. 123 1) PANA client (PaC) learns the IP address of the Enforcement point 124 (EP) during the PANA exchange. 126 2) PaC learns that the network uses IPsec [IPSEC] for securing the 127 link between PaC and EP during the PANA exchange. 129 3) PaC has already acquired an IP address and EP knows about the IP 130 address of the PaC, before the IKE exchange starts. If IPv6 is 131 being used, the EP needs to know both the global address and the 132 link-local address of the PaC. 134 4.0 IKE Pre-shared key derivation 136 If the network chooses IPsec to secure the link between PaC and EP, 137 PAA should communicate the IKE pre-shared key, the IP address of the 138 PaC and the PANA session ID to EP before the IKE exchange begins. 139 This might be just an API call, if PAA and EP are co-located. It is 140 PANA enabling IPsec based Access Control October 2003 142 assumed that the communication between PAA and EP is already secured 143 [PANA-REQ]. 145 The IKE exchange between PaC and PAA is equivalent to the 4-way 146 handshake in [IEEE80211i] following the EAP exchange. The IKE 147 exchange establishes the IPsec SA similar to the pair-wise transient 148 keys (PTK) established in [IEEE80211i]. The IKE exchange provides 149 both key confirmation and protected cipher-suite negotiation. 151 IKE pre-shared key is derived as follows. 153 IKE Pre-shared Key = HMAC-SHA-1 (MSK, "IKE-preshared key" | 154 Session ID) 156 The values have the following meaning: 158 MSK: The Master Session Key (MSK) is provided by the EAP method as 159 part of the PANA/EAP protocol execution. Please refer to [EAP-KEY] 160 for details. 162 Session ID: This value is a 128-bit value as defined in the PANA 163 protocol [PANA-PROT], which identifies a particular session of a 164 client. 166 The character "|" denotes concatenation as defined in [IKE]. 168 5.0 IKE and IPsec details 170 IKE [IKE] MUST be used for establishing the IPsec SA. Manual keying 171 may not be possible, as the network does not know all the PaCs that 172 will be authenticating to the network, a priori. Main mode with pre- 173 shared key SHOULD be supported. Aggressive mode with pre-shared key 174 MUST be supported. PaC and EP SHOULD use its IP address as the phase 175 I identifier in main mode and PANA session ID [PANA-PROT] as the 176 payload of ID_KEY_ID in aggressive mode for establishing the phase I 177 SA. An IP address would also work well as an identifier in aggressive 178 mode. But session ID was chosen to avoid potential problems with 179 link-local addresses in IPv6, which are guaranteed to be unique only 180 within the scope of a link. 182 After Phase I SA is established, quick mode exchange is performed to 183 establish an ESP tunnel mode IPsec SA for protecting the traffic 184 between PaC and EP. The next few sections discusses the packet 185 formats and SPD entries. 187 6.0 Packet Formats 189 Following acronyms are used in this section. 191 PANA enabling IPsec based Access Control October 2003 193 EP's address is denoted by EP-ADDR. 194 PaC's address is denoted by PAC-ADDR. 195 The node with which the PaC is communicating is denoted by END-ADDR. 197 Following is the packet format on the wire for packets sent from PaC 198 to EP: 200 IPv4/IPv6 header (source = PAC-ADDR, 201 destination = EP-ADDR) 202 ESP header 203 IPv4/IPv6 header (source = PAC-ADDR, 204 destination = END-ADDR) 206 In case of IPv6, the outer IP header's addresses SHOULD be the link- 207 local address of PaC and EP. 209 Following is the packet format on the wire for packets sent from EP 210 to PaC: 212 IPv4/IPv6 header (source = EP-ADDR, 213 destination = PAC-ADDR) 214 ESP header 215 IPv4/IPv6 header (source = END-ADDR, 216 destination = PAC-ADDR) 218 In case of IPv6, the outer IP header's addresses SHOULD be the link- 219 local address of PaC and EP. 221 7.0 IPsec SPD entries 223 Following acronyms are used in this section. 225 EP's address is denoted by EP-ADDR. 226 PaC's address is denoted by PAC-ADDR. 227 PaC's link-local address is denoted by PAC-LINK-LOCAL 228 PaC's global address is denoted by PAC-GLOBAL-ADDR 229 EP's link-local address is denoted by EP-LINK-LOCAL 231 The SPD entries given below affect the traffic destined to EP-ADDR. 232 If PAA and EP share the same IP address, then the traffic destined to 233 PAA will also be affected. This implies that some of the control 234 traffic, which is already protected using PANA SA will be protected 235 with IPsec also. This can be avoided (if needed) by configuring 236 bypass IPsec policy for packets, which are not shown below. 238 7.1 IPv4 SPD entries 239 PANA enabling IPsec based Access Control October 2003 241 PaC's SPD OUT: 242 IF source = PAC-ADDR & destination = any 243 THEN USE ESP TUNNEL MODE SA: 244 outer source = PAC-ADDR 245 outer destination = EP-ADDR 247 PaC's SPD IN: 248 IF source = any & destination = PAC-ADDR 249 THEN USE ESP TUNNEL MODE SA: 250 outer source = EP-ADDR 251 outer destination = PAC-ADDR 253 EP's SPD OUT: 254 IF source = any & destination = PAC-ADDR 255 THEN USE ESP TUNEL MODE SA: 256 outer source = EP-ADDR 257 outer destination = PAC-ADDR 259 EP's SPD IN: 260 IF source = PAC-ADDR & destination = any 261 THEN USE ESP TUNNEL MODE SA: 262 outer source = PAC-ADDR 263 outer destination = EP-ADDR 265 During the IPsec SA setup, PaC uses PAC-ADDR as its phase 2 identity 266 (IDci) and EP uses ID_IPV4_ADDR_RANGE or ID_IPV4_ADDR_SUBNET as its 267 phase 2 identity. The starting address is zero IP address and the end 268 address is all ones for ID_IPV4_ADDR_RANGE. The starting address is 269 zero IP address and the end address is all zeroes for 270 ID_IPV4_ADDR_SUBNET. 272 7.2 IPv6 SPD entries 274 The IPv6 SPD entries are slightly different from IPv4 to prevent the 275 neighbor/router discovery [IPV6-ND] packets from being protected with 276 IPsec. Due to the current limitation in specifying the proper 277 selectors for neighbor discovery packets, separate set of selectors 278 are added for bypassing IPsec for link-local traffic. All traffic 279 destined to global address is always sent to the default router i.e, 280 the global prefix is not considered to be on-link. In the future, 281 when the IPsec [IPSEC] allows selectors to be based on ICMPv6 types, 282 we just need an entry to bypass IPsec for neighbor/router discovery 283 packets and the rest of the entries will be similar to IPv4 SPD 284 entries. 286 Pac's SPD OUT: 288 IF source = ::/128 & destination = any 289 THEN BYPASS 290 PANA enabling IPsec based Access Control October 2003 292 IF source = fe80::/10 & destination = any 293 THEN BYPASS 295 IF source = any & destination = fe80::/10 296 THEN BYPASS 298 IF source = PAC-GLOBAL-ADDR & destination = any 299 THEN USE ESP TUNNEL MODE SA: 300 outer source = PAC-LINK-LOCAL 301 outer destination = EP-LINK-LOCAL 303 PaC's SPD IN: 305 IF source = ::/128 & destination = any 306 THEN BYPASS 308 IF source = fe80::/10 & destination = any 309 THEN BYPASS 311 IF source = any & destination = fe80::/10 312 THEN BYPASS 314 IF source = any & destination = PAC-GLOBAL-ADDR 315 THEN USE ESP TUNNEL MODE SA: 316 outer source = EP-LINK-LOCAL 317 outer destination = PAC-LINK-LOCAL 319 EP's SPD OUT: 321 IF source = ::/128 & destination = any 322 THEN BYPASS 324 IF source = fe80::/10 & destination = any 325 THEN BYPASS 327 IF source = any & destination = fe80::/10 328 THEN BYPASS 330 IF source = any & destination = PAC-GLOBAL-ADDR 331 THEN USE ESP TUNNEL MODE SA: 332 outer source = EP-LINK-LOCAL 333 outer destination = PAC-LINK-LOCAL 335 EP's SPD IN: 337 IF source = ::/128 & destination = any 338 PANA enabling IPsec based Access Control October 2003 340 THEN BYPASS 342 IF source = fe80::/10 & destination = any 343 THEN BYPASS 345 IF source = any & destination = fe80::/10 346 THEN BYPASS 348 IF source = PAC-GLOBAL-ADDR & destination = any 349 THEN USE ESP TUNNEL MODE SA: 350 outer source = PAC-LINK-LOCAL 351 outer destination = EP-LINK-LOCAL 353 Following the conceptual model in section 5.1 of [IPV6-ND], PaC would 354 maintain the following. 356 1) Neighbor Cache: This contains the entry for the link-local 357 address of EP. 358 2) Destination Cache: This contains the entry for all on-link and 359 off-link destinations. 360 3) Prefix List: This list contains the link-local prefix alone. 361 4) Default Router List: This list contains the EP alone. 363 Note that there are no entries for link-local addresses of other PaCs 364 as it is assumed that communications with other PaCs use global 365 addresses. All packets that are not destined to a link-local address 366 are sent to the default router (EP). This can be achieved by turning 367 off the "L" bit in the router advertisement. 369 During the IPsec SA setup, PaC uses PAC-GLOBAL-ADDR as its phase 2 370 identity (IDci) and EP uses ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET 371 as its phase 2 identity. The starting address is zero IP address and 372 the end address is all ones for ID_IPV6_ADDR_RANGE. The starting 373 address is zero IP address and the end address is all zeroes for 374 ID_IPV6_ADDR_SUBNET. 376 8.0 Double IPsec 378 If the PaC uses IPsec for secure remote access e.g., Corporate VPN 379 access, there will be separate SPD entries protecting the traffic 380 to/from remote network. In this case, IPsec may need to be applied 381 twice, once for protecting the remote access and once for protecting 382 the local access. This is the same as the iterative tunneling 383 discussed in [IPSEC]. 385 When the IPsec SA is established with the remote security gateway, 386 the IKE packets from the PaC to the remote security gateway may or 387 may not need IPsec protection on the local link depending on the 388 PANA enabling IPsec based Access Control October 2003 390 configuration at the EP. If EP requires IPsec protection for all 391 packets, then the PaC should configure SPD entries appropriately so 392 that IKE packets destined to EP are bypassed whereas IKE packets to 393 the remote SG are protected. If EP does not require IPsec protection 394 for IKE packets destined to remote security gateway, it needs to 395 configure SPD entries that would bypass them. This issue of 396 configuring SPD entries for IKE packets is being currently discussed 397 in the IPsec mailing list [IPSEC-ML]. 399 9.0 Security considerations 401 This document discusses the use of IPsec for access control when PANA 402 is used for authenticating the clients to the access network. 404 If the PAA does not verify whether PaC is authorized to use an IP 405 address, it is possible for the PaC to steal the traffic destined to 406 some other PaC. The use of IPsec does not prevent this attack. PAA 407 may use other mechanisms to prevent this attack. 409 When IPv6 is used, the SPD entries bypass all link-local traffic 410 without applying IPsec. This should not be a limitation as the link- 411 local address is used only by link-local services e.g. 412 neighbor/router discovery, which uses a different mechanism to 413 protect their traffic. Moreover, this limitation may not be there in 414 the future if IPsec extends the SPD selectors to specify ICMP types. 416 10.0 Normative References 418 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, 419 RFC 2026, October 1996. 421 [IPSEC] S. Kent et al., "Security Architecture for the Internet 422 Protocol", RFC 2401, November 1998 424 11.0 Informative References 426 [PANAREQ] A. Yegin et al., "Protocol for Carrying Authentication for 427 Network Access (PANA) Requirements and Terminology", draft-ietf- 428 pana-requirements-04.txt 430 [PANA-PROT] D.Fosberg et al., "Protocol for Carrying Authentication 431 for Network Access", draft-ietf-pana-01.txt 433 [PANA-THREATS] M.Parthasarathy, "PANA Threat analysis and security 434 requirements", draft-ietf-pana-threats-eval-04.txt 435 PANA enabling IPsec based Access Control October 2003 437 [KEYWORDS] S. Bradner, "Key words for use in RFCS to indicate 438 requirement levels", RFC 2119, March 1997 440 [IKE] D. Harkins et al., "Internet Key Exchange", RFC 2409, November 441 1998 443 [IPV6-ND] T. Narten et al., "Neighbor Discovery for IP version 6 444 (IPv6) ", RFC 2461, December 1998 446 [EAP-KEY] D.Simon et al., "EAP Key Management Framework", draft- 447 aboba-ppext-key-problem-07.txt 449 [IPSEC-ML] https://roundup.machshav.com/ipsec/, RFC2401bis, Issue 67. 451 [IEEE80211i] IEEE Draft 802.11I/D5.0, "Draft Supplement to STANDARD 452 FOR Telecommunications and Information Exchange between Systems � 453 LAN/MAN Specific Requirements - Part 11: Wireless Medium Access 454 Control (MAC) and physical layer specifications: Specification for 455 Enhanced Security", August 2003. 457 12.0 Acknowledgments 459 The author would like to thank Francis Dupont, Pasi Eronen and other 460 PANA WG members for their valuable comments and discussions. 462 13.0 Revision log 464 Changes between revision 00 and 01 466 -Specified the use of ESP tunnel mode SA instead of IP-IP transport 467 mode SA after working group discussion. 468 -Specified the IKE pre-shared key derivation. 470 14.0 Author's Addresses 472 Mohan Parthasarathy 474 Phone: 408-734-8820 475 Email: mohanp@sbcglobal.net 477 15.0 Full Copyright Statement 479 Copyright (C) The Internet Society (2003). All Rights Reserved. 481 This document and translations of it may be copied and furnished to 482 others, and derivative works that comment on or otherwise explain it 483 or assist in its implementation may be prepared, copied, published 484 and distributed, in whole or in part, without restriction of any 485 PANA enabling IPsec based Access Control October 2003 487 kind, provided that the above copyright notice and this paragraph are 488 included on all such copies and derivative works. However, this 489 document itself may not be modified in any way, such as by removing 490 the copyright notice or references to the Internet Society or other 491 Internet organizations, except as needed for the purpose of 492 developing Internet standards in which case the procedures for 493 copyrights defined in the Internet Standards process must be 494 followed, or as required to translate it into languages other than 495 English. 497 The limited permissions granted above are perpetual and will not be 498 revoked by the Internet Society or its successors or assigns. 500 This document and the information contained herein is provided on an 501 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 502 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 503 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 504 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 505 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 507 Acknowledgement 509 Funding for the RFC Editor function is currently provided by the 510 Internet Society.