As per Relevance of the word security, we have this rfc below:
Network Working Group M.
Request for Comments: 3129 Cisco
Category: Informational June 2001
Requirements for Kerberized Internet Negotiation of
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
The goal of this document is to produce a streamlined, fast,
managed, and cryptographically sound protocol without
public key
The IPsec working group has defined a number of protocols
provide the ability to create and maintain cryptographically
security associations at layer three (i.e., the IP layer).
effort has produced two distinct protocols
1) a mechanism to encrypt and authenticate IP datagram payloads
assumes a shared secret between the sender and
2) a mechanism for IPsec peers to perform mutual authentication
exchange keying
The IPsec working group has defined a peer to peer authentication
keying mechanism, IKE (RFC 2409). One of the drawbacks of a peer
peer protocol is that each peer must know and implement a site'
security policy which in practice can be quite complex. In addition
the lack of a trusted third party requires the use of Diffie
(DH) to establish a shared secret. DH, unfortunately,
computationally quite expensive and prone to denial of
attacks. IKE also relies on X.509 certificates to realize
authentication of peers. Digital signatures are also
expensive and certificate based trust models are difficult to
Thomas Informational [Page 1]
RFC 3129 Requirements for KINK June 2001
in practice. While IKE does allow for pre-shared symmetric keys,
distribution is required between all peers -- an O(n^2) problem --
which is problematic for large deployments
Kerberos (RFC 1510) provides a mechanism for trusted third
authentication for clients and servers. Clients authenticate to
centralized server -- the Key Distribution Center -- which in
issues tickets that servers can decrypt thus proving that the
is who it claims to be. One of the elements of a Kerberos ticket
a session key which is generated by the KDC which may be used by
client and server to share a secret. Kerberos also allows for
symmetric key authentication, as well as certificate based public
authentication (PKinit). Since the authentication phase of
is performed by the KDC, there is no need to perform expensive DH
X.509 certificate signatures/verification operations on servers
While clients may authenticate using X.509 certificates,
authentication phase can be amortized over the lifetime of
credentials. This allows a single DH and certificate exchange to
used to key security associations with many servers in
computationally economic way. Kerberos also support clients
symmetric keys but unlike IKE, the symmetric keys are stored in
KDC making the number of keys an O(n) problem rather than O(n^2).
Kerberos also allows security policy to be managed in a
centralized fashion, rather than expecting each
untrustworthy peer to abide by stated security policies of
organization
The KINK working group takes these basic features of Kerberos
uses them to its advantage to create a protocol which can
and maintain IPsec security associations (RFC 2401). It should
noted that KINK is not a replacement for IKE. IKE has one
which KINK cannot reproduce: the ability for two peers to
authenticate and exchange keys without the need for an
participating third party. However, there are many situations
a trusted third party which proxies authentication is viable, and
fact desirable
While Kerberos specifies a standard protocol between the client
the KDC to get tickets, the actual ticket exchange between client
server is application specific. KINK is intended to be
alternative to requiring each application having its own method
transporting and validating service tickets using a protocol which
efficient and tailored to the specific needs of Kerberos and
applications for which it provides keying and parameter negotiation
Given the above, a new general keying protocol which leverages
scalability of Kerberos is desirable. The working group's first
is to define this protocol and define an domain of interpretation
Thomas Informational [Page 2]
RFC 3129 Requirements for KINK June 2001
IPsec to establish and maintain IPsec security associations.
protocol must be able to take full advantage of the features of
2401 but in the context of a centralized keying authority
KINK must meet the following requirements at a minimum
- The protocol must use the session keys found in
tickets as the basis of the keying material used for
security association keys
- The protocol must be able to integrate into
architecture of IPsec (RFC 2401).
- The protocol must be able to start up SA's regardless of
client/server disposition in the keying protocol. In
words, either IPsec peer can be the initiator or responder
regardless of whether it's a Kerberos 'client' (TGT-only)
Kerberos 'server'(has a keytab).
- The protocol must support Kerberos using either secret key,
public key (PKINIT) initial authentication
- The protocol must support Kerberos User-to-User mode for
in which the initiator cannot obtain an AP_REQ for
responder (i.e. the responder is a PKINIT client) or
responder cannot decrypt 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
participate in many realms
- The protocol must handle absolute time skew gracefully
- The protocol must be able to create, modify, rekey, and
security associations
- The protocol must be capable of setting up both transport
tunnel modes of IPsec
- The protocol must be capable of setting up both AH and
security associations
- The protocol must be capable of negotiating cipher suites
- The protocol must be capable of setting up IPsec
selectors
Thomas Informational [Page 3]
RFC 3129 Requirements for KINK June 2001
- The protocol must be capable of rekeying without the
of the KDC if the Kerberos session ticket is still valid
- The protocol must make an effort to mitigate third party
of Service attacks (aka Zombies attacks).
- The protocol must be able to be used for more than
keying
- The protocol must support both IPv4 and IPv6.
Security
These requirements lay out input to define a protocol which
the keying of IPsec security associations using Kerberos as the
distribution mechanism. As such, the security associations that
be created by the new protocol will inherit the union of IPsec
Kerberos's existing security weaknesses. There is no requirement
address those weaknesses unless in combination they produce a
weakness which is not inherent in other keying protocols
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
specification PKT-SP-SEC-I01-991201 provided the raw fodder for
effort in its Kerberized IPsec section, and all of the focus
members who played a part in the spec. We must also
Nancy Davoust of Cablelabs for keeping order in our
disorderly proceedings
Thomas Informational [Page 4]
RFC 3129 Requirements for KINK June 2001
[1] Kohl, J. and C. Neuman, "The Kerberos
Authentication Service (V5)", RFC 1510, September 1993.
[2] Kent, S. and R. Atkinson, "Security Architecture for
Internet Protocol", RFC 2401, November 1998.
[3] Harkins, D. and D. Carrel, "The Internet
Exchange (IKE)", RFC 2409, November 1998.
Author's
Michael
Cisco
375 E Tasman
San Jose, Ca, 95134,
Phone: +1 408-525-5386
EMail: mat@cisco.
Thomas Informational [Page 5]
RFC 3129 Requirements for KINK June 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Thomas Informational [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
