Requirements for Kerberized Internet Negotiation of Keys
draft-ietf-kink-reqmt-03
The information below is for an old version of the document that is already published as an RFC.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3129.
|
|
---|---|---|---|
Author | Michael Thomas | ||
Last updated | 2013-03-02 (Latest revision 2001-04-30) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | Informational | ||
Formats | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | (None) | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 3129 (Informational) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-kink-reqmt-03
INTERNET-DRAFT Requirements for Kerberized Michael Thomas Internet Negotiation of Keys Cisco Systems April 30, 2001 Requirements for Kerberized Internet Negotiation of Keys draft-ietf-kink-reqmt-03.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The KINK working group is chartered to create a standards track protocol to facilitate centralized key management for IPsec security associations as defined in RFC 2401, as an alternative to IKE (RFC 2409). Participating systems will use the Kerberos architecture as defined in RFC 1510 (and its successors) for key management. The goal of the working group is to produce a streamlined, fast, easily managed, and cryptographically sound protocol without requiring public key. The working group will not require changes to either IPsec (RFC 2401), or Kerberos (RFC 1510). Thomas draft-ietf-kink-reqmt-03 [Page 1] INTERNET-DRAFT Requirements for KINK 30 April 2001 Motivation The IPsec working group has defined a number of protocols which provide the ability to create and maintain cryptographically secure security associations at layer three (ie, the IP layer). This effort has produced two distinct protocols: 1) a mechanism to encrypt and authenticate IP datagram payloads which assumes a shared secret between the sender and receiver 2) a mechanism for IPsec peers to perform mutual authentication and exchange keying material The IPsec working group has defined a peer to peer authentication and keying mechanism, IKE (RFC 2409). One of the drawbacks of a peer to peer protocol is that each peer must know and implement a site's security policy which in practice can be quite complex. In addition, the lack of a trusted third party requires the use of Diffie Hellman (DH) to establish a shared secret. DH, unfortunately, is computation- ally quite expensive and prone to denial of service attacks. IKE also relies on X.509 certificates to realize scalable authentication of peers. Digital signatures are also computationally expensive and cer- tificate based trust models are difficult to deploy in practice. While IKE does allow for pre-shared symmetric keys, key distribution is required between all peers -- an O(n^2) problem -- which is prob- lematic for large deployments. Kerberos (RFC 1510) provides a mechanism for trusted third party authentication for clients and servers. Clients authenticate to a centralized server -- the Key Distribution Center -- which in turn issues tickets that servers can decrypt thus proving that the client is who it claims to be. One of the elements of a Kerberos ticket is a session key which is generated by the KDC which may be used by the client and server to share a secret. Kerberos also allows for both symmetric key authentication, as well as certificate based public key authentication (PKinit). Since the authentication phase of Kerberos is performed by the KDC, there is no need to perform expensive DH or X.509 certificate signatures/verification operations on servers. While clients may authenticate using X.509 certificates, the authen- tication phase can be amortized over the lifetime of the credentials. This allows a single DH and certificate exchange to be used to key security associations with many servers in a computationally economic way. Kerberos also support clients with symmetric keys but unlike IKE, the symmetric keys are stored in the KDC making the number of keys an O(n) problem rather than O(n^2). Kerberos also allows secu- rity policy to be managed in a more centralized fashion, rather than expecting each potentially untrustworthy peer to abide by stated security policies of an organization. Thomas draft-ietf-kink-reqmt-03 [Page 2] INTERNET-DRAFT Requirements for KINK 30 April 2001 The KINK working group takes these basic features of Kerberos and uses them to its advantage to create a protocol which can establish and maintain IPsec security associations (RFC 2401). It should be noted that KINK is not a replacement for IKE. IKE has one property which KINK cannot reproduce: the ability for two peers to mutually authenticate and exchange keys without the need for an actively par- ticipating third party. However, there are many situations where a trusted third party which proxies authentication is viable, and in fact desirable. While Kerberos specifies a standard protocol between the client and the KDC to get tickets, the actual ticket exchange between client and server is application specific. KINK is intended to be an alterna- tive to requiring each application having its own method of tran- sporting and validating service tickets using a protocol which is efficient and tailored to the specific needs of Kerberos and the applications for which it provides keying and parameter negotiation. Given the above, a new general keying protocol which leverages the scalability of Kerberos is desirable. The working group's first task is to define this protocol and define an domain of interpretation for IPsec to establish and maintain IPsec security associations. The pro- tocol must be able to take full advantage of the features of RFC 2401 but in the context of a centralized keying authority. Requirements KINK must meet the following requirements at a minimum: - The protocol must use the session keys found in Kerberos tickets as the basis of the keying material used for IPsec security associa- tion keys. - The protocol must be able to integrate into security architecture of IPsec (RFC 2401) - The protocol must be able to start up SA's regardless of any client/server disposition in the keying protocol. In other words, either IPsec peer can be the initiator or responder, regardless of whether it's a Kerberos 'client' (TGT-only) or Kerberos 'server' (has a keytab). - The protocol must support Kerberos using either secret key, or pub- lic key (PKINIT) initial authentication. - The protocol must support Kerberos User-to-User mode for cases in which the initiator cannot obtain an AP_REQ for the responder (i.e. the responder is a PKINIT client) or the responder cannot decrypt Thomas draft-ietf-kink-reqmt-03 [Page 3] INTERNET-DRAFT Requirements for KINK 30 April 2001 and AP_REQ from the initiator (i.e. the responder doesn't have a Kerberos Keytab, just a TGT). - The protocol must be able to allow a peer to authenticate and par- ticipate in many realms - The protocol must handle absolute time skew gracefully - The protocol must be able to create, modify, rekey, and delete security associations - The protocol must be capable of setting up both transport and tun- nel modes of IPsec - The protocol must be capable of setting up both AH and ESP security associations - The protocol must be capable of negotiating cipher suites - The protocol must be capable of setting up IPsec flow selectors - The protocol must be capable of rekeying without the assistance of the KDC if the Kerberos session ticket is still valid - The protocol must make an effort to mitigate third party Denial of Service attacks (aka Zombies attacks) - The protocol must be able to be used for more than IPsec keying - The protocol must support both IPv4 and IPv6 Security Considerations These requirements lay out input to define a protocol which allows the keying of IPsec security associations using Kerberos as the key distribution mechanism. As such, the security associations that will be created by the new protocol will inherit the union of IPsec and Kerberos's existing security weaknesses. There is no require- ment to address those weaknesses unless in combination they produce a new weakness which is not inherent in other keying protocols. Acknowledgments The original KINK Kabal was: Michael Thomas (Cisco) David McGrew (Cisco) Jan Vilhuber (Cisco) Thomas draft-ietf-kink-reqmt-03 [Page 4] INTERNET-DRAFT Requirements for KINK 30 April 2001 Jonathan Trostle (Cisco) Matt Hur (Cybersafe) Mike Froh (Cybersafe) Sasha Medvinsky (GI) Derek Atkins (Telcordia) It must also be acknowledged that the Packetcable Security specification PKT-SP-SEC-I01-991201 provided the raw fodder for this effort in its Kerberized IPsec section, and all of the focus team members who played a part in the spec. We must also acknowledge Nancy Davoust of Cablelabs for keeping order in our normally disorderly proceedings. References [1] The CAT Working Group, J. Kohl, C.Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993 [2] The IPsec Working Group, S. Kent, R. Atkinson, "Security Architec- ture for the Internet Protocol", RFC 2401, November 1998 [3] The IPsec Working Group, D. Harkins, D. Carrel, "The Internet Key Exchange", RFC 2409, November 1998 Author's Address Michael Thomas Cisco Systems 375 E Tasman Rd San Jose, Ca, 95134, USA Tel: +1 408-525-5386 E-MAIL: mat@cisco.com Thomas draft-ietf-kink-reqmt-03 [Page 5]