idnits 2.17.1 draft-laganier-ike-ipv6-cga-02.txt: 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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 692. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 698. ** Found boilerplate matching RFC 3979, Section 5, paragraph 3 (on line 698), which is fine, but *also* found old RFC 2026, Section 10.4B text on line 606. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 148: '... (i.e., ::0/0) SHOULD be protected b...' RFC 2119 keyword, line 155: '...GA enabled Security Gateway MUST prove...' RFC 2119 keyword, line 163: '...wer 64 bits of the hash MUST match the...' RFC 2119 keyword, line 165: '... data structure MUST be the same as t...' RFC 2119 keyword, line 169: '... the responder MUST verify the chall...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3979, Section 5, paragraph 1 boilerplate, a section with a similar start was also found: The IETF takes no position regarding the validity or scope of intellectual property or other rights that might be claimed pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. == In addition to RFC 3979, Section 5, paragraph 3 boilerplate, a section with a similar start was also found: The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Beside the address-proof-of ownership, gateways (GW_i and GW_r) SHOULD mutually prove themselves that they had been authorized to act as CGA enabled Security Gateways for the initiator's or responder's CGA (respectively). This could be solved with the authorization certificates, eg. initiator could issue certificate to GW_i to allow GW_i to be its CGA enabled Security Gateway. However, authorization certificates SHOULD not be used for this purpose because of the incompliance with the IKEv2 spec and CGA spec. Both specifications require use of the X.509 Certificate -Signature. This issue SHOULD be rather solved with making use of PAD database to store additional authentication and authorization parameters (TBD). -- 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 (July 8, 2007) is 6135 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) ** Obsolete normative reference: RFC 4306 (ref. '1') (Obsoleted by RFC 5996) == Outdated reference: A later version (-07) exists of draft-ietf-btns-prob-and-applic-05 ** Downref: Normative reference to an Informational draft: draft-ietf-btns-prob-and-applic (ref. '3') Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Laganier 3 Internet-Draft DoCoMo Euro-Labs 4 Expires: January 9, 2008 G. Montenegro 5 Microsoft Corporation 6 A. Kukec 7 University of Zagreb 8 July 8, 2007 10 Using IKE with IPv6 Cryptographically Generated Addresses 11 draft-laganier-ike-ipv6-cga-02 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 9, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document describes IKEv2 peer authentication via IPv6 45 Cryptographically Generated Addresses (CGA). This techincque have 46 been proposed to solve several security issues in the absence of any 47 centralized trusted security infrastructure and without any pre- 48 arrangements, to provide IPSec self-evident authentication mode 49 between IPv6 nodes or security gateways. 51 Table of Contents 53 1. Introduction and Problem Statement . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Node Configuration and Requirements . . . . . . . . . . . . . 5 56 4. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 7 57 4.1. IPsec Transport Mode with self-evident authentication . . 7 58 4.2. IPSec Tunnel Mode with self-evident authentication . . . . 8 59 5. IKEv2 Payload usage and requirements . . . . . . . . . . . . . 11 60 5.1. Identification Payload . . . . . . . . . . . . . . . . . . 11 61 5.2. Certificate Payload . . . . . . . . . . . . . . . . . . . 11 62 5.3. Certificate Request Payload . . . . . . . . . . . . . . . 11 63 5.4. Authentication Payload . . . . . . . . . . . . . . . . . . 12 64 5.5. Traffic Selector Payload . . . . . . . . . . . . . . . . . 12 65 6. IKE_AUTH validation . . . . . . . . . . . . . . . . . . . . . 13 66 6.1. IPSec Transport Mode with self-evident authentication . . 13 67 6.2. IPSec Tunnel Mode with self-evident authentication . . . . 14 68 7. Comparation with Better Than Nothing Security (BTNS) . . . . . 15 69 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 71 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18 72 11. Intellectual Property Rights Considerations . . . . . . . . . 19 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 74 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 75 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 77 Intellectual Property and Copyright Statements . . . . . . . . . . 22 79 1. Introduction and Problem Statement 81 This document describes how to use IKEv2 with IPv6 Cryptographically 82 Generated Address (CGA). The use of CGA provides authentication for 83 IKEv2 based on the address-proof-of-ownership. It requires only 84 slight modification of IKEv2 protocol and provides self-evident 85 authentication between previously unknown IPv6 nodes and/or gateways. 87 CGAs have been proposed to solve several security issues in the 88 absence of any centralized trusted security infrastructure and 89 without any pre-arrangements, for example, securing Binding Updates 90 in Mobile IPv6, securing Neighbor Discovery for IPv6, securing IPv6 91 multihoming protocol - SHIM6, and securing Group Membership in 92 Multicast and Anycast communications. 94 Until now, the deployment of IPSec has been severely limited because 95 it constrains IP nodes to have either a pre-shared key or a common 96 trusted root (e.g., a PKI infrastructure). Thus, the lack of a 97 global, Internet-wide, trusted infrastructure has precluded a 98 straightforward application of IPsec between any two previously 99 unknown nodes. CGA provides an alternative for Security Association 100 establishment that does not require using a centralized 101 infrastructure or prearrangements. This approach is similar to [4]. 103 From the point of view of implementation effort, the fact that this 104 approach only requires the addition of stand-alone CGA validation 105 routines into existing IKEv2 daemons (e.g. racoon2, pluto, ikev2, 106 etc) is another considerable advantage. 108 This note is organized as follows: we will first describe related 109 work and some usage scenarios for a CGA-enabled peer authentication 110 within an IKEv2 exchange, then we will enumerate requirements for 111 those IKEv2 payloads that need it, and finally, describe precisely 112 how to perform the IKE_AUTH exchange. Accordingly, this note 113 presents an overview of how to use the Internet Key Exchange version 114 2 protocol [1] while one or both peers authenticate themselves via 115 CGA proof-of-ownership. This document details the slight 116 modifications needed. Additionally, it aims at capturing the current 117 thinking about how to achieve proof-of-ownership in IKEv2 via CGA in 118 a standard manner, thus preventing subsequent conflicting 119 definitions. Currently, it has still some open aspects/issues. 121 2. Terminology 123 Cryptographically Generated Address (CGA): An adress which is 124 generated in accordance with [2]. Any crypto address used must be 125 generated as a CGA. 127 CGA enabled Node: An IPv6 node that has one CGA configured as its 128 IPv6 address and posseses related CGA Parameters structure, as well 129 as the private key. For such nodes we use terms initiator and 130 responder. CGA enabled Nodes are present both in the transport 131 scenario and tunnel scenario. 133 CGA enabled Security Gateway: An IPv6 enabled IPsec security gateway 134 which applies tunnel mode CGA Security Policy (CGA SP), either in the 135 net to net scenario or in the endpoint to net scenario. It posseses 136 CGA and related CGA Paramateres data structure. We use mark GW_i for 137 the initiator's CGA enabled Security Gateway and GW_r for the 138 responder's CGA enabled Security Gateway. 140 Self-evident authentication mode: It denotes the use of IPSec/IKEv2 141 between previously unknown CGA enabled nodes and/or CGA enabled 142 gateways. The IKEv2 Security Association establishment in case of 143 self-evident authentication mode of IPSec does not require any pre- 144 arrangements nor trusted security infrastructure. 146 CGA Security Policy (CGA SP): A CGA Security Policy is a Security 147 Policy that specifies that traffic towards any outbound destination 148 (i.e., ::0/0) SHOULD be protected by IPsec, either transport mode or 149 tunnel mode (transport mode for securing end-to-end traffic between 150 two nodes and tunnel mode for securing traffic between two CGA 151 enabled Security Gateways, while in transit in the public internet). 153 3. Node Configuration and Requirements 155 Each CGA enabled Node and CGA enabled Security Gateway MUST prove 156 address ownership of its CGA. CGA has to be generated and verified 157 against CGA Parameters data structure as described in [2]. The CGA 158 authentication procedure includes the following steps: 160 1. The verification of binding between the CGA and the proposed 161 public key/CGA Parameters data structure. Peer has to verify: a) 162 the produced hash of the CGA Parameters data structure, b) the 163 prefix of the CGA. The lower 64 bits of the hash MUST match the 164 iid of the CGA. Also, the prefix contained in the CGA Parameters 165 data structure MUST be the same as the prefix in the CGA. 167 2. The verification that the peer's private key corresponds to the 168 public key from the CGA Parameters data structure. For example, 169 the responder MUST verify the challenge signed with the 170 initiator's private key with the initiator's public key received 171 in the CGA Parameters data structure. 173 Succesfull verification denotes that the public key in the CGA 174 parameters is the authentic public key used to generate CGA. Both 175 CGA enabled Nodes and CGA enabled Security Gateways use their CGA as 176 IKEv2 identities. 178 Thus, each CGA enabled Node and Security Gateway generate a RSA 179 public (PK) - private (SK) key pair in accordance with Internet X.509 180 certificate profile (rfc3280). Usually, keys will be generated 181 together with the self-signed X.509 certificate. 183 The following requirements are related to tunnel mode scenarios and 184 are actually open issues: 186 Beside the check of the PK-CGA binding of peer GW's CGA, each CGA 187 enabled Security Gateway SHOULD verify also the initiator's and 188 responder's PK-CGA binding. In that case, gateways need to 189 exchange CGA Parameters related to initiator's and responder's 190 CGA. The PAD database could be used to store the initiator's/ 191 responder's CGA Parameters (TBD). Those CGA Parameters could be 192 exchanged in the IKE_AUTH exchange (TBD). 194 Beside the address-proof-of ownership, gateways (GW_i and GW_r) 195 SHOULD mutually prove themselves that they had been authorized to 196 act as CGA enabled Security Gateways for the initiator's or 197 responder's CGA (respectively). This could be solved with the 198 authorization certificates, eg. initiator could issue certificate 199 to GW_i to allow GW_i to be its CGA enabled Security Gateway. 200 However, authorization certificates SHOULD not be used for this 201 purpose because of the incompliance with the IKEv2 spec and CGA 202 spec. Both specifications require use of the X.509 Certificate - 203 Signature. This issue SHOULD be rather solved with making use of 204 PAD database to store additional authentication and authorization 205 parameters (TBD). 207 4. Usage Scenarios 209 CGA authentication within an IKEv2 exchange can be applied in several 210 different usage scenarios. The following sections describe some of 211 these scenarios while emphasizing on easiness of Security Policy 212 configuration. 214 Self-evident authentication mode for IPSec bootstraps an IPsec 215 Security Association between two previously unknown nodes. Some 216 schemes have been proposed to achieve this goal: FreeS/WAN 217 Opportunistic IPsec uses the standard IKE protocol and DNS queries to 218 retrieve IKE peers' public keys. While these schemes certainly allow 219 to bootstrap such an SA, we argue that it is not convenient to rely 220 on upper layer infrastructure (e.g., DNS) to secure the network 221 layer. This causes cyclic dependencies that ends up in a chicken- 222 and-egg problem: DNS is carried over {TCP|UDP}/IP and a related 223 Security Policy should require that this traffic be protected as 224 well, thus requiring Opportunistic negotiation to secure needed KEY 225 RR lookups. On the other hand, a CGA-based scheme achieves true 226 independence because the security gateways can discover each other 227 and verify authorization by relying solely on IP infrastructure. 229 While the supported IKEv2 identites are IPv4 addresses, IPv6 230 addresses, FQDN, email addresses, X.500 Distinguished Name, X.500 231 General Name and vendor-specific identity, the self-evident 232 authentication mode of IPSec provides the possibility to identify 233 with IPv6 address or FQDN. In case of FQDN identity, the DNBS would 234 provide the binding between the FQDN and the IPv6 address and then 235 the CGA would provide the binding between the IPv6 address and the 236 crypto material. 238 In the rest of the section, we describe the following three 239 application scenarios: transport mode, tunnel mode gateway to gateway 240 and tunnel mode node to gateway. 242 4.1. IPsec Transport Mode with self-evident authentication 244 IPSec Transport Mode with the self-evident authentication secures 245 end-to-end communications between any two previously unknown CGA 246 enabled Nodes and thus provides any-to-any trust relationships. For 247 instance, let's assume that initiator initially wants to send a data 248 packet to responder. Transport Mode CGA SP requires protection of 249 this data packet. As no trust relationship exists between initiator 250 and responder prior to this, they needs to establish a Transport Mode 251 IPsec Security Association. 253 [initiator]<=i=p=s=e=c==t=r=a=n=s=p=o=r=t=>[responder] 254 Bootstrapping an IPsec SA between two CGA enabled Nodes is 255 straightforward: the two peers merely prove ownership of their CGA's 256 while performing the IKEv2 exchange, and configure negotiated IPsec 257 SA's. 259 A typical Transport Mode CGA SP policy should look like that: 261 INBOUND: 263 ::0/0[ike] -> cga_addr/128[any] udp bypass 265 ::0/0[any] -> cga_addr/128[ike] udp bypass 267 ::0/0[any] -> cga_addr/128[any] any require (ipsec/ah/esp/ 268 transport) 270 OUTBOUND: 272 cga_addr/128[any] -> ::0/0[ike] udp bypass 274 cga_addr/128[ike] -> ::0/0[any] udp bypass 276 cga_addr/128[any] -> ::0/0[any] any require (ipsec/ah/esp/ 277 transport) 279 4.2. IPSec Tunnel Mode with self-evident authentication 281 IPSec Tunnel Mode with self-evident authentication is used to secure 282 communications between two CGA enabled nodes (initiator and 283 responder), while this traffic is in transit between their gateways 284 (GW_i and GW_r). 286 [initiator]<---[GW_i]<=i=p=s=e=c==t=u=n=n=e=l=>[GW_r]--->[responder] 288 Bootstrapping a tunnel mode IPsec SA between two CGA enabled nodes is 289 not as straightforward as it is for transport mode, because (1) the 290 GW_r needs to be discovered by the GW_i, and (2) both GW_i and GW_r 291 need to be authorized by the source and destination CGA's 292 respectively of the data packet that initially triggered this 293 exchange. Thus, a Tunnel Mode CGA SP always contains an entry with 294 the unspecified IPv6 address (i.e., ::0) as a placeholder for both 295 tunnel endpoints (local and remote). If we denote by NetworkPrefix/ 296 pflen the network prefix and associated length where initiator 297 resides, a typical Tunnel Mode CGA SP should look like that on the 298 interface of GW_i attached to the Internet: 300 INBOUND: 302 ::0/0[ike] -> GW_i/128[any] udp bypass 304 ::0/0[any] -> GW_i/128[ike] udp bypass 306 ::0/0[any] -> NetworkPrefix/pflen[any] any require (ipsec/ah/esp/ 307 tunnel=::0->::0) 309 OUTBOUND: 311 GW_i/128[any] -> ::0/0[ike] udp bypass 313 GW_i/128[ike] -> ::0/0[any] udp bypass 315 NetworkPrefix/pflen[any] -> ::0/0[any] any require (ipsec/ah/esp/ 316 tunnel=::0->::0) 318 GW_i can discover GW_r by initiating the IKEv2 exchange towards a per 319 network prefix anycast address allocated by IANA. Others discovery 320 means are also possible, for example, DNS queries to retrieve the CGA 321 enabled Security Gateway associated with a given host. Gateway's 322 authorization during the IKE_AUTH exchange in case of the self- 323 evident authentication mode of IPSec imply the verification of TS_i 324 and TS_r payloads (initiator's and responder's CGA) against their CGA 325 parameters. Initiator's and responder's CGA parameters are stored in 326 the GW_i's and GW_r PAD (respectively) and exchanged during the 327 IKE_AUTH exchange in CERT payloads (TBD). 329 When a packet from initiator to responder triggers an IKEv2 exchange, 330 GW_i and GW_r merely prove ownership of their CGAs. Additionally, 331 they check the ownership of CGA for the initiator and responder. In 332 the same time, while GW_i and GW_r posses initiator's and responder's 333 CGA Parameters (respectively) stored in their PAD, GW_i and GW_r 334 prove that they are authorized to be the initiator's and responder's 335 CGA enabled Security Gateway. Following that, they negotiate and 336 configure a pair of bidirectional SA's between the two gateways: 338 GW_i -> GW_r spi=0x... ipsec tunnel ah/esp keys=... 340 GW_i -> GW_r spi=0x... ipsec tunnel ah/esp keys=... 342 And they finally add two news SPD entries specifying that subsequent 343 communications between initiator and responder's CGA require IPsec 344 protection: 346 initiator_CGA/128[any] -> responder_CGA/128[any] any require 347 (ipsec/ah/esp/tunnel=GW_i->GW_r) 348 responder_CGA/128[any] -> initiator_CGA/128[any] any require 349 (ipsec/ah/esp/tunnel=GW_i->GW_r) 351 5. IKEv2 Payload usage and requirements 353 A peer implementing the self-evident authentication mode of IPSec has 354 to use IKEv2 payloads in a specific manner. The following 355 subsections describe usage and requirements of some of the IKEv2 356 payloads while performing IKE_AUTH exchange. 358 5.1. Identification Payload 360 The Identification (ID) Payload of IKE contains the name of the 361 entity to be authenticated with the Authentication (AUTH) Payload. 362 When using CGA, the name of the node is its CGA (initiator's or 363 responder's CGA in the transport mode, and GW_i's or GW_r's CGA in 364 the tunnel mode). CGA is embedded within the ID payload under the 365 known IKEv2 type ID_IPV6_ADDR. CGA enabled node or gateway MAY use 366 also IKEv2 ID_FQDN type (TBD). In that case the CGA technique is a 367 natural complement of the DNSSec. 369 5.2. Certificate Payload 371 The name of the Certificate (CERT) payload is rather misleading and 372 the CERT payload is not used to transport only certificates, but also 373 different authentication material/credentials. In case of the self- 374 evident authentication mode of IPSec, the CERT payload is used to 375 transmit the CGA Parameters data structure. 377 Each CGA enabled Node or Security gateway wanting to prove CGA 378 ownership MUST send to peer its CGA and CGA Parameters used when 379 generating its CGA. CGA Parameters data structure requires the new 380 type of CERT payload. That new type of CERT payload will trigger the 381 CGA verification during the IKE_AUTH exchange. In the tunnel mode, 382 beside the CGA Parameters related to their CGA, GW_i and GW_r SHOULD 383 exchange initiator's and responder's CGA Parameters (TBD). 385 5.3. Certificate Request Payload 387 The Certificate Request (CERTREQ) Payload is used by a peer to 388 request preferred certificates to its correspondent. A preference is 389 the type of certificate requested as well as an acceptable 390 certificate authority for this type. A peer can include multiples 391 preferences using several CERTREQ payload. For CGA, certificates 392 used would usually be self-signed, though this does not preclude one 393 to generate its CGA using a CA-signed certificate. The related 394 CERTREQ payload MUST be set to the same type as the CERT payload. 395 Thus, the same as for the CERT payload, we need the new type of the 396 CERTREQ payload. 398 5.4. Authentication Payload 400 The Authentication (AUTH) Payload contains data used to authenticate 401 the entity named in the ID payload (i.e., the CGA owner). Since CGA 402 are generated using public key cryptography, the AUTH payload has to 403 contain a digital signature of the message computed using the public 404 key contained in the CERT payload in the CGA Parameters data 405 structure. Currently specified digital signature algorithms includes 406 RSA and DSA, but this scheme could be used with any public key 407 cryptographic algorithm. 409 5.5. Traffic Selector Payload 411 The Traffic Selector (TS) Payload contains headers used to identify 412 IP packet flows which need IPsec processing. In the case of the 413 self-evident authentication mode of IPSec, those flows will fly 414 between two CGA's. Both in the transport and tunnel mode, TS 415 payloads will contain initiator's and responder's CGA. Hence we 416 require that the TS payloads used contains CGAs. This imply that the 417 TS Type is set to TS_IPV6_ADDR_RANGE. In the transport mode, both 418 the ID payload and the TS payloads contain initiator's and 419 responder's CGAs. In the tunnel mode, ID payload contains gateways' 420 CGAs, while TS payloads contain initiator's and responder's CGA. 421 Those CGA's from TS payloads will subsequently need to be validated 422 against CGA Parameters exchanged in the CERT payload of new type. 424 6. IKE_AUTH validation 426 [1] does not mandate that two peers exchanging keys use the same 427 means of authenticating themselves. Available means of 428 authentication are Digital Signatures, Public Key Encryption and Pre- 429 shared Secret. It is explicitly stated that end-points are not 430 required to use the same means of authenticating themselves. One 431 could use pre-shared secret, while the other could use a digital 432 signature. This note does not conflict with that, allowing one or 433 both entities to prove CGA ownership, thus allowing one to possibly 434 use another means of authenticating itself. 436 CGA-aware IKE peers wanting to exchange traffic with CGA enabled 437 Nodes (e.g. nodes or gateways) MUST verify CGA ownership. CGA-aware 438 IKEv2 implementation should thus be modified to handle CGA 439 verification, which is very similar to how they currently handle 440 self-signed certificates. The implementation MUST verify that the 441 public key contained in the received CGA Parameters generate the 442 address used as IKEv2 identity. 444 6.1. IPSec Transport Mode with self-evident authentication 446 Validation of the IKE_AUTH only requires CGA-PK binding verification. 447 The initial IKEv2 exchanges will be as follows: 449 IKE_SA_INIT exchange: 451 1. initiator -> responder: HDR, SAi1, KEi, Ni 452 2. responder -> initiator: HDR, SAr1, KEr, Nr, CERTREQ=CGA_type 454 IKE_AUTH exchange: 456 3. initiator -> responder: HDR, 457 SK {IDi=CGA_i, 458 CERT=CGA_Parameters_i, 459 CERTREQ=CGA_type, 460 AUTH=dig_sig(CGA_Parameters_i_PK), 461 SAi2, 462 TSi=CGA_i, TSr=CGA_r} 463 4. responder -> initiator: HDR, 464 SK {IDr=CGA_r, 465 CERT=CGA_Parameters_r, 466 AUTH=dig_sig(CGA_Paramters_r_PK), 467 SAr2, 468 TSi=CGA_i, TSr=CGA_r} 470 6.2. IPSec Tunnel Mode with self-evident authentication 472 Tunnel mode requires the following: 474 verification of binding between received gateway's CGA Parameters 475 and its CGA/IKEv2 identity (MUST), 477 verification of binding between received initiator's and 478 responder's CGA in TS payloads (TBD), 480 verification that the GW_i/GW_r is authorized to act as 481 initiator's/responder's CGA gateway (TBD). 483 Initial IKEv2 exchanges will be as follows (TBD): 485 IKE_SA_INIT exchange: 487 1. GW_i -> GW_r: HDR, SAi1, KEi, Ni 488 2. GW_r -> GW_i: HDR, SAr1, KEr, Nr, CERTREQ=CGA_type 490 IKE_AUTH exchange: 492 3. GW_i -> GW_r: HDR, SK {IDi=CGA_GW_i, 493 CERT=CGA_Parameters_GW_i, 494 CERT=CGA_Parameters_i, 495 CERTREQ=CGA_type, 496 AUTH=dig_sig(CGA_Parameters_GW_i_PK), 497 SAi2, 498 TSi=CGA_i, TSr=CGA_r} 499 4. GW_r -> GW_i: HDR, SK {IDr=CGA_GW_r, 500 CERT=CGA_Parameters_GW_r, 501 CERT=CGA_Parameters_r, 502 AUTH=dig_sig(CGA_Paramters_GW_r_PK), 503 SAr2, 504 TSi=CGA_i, TSr=CGA_r} 506 7. Comparation with Better Than Nothing Security (BTNS) 508 Differences between the IPSec self-evident verification mode and the 509 BTNS are listed along the following lines. 511 The IPSec self-evident verification mode, as a slight modification of 512 the regular IKEv2, does not raise new security concerns to IPSec/ 513 IKEv2. The BTNS lacks the authentication, and therefore raises some 514 security concerns that are described below. 516 Due to the lack of authentication, BTNS does not protect the key 517 exchange itself. Contrary to the regular IKEv2, first IKEv2 exhcange 518 (IKE_SA_INIT) is not integrity protected. This opens the possibility 519 for the masquerader, MITM and DOS attacks. An attacker can easily 520 masquerade as a legitimate client and acquire a sensitive 521 authentication information. It can also establish two different 522 Security Associations between endpoints and thus perform the MITM 523 attack. As described in [3] BTNS detectes mentioned attacks only 524 after the session establishment, which can lead to the CPU exhaustion 525 during the initial IKEv2 exchanges. 527 The lack of authentication in BTNS constraints the IPSec usage only 528 to services that use the anonymous access. 530 While BTNS does not require the deployment of identities, the IPSec 531 self-evident verification mode requires the use of either IPv6 532 addresses or FQDNs as IKEv2 identities. The reduced number of IKEv2 533 identites does not constrain the IPSec deployment, if we take into 534 account two assumptions: a) it is reasonable to expext that in IPv6 535 (even with) adresses would be stable, b) it is also reasonable to 536 expect that DNS mappings are up-to-date. 538 8. Conclusion 540 This note presents an overview of how IKEv2 and CGA can be combined 541 to achieve self-evident authentication mode of IPSec. The CGA 542 technique is sufficiently well understood and can use widely deployed 543 and implemented mechanisms. This proposal works in the absence of 544 any previously established direct or indirect (via a broker, AAA 545 roaming operator or trusted third party) security relationship. 546 Because of this, these methods are a very practical and deployable 547 means of using IPsec between previously unknown peers. 549 9. Security Considerations 551 This document discusses possible use of IKEv2 as a means to prove CGA 552 ownership and exchange keys to bootstrap IPsec SA's. Because IKEv2 553 has already been specified and this technique only slightly modifies 554 it, we believe that this should not raise other security concerns 555 that those incurred by CGA proof-of-ownership. Though the 556 cryptographic algorithm used are the same, CGA proof-of-ownership is 557 very different in nature to authentication. One must be especially 558 careful when establishing the security policy, as this technique 559 allows nodes that use their own IPv6 CGA to be successfully 560 authenticated as their "owner". This is similar in essence to IKE 561 used with self-signed certificates, with the additional consideration 562 that CGA binds the address to the public key. A CGA may be 563 considered as a verifiable self-generated address. 565 The self-evident authentication mode of IPsec might be subject to 566 Denial of Service (DoS) attacks. There are two types of such 567 attacks: fake/malicious initiator and fake/malicious destination. 569 A rogue CGA enabled security gateway may attack from 'outside', 570 trying to exhaust the gateway's resources by attempting to establish 571 as many IPsec tunnels as it can towards machine of the protected 572 network prefix. This is done by initiating many IKEv2 exchanges. 573 The fake initiator typically sends a lot of spoofed packets with 574 random source addresses. This does not cause much harm as the IKEv2 575 exchange will not progress any further. On the other hand, the 576 malicious initiator sends regular packets to progress into the IKEv2 577 exchange. The process of mutual gateway's authorization (which is 578 still marked as TBD) could solve this issue. 580 10. Open Issues 582 This document introduce a new CERT/CERTREQ payload type (CGA 583 Parameters) which, among other, triggers the CGA self-evident 584 authentication mode within IPSec/IKEv2. 586 11. Intellectual Property Rights Considerations 588 The IETF takes no position regarding the validity or scope of 589 intellectual property or other rights that might be claimed pertain 590 to the implementation or use of the technology described in this 591 document or the extent to which any license under such rights might 592 or might not be available; neither does it represent that it has made 593 any effort to identify any such rights. Information on the IETF's 594 procedures with respect to rights in standards-track and standards- 595 related documentation can be found in BCP-11. Copies of claims of 596 rights made available for publication and any assurances of licenses 597 to be made available, or the result of an attempt made to obtain a 598 general license or permission for the use of such proprietary rights 599 by implementors or users of this specification can be obtained from 600 the IETF Secretariat. 602 The IETF invites any interested party to bring to its attention any 603 copyrights, patents or patent applications, or other proprietary 604 rights which may cover technology that may be required to practice 605 this standard. Please address the information to the IETF Executive 606 Director. 608 The IETF has been notified of intellectual property rights claimed in 609 regard to some or all of the specification contained in this 610 document. For more information consult the online list of claimed 611 rights. 613 12. References 615 12.1. Normative References 617 [1] Kaufman, C., "The Internet Key Exchange version 2 (IKEv2)", 618 RFC 4306, December 2005. 620 [2] Aura, T., "Cryptographically Generated Addresses (CGA)", 621 RFC 3972, March 2005. 623 [3] Touch, J., Black, D., and Y. Wang, "Problem and Applicability 624 Statement for Better Than Nothing Security (BTNS)", 625 draft-ietf-btns-prob-and-applic-05 (work in progress), 626 February 2007. 628 12.2. Informative References 630 [4] Castelluccia, C., Montenegro, G., Laganier, J., and C. Neumann, 631 "Hindering Eavsdropping via IPv6 Opportunistic Encryption", 632 LNCS ESORICS 2004, September 2004. 634 Authors' Addresses 636 Julien Laganier 637 DoCoMo Euro-Labs 638 Landsbergerstrasse 312 639 D-80687 Muenchen 640 Germany 642 Email: julien.IETF@laposte.net 644 Gabriel Montenegro 645 Microsoft Corporation 646 One Microsoft Way 647 Redmonds, WA 98052 648 USA 650 Email: gabriel_montenegro_2000@yahoo.com 652 Ana Kukec 653 University of Zagreb 654 Unska bb 655 Zagreb 656 Croatia 658 Email: anchie@tel.fer.hr 660 Full Copyright Statement 662 Copyright (C) The IETF Trust (2007). 664 This document is subject to the rights, licenses and restrictions 665 contained in BCP 78, and except as set forth therein, the authors 666 retain all their rights. 668 This document and the information contained herein are provided on an 669 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 670 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 671 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 672 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 673 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 674 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 676 Intellectual Property 678 The IETF takes no position regarding the validity or scope of any 679 Intellectual Property Rights or other rights that might be claimed to 680 pertain to the implementation or use of the technology described in 681 this document or the extent to which any license under such rights 682 might or might not be available; nor does it represent that it has 683 made any independent effort to identify any such rights. Information 684 on the procedures with respect to rights in RFC documents can be 685 found in BCP 78 and BCP 79. 687 Copies of IPR disclosures made to the IETF Secretariat and any 688 assurances of licenses to be made available, or the result of an 689 attempt made to obtain a general license or permission for the use of 690 such proprietary rights by implementers or users of this 691 specification can be obtained from the IETF on-line IPR repository at 692 http://www.ietf.org/ipr. 694 The IETF invites any interested party to bring to its attention any 695 copyrights, patents or patent applications, or other proprietary 696 rights that may cover technology that may be required to implement 697 this standard. Please address the information to the IETF at 698 ietf-ipr@ietf.org. 700 Acknowledgment 702 Funding for the RFC Editor function is provided by the IETF 703 Administrative Support Activity (IASA).