idnits 2.17.1 draft-ietf-kink-reqmt-02.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 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 (March 1, 2001) is 8457 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 192 looks like a reference -- Missing reference section? '2' on line 195 looks like a reference -- Missing reference section? '3' on line 198 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. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT KINK Requirements Michael Thomas 2 Cisco Systems 3 March 1, 2001 5 Kerberized Internet Negotiation of Keys 7 draft-ietf-kink-reqmt-02.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The KINK working group is chartered to create a standards track 31 protocol to facilitate centralized key management for IPsec security 32 associations as defined in RFC 2401, as an alternative to IKE (RFC 33 2409). Participating systems will use the Kerberos architecture as 34 defined in RFC 1510 (and its successors) for key management. The goal 35 of the working group is to produce a streamlined, fast, easily 36 managed, and cryptographically sound protocol without requiring 37 public key. 39 The working group will not require changes to either IPsec (RFC 40 2401), or Kerberos (RFC 1510). 42 Motivation 44 The IPsec working group has defined a number of protocols which 45 provide the ability to create and maintain cryptographically secure 46 security associations at layer three (ie, the IP layer). This effort 47 has produced two distinct protocols: 49 1) a mechanism to encrypt and authenticate IP datagram payloads which 50 assumes a shared secret between the sender and receiver 52 2) a mechanism for IPsec peers to perform mutual authentication and 53 exchange keying material 55 The IPsec working group has defined a peer to peer authentication and 56 keying mechanism, IKE (RFC 2409). One of the drawbacks of a peer to 57 peer protocol is that each peer must know and implement a site's 58 security policy which in practice can be quite complex. In addition, 59 the lack of a trusted third party requires the use of Diffie Hellman 60 (DH) to establish a shared secret. DH, unfortunately, is computation- 61 ally quite expensive and prone to denial of service attacks. IKE also 62 relies on X.509 certificates to realize scalable authentication of 63 peers. Digital signatures are also computationally expensive and cer- 64 tificate based trust models are difficult to deploy in practice. 65 While IKE does allow for pre-shared symmetric keys, key distribution 66 is required between all peers -- an O(n^2) problem -- which is prob- 67 lematic for large deployments. 69 Kerberos (RFC 1510) provides a mechanism for trusted third party 70 authentication for clients and servers. Clients authenticate to a 71 centralized server -- the Key Distribution Center -- which in turn 72 issues tickets that servers can decrypt thus proving that the client 73 is who it claims to be. One of the elements of a Kerberos ticket is a 74 session key which is generated by the KDC which may be used by the 75 client and server to share a secret. Kerberos also allows for both 76 symmetric key authentication, as well as certificate based public key 77 authentication (PKinit). Since the authentication phase of Kerberos 78 is performed by the KDC, there is no need to perform expensive DH or 79 X.509 certificate signatures/verification operations on servers. 80 While clients may authenticate using X.509 certificates, the authen- 81 tication phase can be amortized over the lifetime of the credentials. 82 This allows a single DH and certificate exchange to be used to key 83 security associations with many servers in a computationally economic 84 way. Kerberos also support clients with symmetric keys but unlike 85 IKE, the symmetric keys are stored in the KDC making the number of 86 keys an O(n) problem rather than O(n^2). Kerberos also allows secu- 87 rity policy to be managed in a more centralized fashion, rather than 88 expecting each potentially untrustworthy peer to abide by stated 89 security policies of an organization. 91 The KINK working group takes these basic features of Kerberos and 92 uses them to its advantage to create a protocol which can establish 93 and maintain IPsec security associations (RFC 2401). It should be 94 noted that KINK is not a replacement for IKE. IKE has one property 95 which KINK cannot reproduce: the ability for two peers to mutually 96 authenticate and exchange keys without the need for an actively par- 97 ticipating third party. However, there are many situations where a 98 trusted third party which proxies authentication is viable, and in 99 fact desirable. 101 While Kerberos specifies a standard protocol between the client and 102 the KDC to get tickets, the actual ticket exchange between client and 103 server is application specific. KINK is intended to be an alterna- 104 tive to requiring each application having its own method of tran- 105 sporting and validating service tickets using a protocol which is 106 efficient and tailored to the specific needs of Kerberos and the 107 applications for which it provides keying and parameter negotiation. 109 Given the above, a new general keying protocol which leverages the 110 scalability of Kerberos is desirable. The working group's first task 111 is to define this protocol and define an domain of interpretation for 112 IPsec to establish and maintain IPsec security associations. The pro- 113 tocol must be able to take full advantage of the features of RFC 2401 114 but in the context of a centralized keying authority. 116 Requirements 118 KINK must meet the following requirements at a minimum: 120 - The protocol must use the session keys found in Kerberos tickets as 121 the basis of the keying material used for IPsec security associa- 122 tion keys. 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. In other words, 129 either IPsec peer can be the initiator or responder, regardless of 130 whether it's a Kerberos 'client' (TGT-only) or Kerberos 'server' 131 (has a keytab). 133 - The protocol must support Kerberos using either secret key, or pub- 134 lic key (PKINIT) initial authentication. 136 - The protocol must support Kerberos User-to-User mode for cases in 137 which the initiator cannot obtain an AP_REQ for the responder (i.e. 138 the responder is a PKINIT client) or the responder cannot decrypt 139 and AP_REQ from the initiator (i.e. the responder doesn't have a 140 Kerberos Keytab, just a TGT). 142 - The protocol must be able to allow a peer to authenticate and par- 143 ticipate in many realms 145 - The protocol must handle absolute time skew gracefully 147 - The protocol must be able to create, modify, rekey, and delete 148 security associations 150 - The protocol must be capable of setting up both transport and tun- 151 nel modes of IPsec 153 - The protocol must be capable of setting up both AH and ESP security 154 associations 156 - The protocol must be capable of negotiating cipher suites 158 - The protocol must be capable of setting up IPsec flow selectors 160 - The protocol must be capable of rekeying without the assistance of 161 the KDC if the Kerberos session ticket is still valid 163 - The protocol must make an effort to mitigate third party Denial of 164 Service attacks (aka Zombies attacks) 166 - The protocol must be able to be used for more than IPsec keying 168 - The protocol must support both IPv4 and IPv6 170 Acknowledgments 172 The original KINK Kabal was: 174 Michael Thomas (Cisco) 175 David McGrew (Cisco) 176 Jan Vilhuber (Cisco) 177 Jonathan Trostle (Cisco) 178 Matt Hur (Cybersafe) 179 Mike Froh (Cybersafe) 180 Sasha Medvinsky (GI) 181 Derek Atkins (Telcordia) 183 It must also be acknowledged that the Packetcable Security 184 specification PKT-SP-SEC-I01-991201 provided the raw fodder 185 for this effort in its Kerberized IPsec section, and all of 186 the focus team members who played a part in the spec. We must 187 also acknowledge Nancy Davoust of Cablelabs for keeping order 188 in our normally disorderly proceedings. 190 References 192 [1] The CAT Working Group, J. Kohl, C.Neuman, "The Kerberos Network 193 Authentication Service (V5)", RFC 1510, September 1993 195 [2] The IPsec Working Group, S. Kent, R. Atkinson, "Security Architec- 196 ture for the Internet Protocol", RFC 2401, November 1998 198 [3] The IPsec Working Group, D. Harkins, D. Carrel, "The Internet Key 199 Exchange", RFC 2409, November 1998 201 Author's Address 203 Michael Thomas 204 Cisco Systems 205 375 E Tasman Rd 206 San Jose, Ca, 95134, USA 207 Tel: +1 408-525-5386 208 E-MAIL: mat@cisco.com