idnits 2.17.1 draft-ietf-kink-reqmt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations 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 abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (August 9, 2000) is 8655 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 section? '1' on line 243 looks like a reference -- Missing reference section? '2' on line 246 looks like a reference -- Missing reference section? '3' on line 249 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT KINK Requirements Michael Thomas 3 Cisco Systems 4 August 9, 2000 6 Kerberized Internet Negotiation of Keys 8 draft-ietf-kink-reqmt-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 The KINK working group is chartered to create a standards track 32 protocol to facilitate centralized key management for IPsec security 33 associations as defined in RFC 2401, as an alternative to IKE (RFC 34 2409). Participating systems will use the Kerberos architecture as 35 defined in RFC 1510 (and its successors) for key management. The goal 36 of the working group is to produce a streamlined, fast, easily 37 managed, and cryptographically sound protocol without requiring 38 public key. 40 The working group will not require changes to either IPsec (RFC 41 2401), or Kerberos (RFC 1510). 43 Motivation 45 The IPsec working group has defined a number of protocols which 46 provide the ability to create and maintain cryptographically secure 47 security associations at layer three (ie, the IP layer). This effort 48 has produced two distinct protocols: 50 1) a mechanism to encrypt and authenticate IP datagram payloads which 51 assumes a shared secret between the sender and receiver 53 2) a mechanism for IPsec peers to perform mutual authentication and 54 exchange keying material 56 The IPsec working group has defined a peer to peer authentication and 57 keying mechanism, IKE (RFC 2409). One of the drawbacks of a peer to 58 peer protocol is that each peer must know and implement a site's 59 security policy which in practice can be quite complex. In addition, 60 the lack of a trusted third party requires the use of Diffie Hellman 61 (DH) to establish a shared secret. DH, unfortunately, is computation- 62 ally quite expensive and prone to denial of service attacks. IKE also 63 relies on X.509 certificates to realize scalable authentication of 64 peers. Digital signatures are also computationally expensive and cer- 65 tificate based trust models are difficult to deploy in practice. 66 While IKE does allow for pre-shared symmetric keys, key distribution 67 is required between all peers -- an O(n^2) problem -- which is prob- 68 lematic for large deployments. 70 Kerberos (RFC 1510) provides a mechanism for trusted third party 71 authentication for clients and servers. Clients authenticate to a 72 centralized server -- the Key Distribution Center -- which in turn 73 issues tickets that servers can decrypt thus proving that the client 74 is who it claims to be. One of the elements of a Kerberos ticket is a 75 session key which is generated by the KDC which may be used by the 76 client and server to share a secret. Kerberos also allows for both 77 symmetric key authentication, as well as certificate based public key 78 authentication (PKinit). Since the authentication phase of Kerberos 79 is performed by the KDC, there is no need to perform expensive DH or 80 X.509 certificate signatures/verification operations on servers. 81 While clients may authenticate using X.509 certificates, the authen- 82 tication phase can be amortized over the lifetime of the credentials. 83 This allows a single DH and certificate exchange to be used to key 84 security associations with many servers in a computationally economic 85 way. Kerberos also support clients with symmetric keys but unlike 86 IKE, the symmetric keys are stored in the KDC making the number of 87 keys an O(n) problem rather than O(n^2). Kerberos also allows secu- 88 rity policy to be managed in a more centralized fashion, rather than 89 expecting each potentially untrustworthy peer to abide by stated 90 security policies of an organization. 92 The KINK working group takes these basic features of Kerberos and 93 uses them to its advantage to create a protocol which can establish 94 and maintain IPsec security associations (RFC 2401). It should be 95 noted that KINK is not a replacement for IKE. IKE has one property 96 which KINK cannot reproduce: the ability for two peers to mutually 97 authenticate and exchange keys without the need for an actively par- 98 ticipating third party. However, there are many situations where a 99 trusted third party which proxies authentication is viable, and in 100 fact desirable. 102 While Kerberos specifies a standard protocol between the client and 103 the KDC to get tickets, the actual ticket exchange between client and 104 server is application specific. KINK is intended to be an alterna- 105 tive to requiring each application having its own method of tran- 106 sporting and validating service tickets using a protocol which is 107 efficient and tailored to the specific needs of Kerberos and the 108 applications for which it provides keying and parameter negotiation. 110 Given the above, a new general keying protocol which leverages the 111 scalability of Kerberos is desirable. The working group's first task 112 is to define this protocol and define an domain of interpretation for 113 IPsec to establish and maintain IPsec security associations. The pro- 114 tocol must be able to take full advantage of the features of RFC 2401 115 but in the context of a centralized keying authority. 117 Requirements 119 KINK must meet the following requirements at a minimum: 121 - The protocol must use Kerberos to create session keys in a secure 122 fashion 124 - The protocol must be able to integrate into security architecture 125 of IPSec (RFC 2401) 127 - The protocol must be able to start up SA's regardless of any 128 client/server disposition in the keying protocol 130 - Kerberos makes a distinction between clients and servers; IPsec 131 does not. The protocol must allow for IPsec security associations 132 to be initiated by both servers and clients, thus preserving 133 IPsec's peer to peer nature. 135 - The protocol must be able to initially authenticate using either 136 secret key, or public key authentication. 138 - The protocol must accommodate any combination of public and secret 139 key peers 141 - The protocol must be able to allow a peer to authenticate and par- 142 ticipate in many realms 144 - The protocol must handle absolute time skew gracefully 146 - The protocol must be able to create, modify, rekey, and delete 147 security associations 149 - The protocol must be capable of setting up both transport and tun- 150 nel modes of IPSec 152 - The protocol must be capable of setting up both AH and ESP security 153 associations 155 - The protocol must be capable of negotiating cipher suites 157 - The protocol must be capable of setting up IPsec flow selectors 159 - The protocol must be capable of rekeying without the assistance of 160 the KDC if the session ticket is still valid 162 - The protocol must make an effort to mitigate third party Denial of 163 Service attacks (aka Zombies attacks) 165 - The protocol must be able to be used for more than IPsec keying 167 - The protocol must support both IPv4 and IPv6 169 Deliverables 171 The working group's responsibilities are as follows: 173 - Complete a protocol which meets the requirements outlined above 175 - Keep all KINK working group documents moving along publication / 176 standardization track. 177 The list of the working group's current work items is as follows: 179 - Define the base Kerberized Internet Negotiation of Keys protocol. 181 Goals and Milestones 183 Sep 2000 Consensus on requirements document 185 Dec 2000 Review drafts at Dec IETF 186 Jan 2001 Consensus on base draft protocol 188 Mar 2001 WG Last call on draft 190 Mar 2001-Jun 2001 191 Interoperability Bakeoffs 193 Aug 2001 Interoperability results, decision to recycle or move for- 194 ward 196 Administrativa 198 Chair(s): 200 Derek Atkins 202 Document Editor: 204 TBD 206 Internet Area Director(s): 208 Jeffrey Schiller 209 Marcus Leech 211 Internet Area Advisor: 213 TBD 215 Mailing Lists: 217 General Discussion: ietf-kink@vpnc.org 218 To Subscribe: majordomo@vpnc.org 219 In Body: in body: subscribe ietf-kink 220 Archive: ftp:// 222 Acknowledgments 224 The original KINK Kabal was: 226 Michael Thomas (Cisco) 227 David McGrew (Cisco) 228 Jan Vilhuber (Cisco) 229 Jonathan Trostle (Cisco) 230 Matt Hur (Cybersafe) 231 Mike Froh (Cybersafe) 232 Sasha Medvinsky (GI) 233 Derek Atkins (Telcordia) 234 It must also be acknowledged that the Packetcable Security 235 specification PKT-SP-SEC-I01-991201 provided the raw fodder 236 for this effort in its Kerberized IPsec section, and all of 237 the focus team members who played a part in the spec. We must 238 also acknowledge Nancy Davoust of Cablelabs for keeping order 239 in our normally disorderly proceedings. 241 References 243 [1] The CAT Working Group, J. Kohl, C.Neuman, "The Kerberos Network 244 Authentication Service (V5)", RFC 1510, September 1993 246 [2] The IPsec Working Group, S. Kent, R. Atkinson, "Security Architec- 247 ture for the Internet Protocol", RFC 2401, November 1998 249 [3] The IPsec Working Group, D. Harkins, D. Carrel, "The Internet Key 250 Exchange", RFC 2409, November 1998 252 Author's Address 254 Michael Thomas 255 Cisco Systems 256 375 E Tasman Rd 257 San Jose, Ca, 95134, USA 258 Tel: +1 408-525-5386 259 E-MAIL: mat@cisco.com