idnits 2.17.1 draft-ietf-kink-reqmt-03.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 4 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 5 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (April 30, 2001) is 8390 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) == Unused Reference: '1' is defined on line 203, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 206, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 209, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1510 (ref. '1') (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 2401 (ref. '2') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (ref. '3') (Obsoleted by RFC 4306) Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Requirements for Kerberized Michael Thomas 3 Internet Negotiation of Keys Cisco Systems 4 April 30, 2001 6 Requirements for Kerberized Internet Negotiation of Keys 8 draft-ietf-kink-reqmt-03.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 the session keys found in Kerberos tickets as 122 the basis of the keying material used for IPsec security associa- 123 tion keys. 125 - The protocol must be able to integrate into security architecture 126 of IPsec (RFC 2401) 128 - The protocol must be able to start up SA's regardless of any 129 client/server disposition in the keying protocol. In other words, 130 either IPsec peer can be the initiator or responder, regardless of 131 whether it's a Kerberos 'client' (TGT-only) or Kerberos 'server' 132 (has a keytab). 134 - The protocol must support Kerberos using either secret key, or pub- 135 lic key (PKINIT) initial authentication. 137 - The protocol must support Kerberos User-to-User mode for cases in 138 which the initiator cannot obtain an AP_REQ for the responder (i.e. 139 the responder is a PKINIT client) or the responder cannot decrypt 140 and AP_REQ from the initiator (i.e. the responder doesn't have a 141 Kerberos Keytab, just a TGT). 143 - The protocol must be able to allow a peer to authenticate and par- 144 ticipate in many realms 146 - The protocol must handle absolute time skew gracefully 148 - The protocol must be able to create, modify, rekey, and delete 149 security associations 151 - The protocol must be capable of setting up both transport and tun- 152 nel modes of IPsec 154 - The protocol must be capable of setting up both AH and ESP security 155 associations 157 - The protocol must be capable of negotiating cipher suites 159 - The protocol must be capable of setting up IPsec flow selectors 161 - The protocol must be capable of rekeying without the assistance of 162 the KDC if the Kerberos session ticket is still valid 164 - The protocol must make an effort to mitigate third party Denial of 165 Service attacks (aka Zombies attacks) 167 - The protocol must be able to be used for more than IPsec keying 169 - The protocol must support both IPv4 and IPv6 171 Security Considerations 173 These requirements lay out input to define a protocol which allows 174 the keying of IPsec security associations using Kerberos as the key 175 distribution mechanism. As such, the security associations that 176 will be created by the new protocol will inherit the union of IPsec 177 and Kerberos's existing security weaknesses. There is no require- 178 ment to address those weaknesses unless in combination they produce 179 a new weakness which is not inherent in other keying protocols. 181 Acknowledgments 183 The original KINK Kabal was: 185 Michael Thomas (Cisco) 186 David McGrew (Cisco) 187 Jan Vilhuber (Cisco) 188 Jonathan Trostle (Cisco) 189 Matt Hur (Cybersafe) 190 Mike Froh (Cybersafe) 191 Sasha Medvinsky (GI) 192 Derek Atkins (Telcordia) 194 It must also be acknowledged that the Packetcable Security 195 specification PKT-SP-SEC-I01-991201 provided the raw fodder 196 for this effort in its Kerberized IPsec section, and all of 197 the focus team members who played a part in the spec. We must 198 also acknowledge Nancy Davoust of Cablelabs for keeping order 199 in our normally disorderly proceedings. 201 References 203 [1] The CAT Working Group, J. Kohl, C.Neuman, "The Kerberos Network 204 Authentication Service (V5)", RFC 1510, September 1993 206 [2] The IPsec Working Group, S. Kent, R. Atkinson, "Security Architec- 207 ture for the Internet Protocol", RFC 2401, November 1998 209 [3] The IPsec Working Group, D. Harkins, D. Carrel, "The Internet Key 210 Exchange", RFC 2409, November 1998 212 Author's Address 214 Michael Thomas 215 Cisco Systems 216 375 E Tasman Rd 217 San Jose, Ca, 95134, USA 218 Tel: +1 408-525-5386 219 E-MAIL: mat@cisco.com