idnits 2.17.1 draft-ietf-btns-core-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 459. ** 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: ---------------------------------------------------------------------------- == 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 == Line 198 has weird spacing: '...rotocol ok...' == Line 263 has weird spacing: '...rotocol ok...' == Line 295 has weird spacing: '...rotocol ok...' -- 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 (February 2006) is 6635 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 section? 'RFC2408' on line 399 looks like a reference -- Missing reference section? 'RFC2409' on line 403 looks like a reference -- Missing reference section? 'RFC4306' on line 415 looks like a reference -- Missing reference section? 'RFC4301' on line 412 looks like a reference -- Missing reference section? 'I-D.ietf-btns-prob-and-applic' on line 379 looks like a reference -- Missing reference section? 'RFC2119' on line 396 looks like a reference -- Missing reference section? 'Q' on line 160 looks like a reference -- Missing reference section? 'R' on line 161 looks like a reference -- Missing reference section? 'A' on line 160 looks like a reference -- Missing reference section? 'B' on line 160 looks like a reference -- Missing reference section? 'C' on line 174 looks like a reference -- Missing reference section? 'D' on line 162 looks like a reference -- Missing reference section? 'SG-A' on line 172 looks like a reference -- Missing reference section? 'I-D.ietf-btns-connection-latching' on line 374 looks like a reference -- Missing reference section? 'RFC2743' on line 406 looks like a reference -- Missing reference section? 'I-D.ietf-nfsv4-channel-bindings' on line 391 looks like a reference -- Missing reference section? 'RFC4251' on line 409 looks like a reference -- Missing reference section? 'I-D.ietf-kitten-gssapi-channel-bindings' on line 385 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 26 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP N. Williams 3 Internet-Draft Sun 4 Expires: August 5, 2006 M. Richardson 5 SSW 6 February 2006 8 Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec 9 draft-ietf-btns-core-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 5, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document specifies how to use the Internet Key Exchange (IKE) 43 protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" 44 security associations (SAs) for use with the IPsec Encapsulating 45 Security Payload (ESP) and the IPsec Authentication Header (AH). No 46 IKE extensions are needed, but Peer Authorization Database (PAD) and 47 Security Policy Database (SPD) extensions are specified. 48 Unauthenticated IPsec is herein referred to by its popular acronym, 49 "BTNS" (Better Than Nothing Security). 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Conventions used in this document . . . . . . . . . . . . . 3 55 2. BTNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. Example #1: sgA . . . . . . . . . . . . . . . . . . . . . . 5 58 3.2. Example #2: Q . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.3. Example #3: C . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.4. Miscaellaneous examples . . . . . . . . . . . . . . . . . . 8 61 4. Security Considerations . . . . . . . . . . . . . . . . . . 9 62 4.1. Connection-Latching and Channel Binding . . . . . . . . . . 9 63 4.2. Leap-of-Faith (LoF) for BTNS . . . . . . . . . . . . . . . . 9 64 5. Normative . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 66 Intellectual Property and Copyright Statements . . . . . . . 13 68 1. Introduction 70 Here we describe how to establish unauthenticated IPsec SAs using 71 IKEv1 [RFC2408] [RFC2409] or IKEv2 [RFC4306] and unauthenticated 72 public keys. No new on-the-wire protocol elements are added to IKE 73 or IKEv2. 75 The [RFC4301] processing model is assumed. 77 This document does not define an opportunistic BTNS mode of IPsec 78 whereby nodes may fallback on unprotected IP when their peers do not 79 support IKE or IKEv2, nor does it describe "leap-of-faith" modes, or 80 "connection latching." 82 See [I-D.ietf-btns-prob-and-applic] for the applicability and uses of 83 BTNS. 85 1.1. Conventions used in this document 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 2. BTNS 93 The IPsec processing model, IKE and IKEv2 are hereby modified as 94 follows: 96 o A new ID type is added, 'PUBLICKEY'; IDs of this type have public 97 keys as values. This ID type is not used on the wire. 99 o A BTNS-specific PAD entry. This entry is intended to be the last 100 entry in the PAD when BTNS is enabled. A peer that matches no 101 other PAD entries is to be "authenticated" by verifying that the 102 signature in its AUTH (or SIG) payload in the IKEv2 (or v1) 103 exchange with the public key from the peer's CERT payload. The 104 peer's ID MUST then be coerced to be of 'PUBLICKEY' type with the 105 peer's public key as its value. 107 o A new flag for SPD entries: 'BTNS_OK'. Traffic to/from peers that 108 match the BTNS PAD entry will only match SPD entries that have the 109 BTNS_OK flag set. The SPD may be searched by address or by ID (of 110 type PUBLICKEY, of course, for BTNS peers), as per the IPsec 111 processing model [RFC4301]; searching by ID in this case requires 112 creation of SPD entries that are bound to public key values (this 113 could be used to build "leap-of-faith" behaviour, for example). 115 Nodes MUST reject IKE_SA proposals from peers that match non-BTNS PAD 116 entries but fail to authenticate properly. 118 Nodes wishing to be treated as BTNS nodes by their peers SHOULD use 119 bare RSA key CERT payloads and MAY use certificates known not to have 120 been pre-shared with their peers or outside their trust anchors 121 (e.g., self-signed certificates). RSA keys for use in BTNS may be 122 generated at any time, but "connection latching" [I-D.ietf-btns- 123 connection-latching] requires that they remain constant between IKE 124 exchanges setting up SAs for latched connections. 126 To preserve standard IPsec access control semantics BTNS responders 127 MUST NOT allow BTNS peers to assert addresses which could be asserted 128 by non-BTNS peers. If there are no wildcard entries in the PAD other 129 than the BTNS PAD entry then this can be ensured by checking that 130 BTNS peers' addresses do not match any PAD entry for a non-BTNS peer. 131 Otherwise, if there are wildcard entries in the PAD other than the 132 BTNS PAD entry then the addresses that these entries can match MUST 133 be constrained to prevent overlaps. 135 Note that nodes may unwittingly match peers' BTNS PAD entries and be 136 authenticated as BTNS nodes, as long as they do not match any non- 137 BTNS PAD entries. 139 3. Usage Scenarios 141 In order to explain the above rules a number of scenarios will be 142 postulated. The goal here is to demonstrate that the above rules are 143 both sufficient and required. 145 To explain the scenarios a reference diagram describing a canonical 146 network will be used. It is as follows: 148 [Q] [R] 149 AS1 . . AS2 150 [A]----+----[SG-A].......+....+.......[SG-B]-------[B] 151 ...... \ 152 ..PI.. ----[btns-B] 153 ...... 154 [btns-C].....+....+.......[btns-D] 156 Figure 1: Reference Network Diagram 158 In this diagram, there are six end-nodes: A, B, C and D. Two of the 159 systems are security gateways: SG-A, SG-B, protecting networks on 160 which [A] and [B] reside. There is a node [Q] which is IPsec and 161 BTNS capable, and node [R] is a simple node, with no IPsec or BTNS 162 capability. Nodes [C] and [D] are BTNS capable. We will examine 163 interactions between the BTNS enabled nodes, and the IPsec enabled 164 nodes. 166 Nodes C and Q have a fixed addresses. Node D non-fixed addresses. 168 PI is the Public Internet ("The Wild"). 170 3.1. Example #1: sgA 172 The machine that we will care about will be [SG-A], a firewall device 173 of some kind which we wish to configure to respond to BTNS 174 connections from [C] 176 SG-A has the following "VPN" PAD and SPD entries: 178 Child SA 179 Rule Remote ID IDs allowed SPD Search by 180 ---- --------- ----------- ------------- 181 1 ID 182 2 ID 183 3 PUBLICKEY:any ANY by-IP 185 The last entry is the BTNS entry. 187 Figure 2: SG-A PAD table 189 Here is any address that is not part of A's network, and is not 190 claimed by any other entry. Note that sgA's PAD entry has one and 191 only one wildcard PAD entry: the BTNS catch-all PAD entry, so, as 192 described in Section 2. 194 and are from [RFC4301] section 195 4.4.3 197 Rule Local Remote Next Layer BTNS Action 198 ID/TS ID/TS Protocol ok 199 ---- ----- ------ ---------- ---- ----------------------- 200 1 ID:A ID:R ANY N/A BYPASS 201 2 ID:A ID:Q ANY no PROTECT(ESP,tunnel,AES, 202 SHA256) 203 3 ID:A ID:B ANY no PROTECT(ESP,tunnel,AES, 204 SHA256) 205 4 IP:A-net IP:ANY ANY yes PROTECT(ESP,transport, 206 integr+conf) 208 Figure 3: SG-A SPD table 210 The processing by sgA of various peers then is as follows: 212 o Q does not match PAD entry #1, but does match PAD entry #2; PAD 213 processing stops, then the SPD is searched by Q's ID to find entry 214 #2; CHILD SAs are then allowed that have sgA's and Q's addresses 215 as the end-point addresses. 217 o sgB matches PAD entry #1; PAD processing stops, then the SPD is 218 searched by sgB's ID to find SPD entry #3; CHILD SAs are then 219 allowed that have sgA's address and any addresses from B's network 220 as the end-point addresses. 222 o R does not initiate any IKE_SAs; its traffic to A is bypassed by 223 SPD entry #1. 225 o C does not match PAD entries #1 or #2, but does match entry #3, 226 the BTNS entry; the SPD is searched by C's address and SPD entry 227 #3 is matched; CHILD SAs are then allowed that have sgA's address 228 and C's address as the end-point addresses provided that C's 229 address is neither Q's nor any of B's. 231 o Rogue BTNS nodes attempting to assert Q's or B's addresses will 232 either match the PAD entries for Q or B and fail to authenticate 233 as Q or B, in which case they are rejected, or they will match PAD 234 entry #3 but will not be allowed to create CHILD SAs with Q's or 235 B's addresses as traffic selectors. 237 o Rogue BTNS nodes attempting to assert C's address are allowed. 238 Protection for C requires additional bindings of C's specific BTNS 239 ID (that is, its public key) to its traffic flows through 240 connection-latching and channel binding, or leap-of-faith, none of 241 which are described here. 243 3.2. Example #2: Q 245 Q is either a BITS or native IPsec implementation; if it is a native 246 implementation it may have IPsec-aware applications, specifically 247 NFSv4 (TCP port 2049). 249 In any case, Q wants to communicate with A generally, and with BTNS 250 peers for NFSv4 only. It's PAD and SPD are configured as follows: 252 Child SA 253 Rule Remote ID IDs allowed SPD Search by 254 ---- --------- ----------- ------------- 255 1 ID 256 2 PUBLICKEY:any ANY by-IP 258 The last entry is the BTNS entry. 260 Figure 4: Q PAD table 262 Rule Local Remote Next Layer BTNS Action 263 ID/TS ID/TS Protocol ok 264 ---- ----- ------ ---------- ---- ----------------------- 265 1 ID:Q ID:A ANY no PROTECT(ESP,tunnel,AES, 266 SHA256) 267 2 IP:Q IP:ANY ANY yes PROTECT(ESP,transport, 268 and port integr+conf) 269 2049 271 Figure 5: SG-A SPD table 273 The same analysis shown above in Section 3.1 applies here with 274 respect to sgA, C and rogue peers, except that C is allowed only 275 access to the NFSv4 service on Q. Additionally sgB is treated as a 276 BTNS peer as it is not known to Q, and therefore any host behind sgB 277 can access the NFSv4 service on Q (and, because Q has no formal 278 relationship with sgB, rogues can impersonate B). 280 3.3. Example #3: C 282 C only supports BTNS and wants to use BTNS to protect NFSv4 traffic. 283 It's PAD and SPD are configured as follows: 285 Child SA 286 Rule Remote ID IDs allowed SPD Search by 287 ---- --------- ----------- ------------- 288 1 PUBLICKEY:any ANY by-IP 290 The last entry is the BTNS entry. 292 Figure 6: Q PAD table 294 Rule Local Remote Next Layer BTNS Action 295 ID/TS ID/TS Protocol ok 296 ---- ----- ------ ---------- ---- ----------------------- 297 1 IP:C IP:ANY ANY yes PROTECT(ESP,transport, 298 and port integr+conf) 299 2049 300 2 ID:C IP:ANY ANY N/A BYPASS 302 Figure 7: SG-A SPD table 304 3.4. Miscaellaneous examples 306 If sgA were not BTNS-capable then it would not have PAD and SPD 307 entries #3 and #4, respectively. Then C would be rejected as usual 308 under the standard IPsec model [RFC4301]. 310 Similarly, if Q were not BTNS-capable then it would not have PAD and 311 SPD entries #2. Then C would be rejected as usual under the standard 312 IPsec model [RFC4301]. 314 4. Security Considerations 316 Unauthenticated security association negotiation is subject to MITM 317 attacks and should be used with care. Where security infrastructures 318 are lacking this may indeed be better than nothing. 320 Use with applications that bind authentication at higher network 321 layers to secure channels at lower layers may provide one secure way 322 to use unauthenticated IPsec, but this is not specified herein. 324 Use of multiple wildcard PAD entries can be problematic. Where it is 325 important that addresses and node identities be tightly bound it is 326 important that such PAD entries limit the addresses that matching 327 peers can assert for their CHILD SAs to non-overlapping address 328 spaces. In practice this may be difficult to configure; if it is not 329 feasible to configure systems in this way then either BTNS should not 330 be used or BTNS PAD entries should constrain matching peers only to 331 using services for which authentication is not normally necessary or 332 where IPsec-aware applications are used. 334 4.1. Connection-Latching and Channel Binding 336 BTNS is subject to MITM attacks. One way to protect against MITM 337 attacks subsequent to initial communications is to use "connection 338 latching" [I-D.ietf-btns-connection-latching], whereby ULPs cooperate 339 with IPsec in native IPsec implementations to bind individual packet 340 flows to sequences of SAs whose end-point IDs (public keys, in the 341 case of BTNS end-points) and other characteristics (e.g., quality of 342 protection) must all be the same. 344 MITMs can be detected by using application-layer authentication 345 frameworks and/or mechanisms, such as the GSS-API [RFC2743], with 346 channel binding [I-D.ietf-nfsv4-channel-bindings] [I-D.ietf-kitten- 347 gssapi-channel-bindings], where the channels to be bound to 348 application-layer authentication are latched connections and where 349 the channel bindings data strongly identify the end-points of the 350 latched connection (e.g., the public keys of the end-points). 352 4.2. Leap-of-Faith (LoF) for BTNS 354 "Leap of faith" is the term generally used for the habit of 355 accepting, without any evidence, that a given key identifies a peer 356 that one wanted to talk to; specifically this is a common mode of 357 operation for Secure Shell [RFC4251] clients where, when a server is 358 encountered for the first time the client may ask the user whether to 359 accept the server's public key as its identity and, if so, records 360 the server's name (as given by the user) and public key in a 361 database. 363 Leap of Faith can work in a similar way for BTNS nodes, but it is 364 currently still being designed and specified by the IETF BTNS WG. 365 [NOTE: I believe that BTNS LoF should be application-driven, 366 requiring native IPsec and IPsec APIs, and also, because LoF bindings 367 can only be created locally (there's no protocol to request that a 368 peer create LoF bindings and such a protocol would not be desirable) 369 connection latching is required in order for BTNS LoF applications to 370 obtain LoF semantics similar to the secure shell's.] 372 5. Normative 374 [I-D.ietf-btns-connection-latching] 375 Williams, N., "IPsec Channels: Connection Latching", 376 draft-ietf-btns-connection-latching-00 (work in progress), 377 February 2006. 379 [I-D.ietf-btns-prob-and-applic] 380 Touch, J., "Problem and Applicability Statement for Better 381 Than Nothing Security (BTNS)", 382 draft-ietf-btns-prob-and-applic-03 (work in progress), 383 June 2006. 385 [I-D.ietf-kitten-gssapi-channel-bindings] 386 Williams, N., "Clarifications and Extensions to the GSS- 387 API for the Use of Channel Bindings", 388 draft-ietf-kitten-gssapi-channel-bindings-01 (work in 389 progress), October 2005. 391 [I-D.ietf-nfsv4-channel-bindings] 392 Williams, N., "On the Use of Channel Bindings to Secure 393 Channels", draft-ietf-nfsv4-channel-bindings-03 (work in 394 progress), February 2005. 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 400 Security Association and Key Management Protocol 401 (ISAKMP)", RFC 2408, November 1998. 403 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 404 (IKE)", RFC 2409, November 1998. 406 [RFC2743] Linn, J., "Generic Security Service Application Program 407 Interface Version 2, Update 1", RFC 2743, January 2000. 409 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 410 Protocol Architecture", RFC 4251, January 2006. 412 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 413 Internet Protocol", RFC 4301, December 2005. 415 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 416 RFC 4306, December 2005. 418 Authors' Addresses 420 Nicolas Williams 421 Sun Microsystems 422 5300 Riata Trace Ct 423 Austin, TX 78727 424 US 426 Email: Nicolas.Williams@sun.com 428 Michael C. Richardson 429 Sandelman Software Works 430 470 Dawson Avenue 431 Ottawa, ON K1Z 5V7 432 CA 434 Email: mcr@sandelman.ottawa.on.ca 435 URI: http://www.sandelman.ottawa.on.ca/ 437 Intellectual Property Statement 439 The IETF takes no position regarding the validity or scope of any 440 Intellectual Property Rights or other rights that might be claimed to 441 pertain to the implementation or use of the technology described in 442 this document or the extent to which any license under such rights 443 might or might not be available; nor does it represent that it has 444 made any independent effort to identify any such rights. Information 445 on the procedures with respect to rights in RFC documents can be 446 found in BCP 78 and BCP 79. 448 Copies of IPR disclosures made to the IETF Secretariat and any 449 assurances of licenses to be made available, or the result of an 450 attempt made to obtain a general license or permission for the use of 451 such proprietary rights by implementers or users of this 452 specification can be obtained from the IETF on-line IPR repository at 453 http://www.ietf.org/ipr. 455 The IETF invites any interested party to bring to its attention any 456 copyrights, patents or patent applications, or other proprietary 457 rights that may cover technology that may be required to implement 458 this standard. Please address the information to the IETF at 459 ietf-ipr@ietf.org. 461 Disclaimer of Validity 463 This document and the information contained herein are provided on an 464 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 465 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 466 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 467 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 468 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 469 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 471 Copyright Statement 473 Copyright (C) The Internet Society (2006). This document is subject 474 to the rights, licenses and restrictions contained in BCP 78, and 475 except as set forth therein, the authors retain all their rights. 477 Acknowledgment 479 Funding for the RFC Editor function is currently provided by the 480 Internet Society.