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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/