idnits 2.17.1 draft-ietf-btns-ipsec-apireq-00.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 437. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 414. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 421. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 427. ** 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 Introduction section. ** 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 237: '... It MAY be appropriate to map IPsec ...' RFC 2119 keyword, line 240: '...n a loss of information. It SHOULD be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 13, 2006) is 6581 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 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4307 (Obsoleted by RFC 8247) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Security Policy M. Richardson 3 Internet-Draft SSW 4 Expires: October 15, 2006 B. Sommerfeld 5 Sun 6 April 13, 2006 8 Requirements for an IPsec API 9 draft-ietf-btns-ipsec-apireq-00.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 October 15, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 Given the open nature of the Internet today, application protocols 43 require strong security. IPsec's wire protocols appear to meet the 44 requirements of many protocols. The lack of a common model for 45 application-layer interfaces has complicated use of IPsec by upper- 46 layer protocols. This document provides an overview of facilities 47 which a host IPsec implementation should provide to applications to 48 allow them to both observe and influence how IPsec protects their 49 communications. 51 Table of Contents 53 1. Motivation for this work . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Motivations for this work . . . . . . . . . . . . . . . . . 3 56 4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 58 6. System policy . . . . . . . . . . . . . . . . . . . . . . . 4 59 7. HOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 8. WHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 8.1. OPAQUE IDENTITY . . . . . . . . . . . . . . . . . . . . . . 5 62 8.2. AUDITING . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 8.3. ACCESS CONTROL . . . . . . . . . . . . . . . . . . . . . . . 5 64 8.4. ATTRIBUTES/CREDENTIALS . . . . . . . . . . . . . . . . . . . 5 65 9. Error reporting . . . . . . . . . . . . . . . . . . . . . . 6 66 10. Security Guarantees . . . . . . . . . . . . . . . . . . . . 6 67 10.1. Connection-oriented communication . . . . . . . . . . . . . 6 68 10.2. Connectionless communication . . . . . . . . . . . . . . . . 7 69 11. Non-goals And Bad Ideas . . . . . . . . . . . . . . . . . . 7 70 11.1. Exposure of keys . . . . . . . . . . . . . . . . . . . . . . 7 71 11.2. Exposure of IPsec SPI values . . . . . . . . . . . . . . . . 7 72 12. Other issues . . . . . . . . . . . . . . . . . . . . . . . . 8 73 13. Security Considerations . . . . . . . . . . . . . . . . . . 8 74 14. Document TODO . . . . . . . . . . . . . . . . . . . . . . . 8 75 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 15.1. Normative References . . . . . . . . . . . . . . . . . . . . 8 77 15.2. Informative References . . . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 79 Intellectual Property and Copyright Statements . . . . . . . 11 81 1. Motivation for this work 83 Many protocols under development are considering the use of IPsec for 84 security. Unfortunately, most existing IPsec implementations 85 ([RFC2401] and [RFC4301]) do not give applications any visibility 86 into what, if anything, they are doing on behalf of an application. 87 This limitation only allows IPsec to do all-or-nothing access 88 control, and requires two levels of authentication, with one within 89 the application, and a second level within an IPsec key management 90 protocol (most typically IKE [RFC2407][RFC2408][RFC2409] and IKEv2 91 [RFC4306][RFC4307]). 93 2. Terminology 95 The term "socket" will be used here to identify an application-layer 96 communications endpoint; it does imply any specific API is to be 97 used. For the purposes of this discussion, a socket may include: 98 A communications endpoint for a connectionless protocol 99 One end of an established connection for a connection-oriented 100 protocol 101 A listening endpoint for a connection-oriented protocol 103 For the purposes of this document, the term "application" refers to 104 programs implementing any client protocol using either IP or a 105 transport protocol such as TCP or UDP running over IP. Note that 106 this is in many ways somewhat broader than the traditional use of 107 "application" within the IETF, as it may also include 108 "infrastructure" protocols built on top of IP and IPsec, including 109 routing, ICMP, etc. 111 3. Motivations for this work 113 Most protocols for application security, such as TLS [RFC2246] and 114 SSH [RFC4251] operate at or above the transport layer. This renders 115 the underlying transport connections vulnerable to denial of service 116 attacks, including connection assassination [RFC3552]. IPsec offers 117 the promise of protecting against many of these denial of service 118 attacks. 120 There are other potential benefits. Conventional software-based 121 IPsec implementations isolate applications from the cryptographic 122 keys, improving security by making inadvertant or malicious key 123 exposure more difficult. In addition, specialized hardware may allow 124 encryption keys protected from disclosure within trusted 125 cryptographic units. Also, custom hardware units may well allow for 126 higher performance. 128 Areas where this is currently under active discussion include the set 129 of block storage protocols being developed by the IP Storage working 130 group [RFC3723] and NFS version 4 (XXX: need newer reference than 131 target="I-D.ietf-nfsv4-ccm") 133 4. Goals 135 Separate policy and mechanism 137 5. Requirements 139 Here are some basic requirements for an IPsec application API: 140 An application should be able to determine HOW a communication was 141 protected (or not). 142 An application should be able to determine WHO it is talking to. 143 If a communication is nominally authorized but fails, an 144 application should be able to get an indication of WHY it failed, 145 to help identify the configuration error causing the spurious 146 failure. 147 An application should be able to influence HOW a communication is 148 protected, subject to override or modification by system policy. 149 An application should be able to indicate WHO it wishes to talk 150 to, again subject to override or modification by system policy. 151 These interfaces should be as independant as possible of the key 152 management protocol being used; it should be possible to implement 153 this with IKEv1, IKEv2, KINK, etc., 155 6. System policy 157 Interactions with system policy: 158 System-level policy trumps all 159 By default, applications should be able to ask for *more* 160 protection. 161 Applications wishing *less* protection may need appropriate local 162 privileges. (example: ike bypass of UDP port 500; DHCP lease 163 renewals...) 165 7. HOW 167 An application may have requirements for confidentiality and/or 168 integrity; it should be able to determine if an inbound communication 169 was protected and whether an outbound communication will be 170 protected. In addition, there may well be a desire to express 171 preferences for relative strength of algorithms, or specify the 172 specific algorithm to be used. Hard-coding algorithm names into 173 applications should be actively discouraged; perhaps there should be 174 generic "weak" or "strong" indications instead of specific algorithm 175 identifiers. 177 8. WHO 179 This is perhaps the most tricky part of the problem. Existing IPsec 180 key management protocols provide a wide variety of authentication 181 methods -- preshared secrets, public key, Kerberos, X.509 182 certificates, etc., 184 There are several potential uses for names provided by IPsec: 186 8.1. OPAQUE IDENTITY 188 It should be possible to determine that two IPsec-protected 189 communications conducted within a short to medium time frame were 190 with the same authenticated peer; it should be possible to use a 191 received identity to initiate a communication back to that identity. 193 Example cases: connectionless replies; linking ftp control and data 194 connections. 196 The application need only be able to determine if two identities are 197 equal. 199 8.2. AUDITING 201 It should be possible for an application to construct a log entry 202 naming the peer. 204 8.3. ACCESS CONTROL 206 While policy rules may allow traffic to be blocked entirely, it's 207 often necessary for a program to provide services to mutually 208 suspicious clients. It should be possible for a service to make 209 appropriate access control decisions based on the identity of the 210 peer; in addition, the peer's certificate may contain interesting 211 SubjectAltName or other attributes which may have relevance for the 212 application; it may also be possible for the system to derive other 213 attributes from the peer's identity. 215 8.4. ATTRIBUTES/CREDENTIALS 217 [Mission Creep Alert] In many cases, an application is not so much 218 interested in the peer's name, but rather in some other attribute of 219 the peer. Exactly where and how to map from long-term keys to these 220 attributes needs to be nailed down; it may well be that this is best 221 left as a local issue. 223 Some of this is probably out of scope for the working group; however, 224 we should not preclude others from building on this. 226 9. Error reporting 228 There are a number of reasons why a communication may fail because of 229 IPsec configuration mismatches.. 231 These include, but are not limited to: 232 Blocked by local or peer SPD. 233 Local or peer key management protocols cannot establish an SA. 234 Local or peer key management protocols cannot authenticate to each 235 other. 237 It MAY be appropriate to map IPsec failures into existing error codes 238 (e.g., "connection refused", "connection timed out"), so that 239 existing applications use appropriate error recovery strategies; 240 however, this does result in a loss of information. It SHOULD be 241 possible for an IPsec-aware application to get additional information 242 about the reasons that a communications failed. 244 10. Security Guarantees 246 Connection-oriented and connectionless communication often require 247 different application structure. In many case, it will often be most 248 convenient to do security checks once per connection, while for 249 connectionless communications, per-message operations will be needed. 251 10.1. Connection-oriented communication 253 Packet boundaries are not, in general, visible to clients of stream 254 protocols such as TCP, while IPsec protection is provided (or not) on 255 a packet-by-packet basis, 257 In addition, it would be an unreasonable burden on applications to 258 force them to continuously inquire about each individual packet. 260 It should be possible for an application to ensure that all traffic 261 to a particular socket is protected appropriately; it should also be 262 possible for an application to ensure that all traffic to a socket 263 originates from the same authenticated identity. 265 A pair of communicating applications should be able to determine that 266 the ipsec protection on a connection between them is end-to-end. 268 Note that it is common for datagram socket API's to allow a "connect" 269 operation which sets a default destination and filters inbound 270 packets based on source address; it should similarly be possible for 271 the connection-oriented security guarantees to be applied to datagram 272 sockets being used for 1:1 communications. 274 10.2. Connectionless communication 276 It is also common to use datagram sockets for many-to-many 277 communication; it should be possible to get and set identity 278 information on a packet-by-packet basis. 280 It may well be the case that a datagram-oriented client application 281 will use the connection-oriented part of this API (because it is 282 using a given datagram socket to talk to a specific server) while the 283 server it is talking to use the connectionless API because it is 284 using a single socket to receive requests from and send replies to a 285 large number of clients. 287 11. Non-goals And Bad Ideas 289 Here are a few ideas which have popped up every so often which really 290 seem to be bad ideas.. in other words, things which should not be 291 exposed to applications because they can't be used reliably or which 292 cause active harm. 294 11.1. Exposure of keys 296 There is absolutely no reason for applications to see the underlying 297 encryption keys, or influence the choice of keys. This is to allow 298 an IPsec implementation to have a clear boundary around its 299 cryptographic components. 301 11.2. Exposure of IPsec SPI values 303 In general, there is no need for applications to see SPI values or 304 keys; it's also the case that in many cases the exact algorithm used 305 may not be of interest as long as it is appropriately strong. 307 Since both IKE and IPsec SA's may be short-lived, it is plausible 308 that: 309 an application connection or association will outlive any given 310 IPsec SA. 311 an application connection or association will outlive any given 312 IKE SA. 313 an application connection may be idle for extended periods, during 314 which time there is no IKE or IPsec SA state between the peers. 315 It should be the case that any properties provided to applications 316 regarding peer identity, protection, etc., should be able to survive 317 rekeying. 319 It may be appropriate to use SPI values as temporary handles, but 320 applications may last much longer than SA's, and SPI values may be 321 recycled over time; it would be better for there to be a separate, 322 local-use-only, space for (identity, params) pairs. 324 12. Other issues 326 Interface-specific vs. application-specific policy; deal with this 327 as separate layers of filtering/intersections/etc? 328 Real-time notifications of both ends that rekey, etc., is having 329 trouble (highly desirable for VoIP-type applications). 330 Balancing keeping full certificate handling out of applications 331 while still providing full access to certificate attributes. 333 13. Security Considerations 335 14. Document TODO 337 Flesh out Other Issues section. 338 Flesh out Informative References with references to existing 339 IPsec-related API's 340 Improve security considerations section. 342 15. References 344 15.1. Normative References 346 [RFC2407] Piper, D., "The Internet IP Security Domain of 347 Interpretation for ISAKMP", RFC 2407, November 1998. 349 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 350 Security Association and Key Management Protocol 351 (ISAKMP)", RFC 2408, November 1998. 353 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 354 (IKE)", RFC 2409, November 1998. 356 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 357 Internet Protocol", RFC 4301, December 2005. 359 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 360 RFC 4306, December 2005. 362 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 363 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 364 December 2005. 366 15.2. Informative References 368 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 369 RFC 2246, January 1999. 371 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 372 Internet Protocol", RFC 2401, November 1998. 374 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 375 Text on Security Considerations", BCP 72, RFC 3552, 376 July 2003. 378 [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. 379 Travostino, "Securing Block Storage Protocols over IP", 380 RFC 3723, April 2004. 382 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 383 Protocol Architecture", RFC 4251, January 2006. 385 Authors' Addresses 387 Michael C. Richardson 388 Sandelman Software Works 389 470 Dawson Avenue 390 Ottawa, ON K1Z 5V7 391 CA 393 Email: mcr@sandelman.ottawa.on.ca 394 URI: http://www.sandelman.ottawa.on.ca/ 396 Bill Sommerfeld 397 Sun Microsystems 398 1 Network Drive 399 Burlington, MA 01803 400 US 402 Phone: +1 781 442 3458 403 Email: somerfeld@sun.com 405 Intellectual Property Statement 407 The IETF takes no position regarding the validity or scope of any 408 Intellectual Property Rights or other rights that might be claimed to 409 pertain to the implementation or use of the technology described in 410 this document or the extent to which any license under such rights 411 might or might not be available; nor does it represent that it has 412 made any independent effort to identify any such rights. Information 413 on the procedures with respect to rights in RFC documents can be 414 found in BCP 78 and BCP 79. 416 Copies of IPR disclosures made to the IETF Secretariat and any 417 assurances of licenses to be made available, or the result of an 418 attempt made to obtain a general license or permission for the use of 419 such proprietary rights by implementers or users of this 420 specification can be obtained from the IETF on-line IPR repository at 421 http://www.ietf.org/ipr. 423 The IETF invites any interested party to bring to its attention any 424 copyrights, patents or patent applications, or other proprietary 425 rights that may cover technology that may be required to implement 426 this standard. Please address the information to the IETF at 427 ietf-ipr@ietf.org. 429 Disclaimer of Validity 431 This document and the information contained herein are provided on an 432 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 433 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 434 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 435 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 436 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 437 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 439 Copyright Statement 441 Copyright (C) The Internet Society (2006). This document is subject 442 to the rights, licenses and restrictions contained in BCP 78, and 443 except as set forth therein, the authors retain all their rights. 445 Acknowledgment 447 Funding for the RFC Editor function is currently provided by the 448 Internet Society.