RFC 3129

Network Working Group RFC 3129 💖

okay bestie, let's get into RFC 3129 🎀 It's titled Requirements for Kerberized Internet Negotiation of Keys. Michael Thomas from Cisco Systems wrote it, and it came out in June 2001. The category is Informational, so it's sharing ideas, not setting a standard ✨ The title block doesn't list anything it obsoletes or updates, so it's a fresh start 🦋

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 💅

Copyright Notice 🌸

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract 🧚

The goal of this document is to produce a streamlined, fast, easily managed, and cryptographically sound protocol without requiring public key. Basically they want the speed and vibes of a secure keying protocol without needing public keys 🔥

Motivation 💜

okay so the IPsec working group has defined a bunch of protocols that let you create and keep up cryptographically secure security associations at layer three (aka the IP layer) 🦋 This effort ended up producing two different 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 also made a peer to peer authentication and keying mechanism, IKE (RFC 2409) 🍓 The drawback of a peer to peer protocol is that each peer must know and implement a site's security policy, which in practice can be super complex 😭 Plus, with no trusted third party, you need Diffie Hellman (DH) to set up a shared secret. DH is computationally quite expensive and prone to denial of service attacks, which is not it 💀 IKE also leans on X.509 certificates for scalable authentication of peers. Digital signatures are computationally expensive too, and certificate based trust models are hard to deploy in practice. IKE does allow pre-shared symmetric keys, but key distribution is required between all peers. That's an O(n^2) problem, which gets messy for large deployments 🙈

Now, Kerberos (RFC 1510) gives you trusted third party authentication for clients and servers 👑 Clients authenticate to a centralized server, the Key Distribution Center, which then issues tickets that servers can decrypt. That proves the client is who it claims to be ✨ One element of a Kerberos ticket is a session key generated by the KDC, which the client and server can use to share a secret. Kerberos also supports both symmetric key authentication and certificate based public key authentication (PKinit) 🌈 Since the KDC handles the authentication phase, servers don't need to do expensive DH or X.509 certificate signing and verification operations. Clients can use X.509 certificates too, and that authentication phase can be amortized over the lifetime of the credentials. So one DH and certificate exchange can key security associations with many servers in a computationally economic way, which is honestly iconic 😭 Kerberos also supports clients with symmetric keys. Unlike IKE, though, those symmetric keys are stored in the KDC, which makes the number of keys an O(n) problem instead of O(n^2) 💅 Kerberos also lets security policy be managed more centrally, so you don't have to hope every possibly untrustworthy peer follows an organization's stated policies 🫶

The KINK working group takes these basic Kerberos features and uses them to its advantage. The goal is a protocol that 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 KINK cannot reproduce: the ability for two peers to mutually authenticate and exchange keys without needing an actively participating third party. Still, there are plenty of situations where a trusted third party that proxies authentication is viable, and honestly desirable 🎀

Kerberos specifies a standard protocol between the client and the KDC for getting tickets, but the actual ticket exchange between client and server is application specific. KINK is meant to be an alternative to every application having its own way of transporting and validating service tickets 🧚 It uses a protocol that's efficient and tailored to what Kerberos and its applications need for keying and parameter negotiation ✨

So, given all that, a new general keying protocol that 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 protocol 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 association 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 public 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 an 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 participate 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 tunnel 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 requirement 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)
   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, plus 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] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
• [2] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
• [3] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.

Author's Address 💌

   Michael Thomas
   Cisco Systems
   375 E Tasman Rd
   San Jose, Ca, 95134, USA

   Phone: +1 408-525-5386
   EMail: mat@cisco.com

Full Copyright Statement 🌈

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society ✨