6.3. CREATE Message
This message initiates an establishment of new security
association(s). The CREATE message must contain an AP-REQ payload
and any DOI-specific payloads.
CREATE KINK Header
KINK_AP_REQ
[KINK_ENCRYPT]
KINK_ISAKMP payloads
SA Payload
Proposal Payloads
Transform Payloads
Nonce Payload (Ni)
[KE]
[IDci, IDcr]
[Notification Payloads]
Replies are of the following forms:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_ISAKMP payloads
SA Payload
Proposal Payloads
Transform Payload
[Nonce Payload (Nr)]
[KE]
[IDci, IDcr]
[Notification Payloads]
Note that there MUST be at least a single proposal payload and a
single transform payload in REPLY messages. There will be multiple
proposal payloads only when an SA bundle is negotiated. Also: unlike
IKE, the Nonce payload Nr is not required, and if it exists, an
acknowledgement must be requested to indicate that the initiator’s
outgoing SAs must be modified. If any of the first proposals are not
chosen by the recipient, it SHOULD include the Nonce payload.
KINK, like IKE, allows the creation of many SAs in one create
command. If any of the optimistic proposals are not chosen by the
responder, it MUST request an ACK.
If an IPsec DOI-specific error is encountered, the responder must
reply with a Notify payload describing the error:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP payloads
[Notification Payloads]
If the responder finds a Kerberos error for which it can produce a
valid authenticator, the REPLY takes the following form:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_KRB_ERROR
Finally, if the responder finds a Kerberos or KINK type of error for
which it cannot create an AP-REP, it MUST reply with a lone
KINK_KRB_ERROR or KINK_ERROR payload:
REPLY KINK Header
[KINK_KRB_ERROR]
[KINK_ERROR]
6.4. DELETE Message
This message indicates that the sending peer has deleted or will
shortly delete Security Association(s) with the other peer.
DELETE KINK Header
KINK_AP_REQ
[KINK_ENCRYPT]
KINK_ISAKMP payloads
Delete Payloads
[Notification Payloads]
There are three forms of replies for a DELETE. The normal form is:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP payloads
Delete Payloads
[Notification Payloads]
If an IPsec DOI-specific error is encountered, the responder must
reply with a Notify payload describing the error:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP payloads
[Notification Payloads]
If the responder finds a Kerberos error for which it can produce a
valid authenticator, the REPLY takes the following form:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_KRB_ERROR
If the responder finds a KINK or Kerberos type of error, it MUST
reply with a lone KINK_KRB_ERROR or KINK_ERROR payload:
REPLY KINK Header
[KINK_KRB_ERROR]
[KINK_ERROR]
6.5. STATUS Message
The STATUS command is used in two ways:
1) As a means to relay an ISAKMP Notification message.
2) As a means of probing a peer whether its epoch has changed for
dead peer detection.
STATUS contains the following payloads:
KINK Header
KINK_AP_REQ
[[KINK_ENCRYPT]
KINK_ISAKMP payload
[Notification Payloads]]
There are three forms of replies for a STATUS. The normal form is:
REPLY KINK Header
KINK_AP_REP
[[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP payload
[Notification Payloads]]
If the responder finds a Kerberos error for which it can produce a
valid authenticator, the REPLY takes the following form:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_KRB_ERROR
If the responder finds a KINK or Kerberos type of error, it MUST
reply with a lone KINK_KRB_ERROR or KINK_ERROR payload:
REPLY KINK Header
[KINK_KRB_ERROR]
[KINK_ERROR]
6.6. GETTGT Message
A GETTGT command is only used to carry a Kerberos TGT and is not
related to SA management; therefore, it contains only KINK_TGT_REQ
payload and does not contain any DOI-specific payload.
There are two forms of replies for a GETTGT. In the normal form,
where the responder is allowed to return its TGT, the REPLY contains
KINK_TGT_REP payload. If the responder is not allowed to return its
TGT, it MUST reply with a KINK_ERROR payload.
7. ISAKMP Key Derivation
KINK uses the same key derivation mechanisms defined in section 5.5
of [IKE], which is:
KEYMAT = prf(SKEYID_d, [g(qm)^xy |] protocol | SPI | Ni_b [| Nr_b])
The following differences apply:
o prf is the pseudo-random function corresponding to the session
key’s etype. They are defined in [KCRYPTO].
o SKEYID_d is the session key in the Kerberos service ticket
from the AP-REQ. Note that subkeys are not used in KINK and
MUST be ignored if received.
o Both Ni_b and Nr_b are the part of the Nonce payloads (Ni and
Nr, respectively) as described in section 3.2 of [IKE]. Nr_b
is optional, which means that Nr_b is treated as if a zero
length value was supplied when the responder’s nonce (Nr) does
not exist. When Nr exists, Nr_b MUST be included in the
calculation.
Note that g(qm)^xy refers to the keying material generated when KE
payloads are supplied using Diffie-Hellman key agreement. This is
explained in section 5.5 of [IKE].
The rest of the key derivation (e.g., how to expand KEYMAT) follows
IKE. How to use derived keying materials is up to each service
(e.g., section 4.5.2 of [IPSEC]).
8. Key Usage Numbers for Kerberos Key Derivation
Kerberos encrypt/decrypt functions and get_mic/verify_mic functions
require "key usage numbers". They are used to generate specific keys
for cryptographic operations so that different keys are used for
different purposes/objects. KINK uses two usage numbers, listed
below.
Purpose Usage number
------- ------------
KINK_ENCRYPT payload (for encryption) 39
Cksum field (for checksum) 40
9. Transport Considerations
KINK uses UDP on port 910 to transport its messages. There is one
timer T which SHOULD take into consideration round-trip
considerations and MUST implement a truncated exponential back-off
mechanism. The state machine is simple: any message that expects a
response MUST retransmit the request using timer T. Since Kerberos
requires that messages be retransmitted with new times for replay
protection, the message MUST be re-created each time including the
checksum of the message. Both commands and replies with the ACKREQ
bit set are kept on retransmit timers. When a KINK initiator
receives a REPLY with the ACKREQ bit set, it MUST retain the ability
to regenerate the ACK message for the transaction for a minimum of
its full retransmission timeout cycle or until it notices that
packets have arrived on the newly constructed SA, whichever comes
first.
When a KINK peer retransmits a message, it MUST create a new Kerberos
authenticator for the AP-REQ so that the peer can differentiate
between replays and dropped packets. This results in a potential
race condition when a retransmission occurs before an in-flight reply
is received/processed. To counter this race condition, the
retransmitting party SHOULD keep a list of valid authenticators that
are outstanding for any particular transaction.
When a KINK peer retransmits a command, it MUST use the same ticket
within the retransmissions. This is to avoid race conditions on
using different keys, which result in different KEYMATs between an
initiator and a responder. For this reason, (1) an initiator MUST
obtain a ticket whose lifetime is greater than the initiator’s
maximum transaction time including timeouts, or (2) it MUST continue
to use the same ticket within a set of retransmissions, and iff it
receives an error (most likely KRB_AP_ERR_TKT_EXPIRED) from the
responder, it starts a new transaction with a new ticket.
10. Security Considerations
The principal names are the identities of the KINK services, but the
traffic protected by SAs are identified by DOI-specific selectors (IP
addresses, port numbers, etc.). This may lead to a breakaway of
SA-protected data from authentication. For example, if two different
hosts claim that they have the same IP address, it may be impossible
to predict which principal’s key protects the data. Thus, an
implementation must take care for the binding between principal names
and the SA selectors.
Sending errors without cryptographic protection must be handled very
carefully. There is a trade-off between wanting to be helpful in
diagnosing a problem and wanting to avoid being a dupe in a denial of
service attack.
KINK cobbles together and reuses many parts of both Kerberos and IKE,
the latter which in turn is cobbled together from many other memos.
As such, KINK inherits many of the weaknesses and considerations of
each of its components. However, KINK uses only IKE phase 2 payloads
to create and delete SAs; the security considerations which pertain
to IKE phase 1 may be safely ignored. However, being able to ignore
IKE’s authentication phase necessarily means that KINK inherits all
of the security considerations of Kerberos authentication as outlined
in [KERBEROS]. For one, a KDC, like an Authentication,
Authorization, and Accounting (AAA) server, is a point of attack and
all that implies. Much has been written about various shortcomings
and mitigations of Kerberos, and they should be evaluated for any
deployment.
KINK’s use of Kerberos presents a couple of considerations. First,
KINK explicitly expects that the KDC will provide adequate entropy
when it generates session keys. Second, Kerberos is used as a user
authentication protocol with the possibility of dictionary attacks on
user passwords. This memo does not describe a particular method to
avoid these pitfalls, but recommends that suitable randomly generated
keys should be used for the service principals such as using the
-randomkey option with MIT’s "kadmin addprinc" command as well as for
clients when that is practical.
Kerberos does not currently provide perfect forward secrecy in
general. KINK with the KE payload can provide PFS for a service key
from a Kerberos key, but the KE is not mandatory because of the
computational cost. This is a trade-off and operators can choose the
PFS over the cost, and vice versa. KINK itself should be secure from
offline analysis from compromised principal passphrases if PFS is
used, but from an overall system’s standpoint, the existence of other
Kerberized services that do not provide PFS makes this a less than
optimal situation.
11. IANA Considerations
The IANA has assigned a well-known port number for KINK.
The IANA has created a new registry for KINK parameters, and has
registered the following identifiers.
KINK Message Types (section 4)
KINK Next Payload Types (section 4.2)
KINK Error Codes (section 4.2.8)
Changes and additions to this registry follow the policies described
below. Their meanings are described in [BCP26].
o Using the numbers in the "Private Use" range is Private Use.
o Assignment from the "RESERVED TO IANA" range needs Standards
Action, or non-standards-track RFCs with Expert Review.
(Though the full specification may be a public and permanent
document of a standards body other than IETF, an RFC referring
it is needed.)
o Other change requires Standards Action.
12. Forward Compatibility Considerations
KINK can accommodate future versions of Quick Mode through the use of
the version field in the ISAKMP payload as well as new domains of
interpretation. In this memo, the only supported Quick Mode version
is 1.0, which corresponds to [IKE]. Likewise, the only DOI supported
is the IPsec domain of interpretation [IPDOI]. New Quick Mode
versions and DOIs MUST be described in subsequent memos.
KINK implementations MUST reject ISAKMP versions that are greater
than the highest currently supported version with a KINK_BADQMVERS
error type. A KINK implementation that receives a KINK_BADQMVERS
message SHOULD be capable of reverting back to version 1.0.
12.1. New Versions of Quick Mode
The IPsec working group is defining the next-generation IKE protocol
[IKEv2], which does not use Quick Mode, but it is similar to the one
in IKEv1. The difference between the two is summarized in Appendix A
of [IKEv2]. Each of them must be considered in order to use IKEv2
with KINK.
12.2. New DOI
The KINK message header contains a field called "Domain of
Interpretation (DOI)" to allow other domains of interpretation to use
KINK as a secure transport mechanism for keying.
As one example of a new DOI, the MSEC working group defined the Group
Domain of Interpretation [GDOI], which defines a few new messages,
which look like ISAKMP messages, but are not defined in ISAKMP.
In order to carry GDOI messages in KINK, the DOI field in the KINK
header would indicate that GDOI is being used, instead of IPSEC-DOI,
and the KINK_ISAKMP payload would contain the payloads defined in the
GDOI document rather than the payloads used by [IKE] Quick Mode. The
version number in the KINK_ISAKMP header is related to the DOI in the
KINK header, so a maj.min version 1.0 under DOI GDOI is different
from a maj.min version 1.0 under DOI IPSEC-DOI.
13. Related Work
The IPsec working group has defined a number of protocols that
provide the ability to create and maintain cryptographically secure
SAs at layer three (i.e., the IP layer). This effort has produced
two distinct protocols:
o a mechanism for encrypting and authenticating IP datagram
payloads that assumes a shared secret between the sender and
receiver
o 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 peer-to-peer nature of IKE requires the use of Diffie-
Hellman (DH) to establish a shared secret. DH, unfortunately, is
computationally 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 certificate-based trust models are difficult to deploy
in practice. While IKE does allow for a pre-shared key, key
distribution is required between all peers -- an O(n^2) problem --
which is problematic for large deployments.
14. Acknowledgements
Many have contributed to the KINK effort, including our working group
chairs Derek Atkins and Jonathan Trostle. The original inspiration
came from CableLab’s PacketCable effort, which defined a simplified
version of Kerberized IPsec, including Sasha Medvinsky, Mike Froh,
and Matt Hur and David McGrew. The inspiration for wholly reusing
IKE phase 2 is the result of Tero Kivinen’s document suggesting
grafting Kerberos authentication onto Quick Mode.
15. References
15.1. Normative References
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IPDOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J.
Turner, "Internet Security Association and Key
Management Protocol (ISAKMP)", RFC 2408, November 1998.
[ISAKMP-REG] IANA, "Internet Security Association and Key Management
Protocol (ISAKMP) Identifiers",
<http://www.iana.org/assignments/isakmp-registry>.
[KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications
for Kerberos 5", RFC 3961, February 2005.
[KERBEROS] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC
4120, July 2005.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
15.2. Informative References
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney,
"The Group Domain of Interpretation", RFC 3547, July
2003.
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[PKINIT] Zhu, L. and B. Tung, "Public Key Cryptography for
Initial Authentication in Kerberos", Work in Progress,
February 2006.
[REQ4KINK] Thomas, M., "Requirements for Kerberized Internet
Negotiation of Keys", RFC 3129, June 2001.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
Authors’ Addresses
Shoichi Sakane
Yokogawa Electric Corporation
2-9-32 Nakacho, Musashino-shi,
Tokyo 180-8750 Japan
EMail: Shouichi.Sakane@jp.yokogawa.com
Ken’ichi Kamada
Yokogawa Electric Corporation
2-9-32 Nakacho, Musashino-shi,
Tokyo 180-8750 Japan
EMail: Ken-ichi.Kamada@jp.yokogawa.com
Michael Thomas
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
EMail: mat@cisco.com
Jan Vilhuber
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
EMail: vilhuber@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).