idnits 2.17.1 draft-ietf-pana-ipsec-06.txt: -(637): 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): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 780. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 757. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 764. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 770. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 784), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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.) ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [RFC2118], but that reference does not seem to mention RFC 2119 either. -- 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 2005) is 6920 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: 'RFC2118' is mentioned on line 148, but not defined == Unused Reference: 'RFC2119' is defined on line 593, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) -- 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-04 ** Downref: Normative reference to an Informational draft: draft-ietf-pana-threats-eval (ref. 'PANA-THREATS') == Outdated reference: A later version (-10) exists of draft-ietf-pana-framework-01 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-15 == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-rfc2401bis-00 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-02 == Outdated reference: A later version (-17) exists of draft-ietf-zeroconf-ipv4-linklocal-12 Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group 3 Internet Draft M. Parthasarathy 4 Document: draft-ietf-pana-ipsec-06.txt Nokia 5 Expires: November 2005 May 2005 7 PANA Enabling IPsec based Access Control 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at 23 anytime. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). All Rights Reserved. 38 Abstract 40 PANA (Protocol for carrying Authentication for Network Access) is a 41 protocol for authenticating clients to the access network using IP 42 based protocols. The PANA protocol authenticates the client and also 43 establishes a PANA security association between the PANA client and 44 PANA authentication agent at the end of a successful authentication. 45 This document discusses the details for establishing an IPsec 46 security association using the PANA security association for enabling 47 IPsec based access control. 49 Table of Contents 50 1.0 Introduction..................................................2 51 2.0 Keywords......................................................4 52 3.0 Pre-requisites for IPsec SA establisment......................4 53 4.0 IP Address Configuration......................................4 54 5.0 IKE Pre-shared key derivation.................................5 55 6.0 IKE and IPsec details.........................................6 56 7.0 Packet Formats................................................7 57 8.0 IPsec SPD entries.............................................8 58 9.0 Dual Stack Operation.........................................12 59 10.0 Security considerations.....................................12 60 11.0 Normative References........................................12 61 12.0 Informative References......................................13 62 13.0 Acknowledgments.............................................14 63 14.0 Revision log................................................14 64 15.0 Appendix A..................................................15 65 16.0 Author's Addresses..........................................16 66 Intellectual Property Statement..................................16 67 Disclaimer of Validity...........................................17 68 Copyright Statement..............................................17 69 Acknowledgment...................................................17 71 1.0 Introduction 73 PANA (Protocol for carrying Authentication for Network Access) is a 74 protocol [PANA-PROT] for authenticating clients to the access network 75 using IP based protocols. The PANA protocol authenticates the client 76 and also establishes a PANA security association between the PANA 77 client (PaC) and PANA authentication agent (PAA) at the end of 78 successful authentication. The PAA indicates the results of the 79 authentication using the PANA-Bind-Request message wherein it can 80 indicate the access control method enforced by the access network. 81 The PANA protocol [PANA-PROT] does not discuss any details of IPsec 82 [RFC2401] security association (SA) establishment, when IPsec is used 83 for access control. This document discusses the details of 84 establishing an IPsec security association between the PANA client 85 and the enforcement point. The IPsec SA is established using IKE 86 [RFC2409], which in turn uses the pre-shared key derived from the EAP 87 authentication (AAA-Key). The IPsec SA used to protect the packet 88 provides the assurance that the packet comes from the client that 89 authenticated to the network. Thus, the IPsec SA can be used for 90 access control and specifically used to prevent the service theft 91 mentioned in [PANA-THREATS]. The term "access control" in this 92 document refers to the per-packet authentication provided by IPsec. 93 IPsec is used to protect packets flowing between PaC and EP in both 94 directions. 96 Please refer to [PANAREQ] for terminology and definitions of terms 97 used in this document. The PANA framework document [PANA-FRAME] 98 describes the deployment scenarios for IPsec. The following picture 99 illustrates what is being protected with IPsec. The different 100 scenarios of PANA usage are described in the [PANAREQ]. When IPsec is 101 used, scenarios 3 and 5 are supported as shown below. As shown in 102 Figure 1, the Enforcement Point (EP), Access Router (AR) and the PANA 103 authentication agent are co-located which is described as scenario 3 104 in [PANAREQ]. 106 PaC ------------------+ 107 | 108 +---EP/AR/PAA----Intranet/Internet 109 | 110 PaC ------------------+ 112 <-----------IPsec--------> 114 Figure 1: PAA/EP/AR are co-located 116 As show in Figure 2, only the AR and EP are co-located. The PAA is a 117 separate node though located on the same link as the AR and EP. All 118 of them are one IP hop away from the PaC. This is the same as 119 scenario 5 described in [PANAREQ]. 121 PaC ------------------+ 122 | 123 +---PAA 124 | 125 +---EP/AR-----Intranet/Internet 126 | 127 PaC ------------------+ 129 <-----------IPsec--------> 131 Figure 2: EP and AR are co-located 133 The IPsec security association protects the traffic between the PaC 134 and EP. In IPsec terms, the EP is a security gateway (therefore a 135 router) and forwards packets coming from the PaC to other nodes. 137 First, this document discusses some of the pre-requisites for IPsec 138 SA establishment. Next, it gives details on what should be 139 communicated between the PAA and EP. Then, it gives the details of 140 IKE exchange with IPsec packet formats and SPD entries. Finally, it 141 discusses the dual stack operation. 143 2.0 Keywords 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2118]. 149 3.0 Pre-requisites for IPsec SA establisment 151 This document assumes that the following have already happened before 152 the IKE exchange starts. 154 1) The PaC) and PAA mutually authenticate each other using an EAP 155 method that is able to derive a AAA-key [EAP-KEY]. 157 2) The PaC learns the IP address of the Enforcement point (EP) 158 during the PANA exchange. 160 3) The PaC learns that the network uses IPsec [RFC2401] for 161 securing the link between the PaC and EP during the PANA 162 exchange. 164 4.0 IP Address Configuration 166 The IP address configuration is explained in [PANA-FRAME]. Some of 167 the details relevant to IPsec are briefly repeated here for clarity. 168 The PaC configures an IP address before the PANA protocol exchange 169 begins. This address is called a pre-PANA address (PRPA). After a 170 successful authentication, the client may have to configure a post- 171 PANA address (POPA) for communication with other nodes, if PRPA is a 172 local-use (e.g., link-local or private address) or a temporarily 173 allocated IP address. 175 The PRPA of the PaC may be a link-local address [IPV4-LINK] or a 176 private address [RFC1918] or a routable address or an IPv6 link-local 177 address or global address [RFC2462]. Please refer to [PANA-FRAME] for 178 more details on how these addresses may be configured. The PaC would 179 use the PRPA as the outer address of IPsec tunnel mode SA (IPsec- 180 TOA). The PaC also needs to configure an inner address (IPsec-TIA). 181 There are different ways to configure IPsec-TIA. 183 1) Some IPv4 IPsec implementations are known to work properly when 184 the same address is configured as both the IPsec-TIA and IPsec- 185 TOA. When PRPA is a routable address, the PRPA may be used as 186 both the IPsec-TIA and IPsec-TOA and POPA may not be configured. 188 2) In IPv4, an IPsec-TIA can be obtained via the configuration 189 method available using DHCP over IPsec tunnels [RFC3456]. The 190 minor difference from the original usage of [RFC3456] is that 191 the IPsec-TOA does not need to be a routable address when 192 [RFC3456] is used between the PaC and EP. 194 3) When IKEv2 [IKEV2] is used for security association negotiation, 195 the address configuration method available in [IKEV2] can be 196 used for configuring the IPsec-TIA for both IPv4 and IPv6. 198 There are other address configuration methods possible. They have 199 some implementation issues, which are described in the Appendix A. 201 5.0 IKE Pre-shared key derivation 203 If the network chooses IPsec to secure the link between the PaC and 204 EP, the PAA should communicate the IKE pre-shared key (Pac-EP Master 205 Key), Key-Id, the device identifier of the PaC, and the session-Id to 206 the EP before the IKE exchange begins. Whenever the IKE pre-shared 207 key changes due to re-authentication as described below, the new 208 value is computed by the PAA and communicated to the EP with all the 209 other parameters. 211 The IKE exchange between the PaC and PAA is equivalent to the 4-way 212 handshake in [IEEE80211i] following the EAP exchange. The IKE 213 exchange establishes the IPsec SA similar to the pair-wise transient 214 key (PTK) established in [IEEE80211i]. The IKE exchange provides both 215 key confirmation and protected cipher-suite negotiation. 217 The IKE pre-shared key is derived as follows. 219 IKE Pre-shared Key = HMAC-SHA-1 (AAA-Key, "IKE-preshared key" | 220 Session ID | Key-ID | EP-address) 222 The values have the following meaning: 224 AAA-Key: A key derived by the peer and EAP server and transported to 225 the authenticator [EAP-KEY]. 227 Session ID: The value as defined in the PANA protocol [PANA-PROT], 228 identifies a particular session of a client. 230 Key-ID: This identifies the AAA-Key within a given session [PANA- 231 PROT]. During the lifetime of the PANA session, there could be 232 multiple runs of EAP re-authentications. As EAP re-authentication 233 changes the AAA-Key, Key-ID is used to identify the right AAA-Key. 234 This is contained in the Key-ID AVP [PANA-PROT]. 236 EP-address: This is the address of the enforcement point with which 237 the IKE exchange is being performed. When the PAA is controlling 238 multiple EPs, this provides a different pre-shared key for each of 239 the EPs. 241 The character "|" denotes concatenation as defined in [RFC2409]. 243 During EAP re-authentication, the AAA-Key changes. Whenever the AAA- 244 Key changes, a new value of Key-ID is established between the PaC and 245 PAA/EP as defined in [PANA-PROT]. If there is already an IKE SA or 246 IPsec SA established, it MUST continue to be used till it expires. A 247 change in the value of AAA-Key MUST NOT result in re-negotiating a 248 new IKE SA or IPsec SA immediately. The IKE PSK continues to exist 249 even after the AAA-Key from which it is derived expires. When the 250 IPsec SA expires, a new IPsec SA is negotiated without negotiating a 251 new IKE SA. When the IKE SA expires, a new IKE PSK is derived from 252 the latest AAA-key and used in negotiating the IKE SA and IPsec SA. 253 In case where two runs of EAP authentication (NAP/ISP) are performed 254 during a single PANA authentication phase, a AAA-Key is derived from 255 both authentications as specified in the [PANA-PROT]. 257 6.0 IKE and IPsec details 259 IKE [RFC2409] MUST be used for establishing the IPsec SA. The details 260 specified in this document works with IKEv2 [IKEV2] as well as IKE. 261 Any difference between them would be explicitly noted. PANA 262 authenticates the client and network, and derives the keys to protect 263 the traffic. Hence, manual keying cannot be used. If IKE is used, 264 aggressive mode with pre-shared key MUST be supported. The PaC and EP 265 SHOULD use the following value in the payload of the ID_KEY_ID to 266 identify the pre-shared key. 268 ID_KEY_ID data = (Session-Id | Key-Id) 270 The Session-Id and Key-Id are the values contained in the data 271 portion of the Session-Id and Key-Id AVP respectively [PANA-PROT]. 272 They are concatenated to form the content of ID_KEY_ID data. IP 273 addresses cannot be used as identifier as the same PaC or different 274 PaC may use the same IP address across a PANA session. For the same 275 reason, main mode of IKE cannot be used, as it requires addresses to 276 be used as identifiers. 278 If IKE is used, a quick mode exchange is performed to establish an 279 ESP tunnel mode IPsec SA for protecting the traffic between the PaC 280 and EP. In IKEv2, the initial exchange (IKE_SA_INIT and IKE_AUTH) 281 creates the IPsec SA also. The identities (traffic selectors in 282 IKEv2) used during Phase 2 are explained in the next section. As 283 mentioned in section 4.0, an address (POPA) may also have to be 284 configured. The address configuration method to be used by the PaC is 285 indicated in the PANA-Bind-Request message at the end of the 286 successful PANA authentication. The PaC chooses the appropriate 287 method and replies back in PANA-Bind-Answer message. 289 7.0 Packet Formats 291 Following acronyms are used throughout this document. 293 PAC-TIA denotes the IPsec-TIA used by the PaC. PAC-TIA may be set to 294 a PRPA when the same PRPA is used as the IPsec-TIA and IPsec-TOA on 295 the PaC. Otherwise, PAC-TIA is set to the POPA. 297 PAC-TOA denotes the IPsec-TOA used by the PaC. 299 EP-ADDR denotes the address of the EP. 301 The node with which the PaC is communicating is denoted by END-ADDR. 303 Following is the IPv4 packet format on the wire for packets sent from 304 the PaC to the EP: 306 IPv4 header (source = PAC-TOA, 307 destination = EP-ADDR) 308 ESP header 309 IPv4 header (source = PAC-TIA, 310 destination = END-ADDR) 312 Following is the IPv6 packet format on the wire for packets sent from 313 the PaC to the EP: 315 IPv6 header (source = PAC-TOA, 316 destination = EP-ADDR) 317 ESP header 318 IPv6 header (source = PAC-TIA, 319 destination = END-ADDR) 321 Following is the IPv4 packet format on the wire for packets sent from 322 the EP to the PaC: 324 IPv4 header (source = EP-ADDR, 325 destination = PAC-TOA) 326 ESP header 327 IPv4 header (source = END-ADDR, 328 destination = PAC-TIA) 330 Following is the IPv6 packet format on the wire for packets sent from 331 the EP to the PaC: 333 IPv6 header (source = EP-ADDR, 334 destination = PAC-TOA) 335 ESP header 336 IPv6 header (source = END-ADDR, 337 destination = PAC-TIA) 339 8.0 IPsec SPD entries 341 The SPD entries for IPv4 and IPv6 are specified separately as they 342 are different. All the SPD entries described below are dynamically 343 created. When the same address is used as IPsec-TIA and IPsec-TOA, 344 the EP can add the entry to the SPD before the IKE exchange starts, 345 as it knows the address a priori. When IKEv2 [IKEV2] or [RFC3456] is 346 used for address configuration, the SPD entry cannot be created until 347 the IPsec SA is successfully negotiated as the address is not known a 348 priori. This is very similar to the road warrior case described in 349 [IPSEC-BIS]. In this case, an SPD entry with a name selector is used 350 and when the IPsec SA is successfully negotiated, a new SPD entry is 351 created with the appropriate addresses. The name used here could be 352 the contents of ID_KEY_ID payload. The SPD entries shown below are 353 the entries that are added after the successful IPsec SA negotiation. 355 In environments where the PaC is a router, the IPsec-TIA can be a 356 range of addresses (prefix) instead of a single host address. The PaC 357 acts like a security gateway in this case establishing the IPsec SA 358 with another security gateway (EP). This scenario is supported by 359 [RFC2401] and [IPSEC-BIS]. It is assumed that the PaC obtains the 360 prefix through other mechanisms not defined in this document. When 361 the IPsec SA is negotiated, the prefix is carried in the traffic 362 selectors. 364 The SPD entries shown here affect the flow of data traffic, which 365 includes neighbor discovery messages for IPv6. The SPD entries in the 366 PaC protect all the traffic with source address set to IPsec-TIA. 367 When IPsec-TIA and IPsec-TOA are the same (as discussed in section 368 4.0), the PANA traffic also gets protected with IPsec. The PANA 369 traffic destined to the PAA from the PaC is forwarded to PAA after 370 decrementing the TTL in the IP header. The PAA would drop the packet 371 if the TTL is not 255. Hence, we need explicit entries to bypass 372 IPsec protection for PANA traffic on PaC. This may not be needed 373 always for traffic going from PAA to PaC. If PAA and EP are not co- 374 located, PAA would send traffic directly to PaC without going through 375 EP. Hence, EP does not need to have SPD entries to bypass IPsec in 376 this case. If PAA and EP are co-located, the PANA packets will be 377 protected with IPsec only if the IPsec-TIA and IPsec-TOA are same. 378 Hence, we need explicit entries to bypass IPsec protection when PAA 379 and EP are co-located. 381 If source_port = PANA_PORT OR dest_port = PANA_PORT 382 THEN BYPASS 384 PANA_PORT is the IANA assigned (TBD) PANA protocol number [PANA- 385 PROT]. There may be other protocols that expect the TTL to be 255 386 whose SPD entries are not shown here. Also, when the PaC is using 387 IPsec for remote access, there may be additional SPD entries and 388 IPsec security associations, which are not discussed in this 389 document. 391 8.1 IPv4 SPD entries 393 PaC's SPD OUT: 395 IF source_port = PANA_PORT OR dest_port = PANA_PORT 396 THEN BYPASS 398 IF source = PAC-TIA & destination = any 399 THEN USE ESP TUNNEL MODE SA: 400 outer source = PAC-TOA 401 outer destination = EP-ADDR 403 PaC's SPD IN: 405 IF source_port = PANA_PORT OR dest_port = PANA_PORT 406 THEN BYPASS 408 IF source = any & destination = PAC-TIA 409 THEN USE ESP TUNNEL MODE SA: 410 outer source = EP-ADDR 411 outer destination = PAC-TOA 413 EP's SPD OUT: 415 IF source_port = PANA_PORT OR dest_port = PANA_PORT 416 THEN BYPASS 418 IF source = any & destination = PAC-TIA 419 THEN USE ESP TUNEL MODE SA: 420 outer source = EP-ADDR 421 outer destination = PAC-TOA 423 EP's SPD IN: 425 IF source_port = PANA_PORT OR dest_port = PANA_PORT 426 THEN BYPASS 428 IF source = PAC-TIA & destination = any 429 THEN USE ESP TUNNEL MODE SA: 431 outer source = PAC-TOA 432 outer destination = EP-ADDR 434 During the IPsec SA setup, the PaC uses PAC-TIA as its phase 2 435 identity (IDci) and EP uses ID_IPV4_ADDR_RANGE or ID_IPV4_ADDR_SUBNET 436 as its phase 2 identity. The starting address is zero IP address and 437 the end address is all ones for ID_IPV4_ADDR_RANGE. The starting 438 address is zero IP address and the end address is all zeroes for 439 ID_IPV4_ADDR_SUBNET. 441 8.2 IPv6 SPD entries 443 The IPv6 SPD entries are slightly different from IPv4 to prevent the 444 neighbor and router discovery [RFC2461] packets from being protected 445 with IPsec. The first three entries of the following SPD entries 446 bypass IPsec protection for neighbor and router discovery packets. 447 The latest version of the IPsec [IPSEC-BIS] document allows traffic 448 selectors to be based on ICMPv6 type and code values. In that case, 449 the first three entries can be based on ICMPv6 type and code values. 451 Pac's SPD OUT: 453 IF source = ::/128 & destination = any 454 THEN BYPASS 456 IF source = fe80::/10 & destination = any 457 THEN BYPASS 459 IF source = any & destination = fe80::/10 460 THEN BYPASS 462 IF source_port = PANA_PORT OR dest_port = PANA_PORT 463 THEN BYPASS 465 IF source = PAC-TIA & destination = any 466 THEN USE ESP TUNNEL MODE SA: 467 outer source = PAC-TOA 468 outer destination = EP-ADDR 470 PaC's SPD IN: 472 IF source = ::/128 & destination = any 473 THEN BYPASS 475 IF source = fe80::/10 & destination = any 476 THEN BYPASS 478 IF source = any & destination = fe80::/10 479 THEN BYPASS 480 IF source_port = PANA_PORT OR dest_port = PANA_PORT 481 THEN BYPASS 483 IF source = any & destination = PAC-TIA 484 THEN USE ESP TUNNEL MODE SA: 485 outer source = EP-ADDR 486 outer destination = PAC-TOA 488 EP's SPD OUT: 490 IF source = ::/128 & destination = any 491 THEN BYPASS 493 IF source = fe80::/10 & destination = any 494 THEN BYPASS 496 IF source = any & destination = fe80::/10 497 THEN BYPASS 499 IF source_port = PANA_PORT OR dest_port = PANA_PORT 500 THEN BYPASS 502 IF source = any & destination = PAC-TIA 503 THEN USE ESP TUNNEL MODE SA: 504 outer source = EP-ADDR 505 outer destination = PAC-TOA 507 EP's SPD IN: 509 IF source = ::/128 & destination = any 510 THEN BYPASS 512 IF source = fe80::/10 & destination = any 513 THEN BYPASS 515 IF source = any & destination = fe80::/10 516 THEN BYPASS 518 IF source_port = PANA_PORT OR dest_port = PANA_PORT 519 THEN BYPASS 521 IF source = PAC-TIA & destination = any 522 THEN USE ESP TUNNEL MODE SA: 523 outer source = PAC-TOA 524 outer destination = EP-ADDR 525 During the IPsec SA setup, the PaC uses PAC-TIA as its phase 2 526 identity (IDci) and the EP uses ID_IPV6_ADDR_RANGE or 527 ID_IPV6_ADDR_SUBNET as its phase 2 identity. The starting address is 528 zero IP address and the end address is all ones for 529 ID_IPV6_ADDR_RANGE. The starting address is zero IP address and the 530 end address is all zeroes for ID_IPV6_ADDR_SUBNET. 532 9.0 Dual Stack Operation 534 IKEv2 [IKEV2] can enable configuration of IPsec-TIA for both IPv4 and 535 IPv6 TIAs by sending both IPv4 and IPv6 configuration attributes in 536 the configuration request (CFG-REQUEST). This enables use of single 537 IPsec tunnel mode SA for sending both IPv4 and IPv6 traffic. 538 Therefore, IKEv2 is recommended for handling dual-stack PaCs where 539 single execution of IKE is desired. 541 10.0 Security considerations 543 This document discusses the use of IPsec for access control when PANA 544 is used for authenticating the clients to the access network. 546 The aggressive mode in IKE [RFC2409] is considered bad due to its DoS 547 properties i.e., any attacker can bombard IKE aggressive mode packets 548 making the EP perform heavy diffie-hellman calculations. As the 549 ID_KEY_ID can be verified by the EP before doing the diffie-hellman 550 calculation, it prevents random attacks. The attacker now needs to 551 listen on the traffic between PaC and PAA to originate IKE requests 552 with valid ID_KEY_ID. 554 If the EP does not verify whether the PaC is authorized to use an IP 555 address, it is possible for the PaC to steal the traffic destined to 556 some other PaC. When IKEv2 [IKEV2] and [RFC3456] are used for address 557 configuration, the address is assigned by the EP and hence this 558 attack is not present in such cases. When the same address is used as 559 both IPsec-TIA and IPsec-TOA, the EP creates the SPD entry with the 560 appropriate address for the PaC and hence the address is verified 561 implicitly by the virtue of successful IPsec SA negotiation. 563 When IPv6 is used, the SPD entries bypass all link-local traffic 564 without applying IPsec. This should not be a limitation as the link- 565 local address is used only by link-local services e.g. neighbor and 566 router discovery, which could use [SEND] to protect their traffic. 567 Moreover, this limitation may not be there in the future if IPsec 568 extends the SPD selectors to specify ICMP types. 570 11.0 Normative References 572 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, 573 RFC 2026, October 1996. 575 [RFC2401] S. Kent et al., "Security Architecture for the Internet 576 Protocol", RFC 2401, November 1998 578 [PANA-PROT] D. Fosberg et al., "Protocol for Carrying Authentication 579 for Network Access", draft-ietf-pana-05.txt 581 [PANA-THREATS] M. Parthasarathy, "PANA Threat analysis and security 582 requirements", draft-ietf-pana-threats-eval-04.txt 584 12.0 Informative References 586 [PANAREQ] A. Yegin et al., "Protocol for Carrying Authentication for 587 Network Access (PANA) Requirements and Terminology", draft-ietf- 588 pana-requirements-09.txt 590 [PANA-FRAME] P. Jayaraman et al., "PANA Framework", draft-ietf-pana- 591 framework-01.txt 593 [RFC2119] S. Bradner, "Key words for use in RFCS to indicate 594 requirement levels", RFC 2119, March 1997 596 [RFC2409] D. Harkins et al., "Internet Key Exchange", RFC 2409, 597 November 1998 599 [IKEV2] C. Kauffman et al., "Internet Key Exchange(IKEv2) Protocol", 600 draft-ietf-ipsec-ikev2-15.txt 602 [IPSEC-BIS] S. Kent, "Security Architecture for the Internet 603 Protocol", draft-ietf-ipsec-rfc2401bis-00.txt 605 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 606 March 1997 608 [RFC3456] B. Patel et al., "Dynamic Host Configuration Protocol 609 (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 610 2003 612 [RFC3315] R. Droms et. al, "Dynamic Host Configuration Protocol for 613 IPv6", RFC 3315, July 2003 615 [RFC2461] T. Narten et al., "Neighbor Discovery for IP version 6 616 (IPv6) ", RFC 2461, December 1998 618 [RFC2462] S. Thomson et. al, "IPv6 Stateless Address 619 Autoconfiguration", RFC 2462, December 1998 621 [RFC3041] T. Narten et al., "Privacy Extensions for Stateless Address 622 Autoconfiguration in IPv6", RFC 3041, January 2001 624 [EAP-KEY] D. Simon et al., "EAP Key Management Framework", draft- 625 ietf-eap-keying-02.txt 627 [SEND] J. Arkko et al., "Secure Neighbor Discovery", draft-ietf-send- 628 ndopt-06.txt 630 [IPV4-LINK] B. Aboba et al., "Dynamic configuration of Link-local 631 IPv4 addresses", draft-ietf-zeroconf-ipv4-linklocal-12.txt 633 [RFC1918] Y. Rekhter et al., "Address Allocation for Private 634 Internets", BCP 5, RFC 1918, February 1996 636 [IEEE80211i] IEEE Draft 802.11I/D5.0, "Draft Supplement to STANDARD 637 FOR Telecommunications and Information Exchange between Systems � 638 LAN/MAN Specific Requirements - Part 11: Wireless Medium Access 639 Control (MAC) and physical layer specifications: Specification for 640 Enhanced Security", August 2003. 642 13.0 Acknowledgments 644 The author would like to thank Francis Dupont, Pasi Eronen, Yoshihiro 645 Ohba, Jari Arkko, Hannes Tschofenig, Alper Yegin, Erik Nordmark, 646 Giaretta Gerardo, Rafa Marin Lopez, Tero Kivinen and other PANA WG 647 members for their valuable comments and discussions. 649 14.0 Revision log 651 Changes between revision 05 and 06 653 -Clarified that PRPA can be a global address also in IPv6. 655 Changes between revision 04 and 05 657 -working group last call comments (mostly editorial) 659 Changes between revision 03 and 04 661 -Comments from Erik Nordmark (mostly editorial) 663 Changes between revision 02 and 03 665 -Clarified the use of key-Id in ID_KEY_ID payload 666 -Clarified the address configuration issues. 667 -Added an Appendix to clarify implementation issues. 669 Changes between revision 01 and 02 671 -Updated the draft with the fixes for all open issues 672 -Added the IP configuration section 673 -Modified the IKE pre-shared key derivation to handle PAA controlling 674 multiple EPs 675 -Clarification regarding DHCP usage and RFC3456 usage. 676 -Only aggressive mode to be supported. Main mode not needed anymore. 678 Changes between revision 00 and 01 680 -Specified the use of ESP tunnel mode SA instead of IP-IP transport 681 mode SA after working group discussion. 682 -Specified the IKE pre-shared key derivation. 684 15.0 Appendix A 686 This section describes the alternate address configuration methods 687 for Post-PANA address (POPA) and the issues associated with it. As 688 mentioned in section 4, there are multiple ways by which the PaC may 689 configure the POPA address. Only [IKEV2] and [RFC3456] address 690 configuration methods were described in section 4. Other 691 possibilities and the issues are as follows. 693 1) Some IKEv1 implementations support IKEv1 MODECFG for configuring 694 IP address. There is no RFC describing MODECFG feature of IKEv1. 695 Also, there is not much information on its widespread support 696 among the implementations. Hence, this document does not 697 recommend it. 699 2) The address may also be obtained using DHCP [RFC2131] [RFC3315] 700 before the IKE exchange starts. Normally the implementations 701 associate the address and other configuration information (e.g., 702 the default router address) with the interface on which the DHCP 703 is performed. This can cause problems with implementations if 704 they attempt to use an IP address that is configured via 705 [RFC2131] [RFC3315] on the physical interface and use it as the 706 IPsec-TIA on the IPsec tunnel interface. This may work without 707 problems when the IPsec-TIA and IPsec-TOA are same as the IPv4 708 PRPA that was obtained using DHCP, as the source address 709 selection has to deal with just one address. But using an IPv4 710 IPsec-TOA different than the IPsec-TIA on a single interface may 711 cause source address selection problem, as there is more than 712 one address to be dealt with. Similarly, an IPv6 address 713 obtained and maintained through a physical link but used on a 714 tunnel interface requires additional implementation 715 considerations. Therefore, this document does not handle the 716 case where DHCP is used to acquire an address for the IPsec-TIA 717 that is different from the IPsec-TOA. Note that this case is 718 different from the address configuration using [RFC3456], which 719 also uses DHCP. When [RFC3456] is used, DHCP is run over the 720 IPsec tunnel and the address (IPsec-TIA) is typically assigned 721 to the IPsec tunnel interface. The IPsec-TOA is assigned to the 722 physical interface. As there is only one address on each 723 interface, there are no address selection issues. 725 3) The address may also be obtained using auto-configuration 726 [RFC2461] including the temporary addresses described in 727 [RFC3041]. The problem described above for DHCP applies to this 728 also. The implementations would associate the auto-configured 729 addresses and the default router with the interface on which the 730 router advertisement was received. As we configure the SPD to 731 bypass IPsec for router discovery and neighbor discovery 732 messages, the address would be associated with the physical 733 interface and not with the IPsec interface. There is also an 734 additional issue, as the address configured by the PaC is not 735 known to the EP. It needs to trust whatever PaC provides in its 736 traffic selector during the IPsec SA negotiation. This leads to 737 a DoS attack where the PaC can steal some other PaC's address, 738 which cannot be prevented unless [SEND] is deployed. 740 16.0 Author's Addresses 742 Mohan Parthasarathy 743 313 Fairchild Drive 744 Mountain View CA-94043 746 Email: mohanp@sbcglobal.net 748 Intellectual Property Statement 750 The IETF takes no position regarding the validity or scope of any 751 Intellectual Property Rights or other rights that might be claimed to 752 pertain to the implementation or use of the technology described in 753 this document or the extent to which any license under such rights 754 might or might not be available; nor does it represent that it has 755 made any independent effort to identify any such rights. Information 756 on the procedures with respect to rights in RFC documents can be 757 found in BCP 78 and BCP 79. 759 Copies of IPR disclosures made to the IETF Secretariat and any 760 assurances of licenses to be made available, or the result of an 761 attempt made to obtain a general license or permission for the use of 762 such proprietary rights by implementers or users of this 763 specification can be obtained from the IETF on-line IPR repository at 764 http://www.ietf.org/ipr. 766 The IETF invites any interested party to bring to its attention any 767 copyrights, patents or patent applications, or other proprietary 768 rights that may cover technology that may be required to implement 769 this standard. Please address the information to the IETF at 770 ietf-ipr@ietf.org. 772 Disclaimer of Validity 774 This document and the information contained herein are provided on an 775 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 776 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 777 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 778 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 779 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 780 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 782 Copyright Statement 784 Copyright (C) The Internet Society (2005). 786 This document is subject to the rights, licenses and restrictions 787 contained in BCP 78, and except as set forth therein, the authors 788 retain all their rights. 790 Acknowledgment 792 Funding for the RFC Editor function is currently provided by the 793 Internet Society.