2.6.5 Kerberized Internet Negotiation of Keys (kink)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 23-Oct-00


Derek Atkins <warlord@mit.edu>
J Trostle <jtrostle@cisco.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>

Security Area Advisor:

Marcus Leech <mleech@nortelnetworks.com>

Mailing Lists:

General Discussion:ietf-kink@vpnc.org
To Subscribe: majordomo@vpnc.org
In Body: subscribe ietf-kink
Archive: www.vpnc.org/ietf-kink/

Description of Working Group:

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 that does not require public key operations, and is compatible with existing and future Kerberos infrastructures.

The working group will not require changes to either IPsec (RFC 2401), or Kerberos (RFC 1510).

Goals and Milestones:

Sep 00


Reach Consensus on requirements document

Dec 00


Meet at San Diego IETF to review drafts

Jan 01


Reach Consensus on base draft protocol

Feb 01


Conduct WG last call on base draft prototol

Mar 01


Begin Interoperability bakeoffs

Aug 01


Document interoperability results. Make decision to recycle or move forward


No Request For Comments

Current Meeting Report

KINK WG Meeting Minutes (49th IETF at San Diego, CA, Tuesday, Dec. 12)

Reported by Lisa Dussealt and Jonathan Trostle


The first meeting of the KINK WG took place on December 12th, Tuesday 1-2PM at the 49th IETF. Derek Atkins and Jonathan Trostle opened the meeting with the following list of agenda items:

KINK Agenda:
KINK Requirements Draft - Mike Thomas
KINK Key Management Draft - Mike Thomas
Server Initiated Authentication - Sasha Medvinsky
Artificial Phase 1 SA Key Management Draft - Tero Kivinen

The immediate goals of the WG are to move the requirements draft into WG last call in January, and to proceed with standardization of a key management specification.


The WG chairs plan to put the requirements draft into WG last call in January.

The current requirements draft specifies that both symmetric key and public key (pkinit) clients must be supported; it was suggested that initial authentication is outside the scope of the draft. Initial authentication is mentioned in the draft since pkinit clients will not generally have a symmetric key in the Kerberos database, and the draft needs to accomodate such clients acting as servers (by using user-user authentication). The latter is a required scenario for packetcable security.

There was some discussion on the list of whether the protocol must be capable of rekeying, but this seems to be outside of the scope of the work. Currently this is in the requirements document. Paul Hoffman stated that he would discuss it on the list. Derek stated that although it's a good goal to have, it's not a hard requirement.

The question was raised whether there ought to be a requirement to work with IPSP. Marcus Leech stated that it should be the other way around: IPSP ought to work with the policies. KINK is an effector of these policies.

Paul Hoffman mentioned that there was also interest in using other authentication protocols to fake a phase 1 SA in the same manner that Tero Kivinen's draft uses Kerberos to create the artificial phase 1 SA. For now, a general mechanism to allow other authentication mechanisms to be plugged in is out of scope.

An audience member asked whether there ought to be motivation in the draft as well as requirements. In particular, more details on why RFC 2409 (IKE) is not adequate to solve the set of scenarios being targetted by the WG are desired. Derek and Mike Thomas indicated that additional concrete motivational suggestions would be welcome. Mike also suggested that the design documents explain the reasoning behind their choices.

Scott Fluhrer asked about requirements for peer discovery; Jonathan Trostle replied that if you don't know who your peer is then there would be issues with respect to who you are authenticating. Mike stated that the issue appeared to be orthogonal.


Michael Thomas led this discussion. The goals of the draft are to use Kerberos (AP_REQ and AP_REP) messages to establish an IPSEC SA using two messages (or three messages in some cases). The protocol uses a command, reply, and ack messages exchange:

Initiator -------------> Responder

Initiator <------------ Responder

Initiator -------------> Responder

Several message types are defined (create, delete, etc.) and these messages use a sequence of ISAKMP defined payloads (currently these payloads are defined by value in the draft). For example, the ISAKMP SA, proposal, and transform payloads are used in the create message to create a new SA.

The draft also defines new messages to be used to obtain a peer's Kerberos ticket granting ticket (TGT) and to send a TGT to the peer, so that user-user authentication can be used. Using user-user authentication handles the case where the client is a pkinit client and does not have a long term key in the Kerberos database.

Key derivation for the IPSEC SA is defined in the draft. The key derivation can be accomplished in the two message exchange if the responder is willing to not contribute to the keys for its outbound SA. If not, the responder sets the ack bit in the reply and the initiator will use the responder nonce as additional input into its inbound SA keys. Both initiator and responder nonces are used as input into the initiator's outbound SA keys.

Mike Thomas sent some mail to the list regarding what is needed in order to rekey a security association. Jesse Walker's contention was that the text in the draft was not explicit enough, so Mike took some of his input from his last mail, and the current text is the result.

Mike stated that we need to create a new SA that describes the new SA, basically for the same flow, and set up some rules for which SA to use at which times. Mike solicits comments on the WG list.

Mike wants to clarify whether the initiator or responder can kill off whatever SA they like.

Mike would like more examination of the key derivation material in the draft. He indicated that more work is needed on the error messages too. Mike looked at Freeswan/Pluto and hopes to have an implementation by the next IETF (March 2001).


Sasha led the discussion here. Sasha's main concern is in a packetcable scenario where there are many clients communicating with a single server. There is a standby server that takes over when the first server fails. With the existing KINK draft user to user approach, the server must request the client's TGT and then obtain a service ticket targetted at the client. Sasha would like to send a new message, the wakeup message, from the server to the client to indicate to the client that it should obtain a service ticket for the server and then authenticate to the server. Thus some of the work is shifted from the server to the client thus improving scalability and performance of the server in this failover scenario.

One concern that was expressed regarding Sasha's approach is that 3rd party denial of service attacks would be easy to launch and potentially difficult to track. In particular, a malicious peer could send wakeups (which are unauthenticated) to a large number of clients in order to bring down a given server(s) and also temporarily remove a KDC from service. Additionally, data would not flow earlier on the IPSEC SA. Alternative solutions include the sharing the ticket cache between the two servers, and pre-establishment of IPSEC SA's between the clients and the backup server.

Sasha also raised some concerns regarding authorization data in tickets when using user-user authentication. Matt Hur and others disagreed with this line of reasoning, saying that the KDC could just as easily bind policy and authorization data for either the client or the server into the ticket.

Additionally, some denial of service attacks might be mitigated if the client has an access control list which would prevent some wake up requests from being acted upon. Access control lists would not be applicable in all environments, and would only partially mitigate denial of service attacks in environments where they could be used.

There was a desire to resolve this issue at the WG meeting rather than move the discussion to the WG list, but since roughly 10 people had read the draft, it was decided to move the discussion to the list and obtain consensus there.


Tero Kivinen presented his draft for KINK key management: draft-ietf-kink-ike-over-kkmp-00.txt. The draft uses a newly defined Kerberos payload to exchange the AP_REQ and AP_REP messages. At that point, the two peers share the Kerberos session key which is used to create the following shared state (corresponding to a successful phase 1 exchange): cookies, SKEYID for key material, and IV.

Everything that is in IKE phase 2 can be supported: new group mode, quick mode, etc.

Tero claimed that his draft is quite simple to implement. Tero has implemented IKE, and he stated that his new draft would take one day to implement.

Tero also stated that any new features or improvements to phase 2 IKE could also be reflected in his work since it builds upon IKE. Tero noted that he needed to add the capability for Kerberos user-user messages. The Kerberos payload message in his draft could be used to transport KRB_TGT_REQ and KRB_TGT_REPLY messages, in order to support user to user messages.

An audience member questioned the possibility of replays. Tero stated that if the SA is already valid, then they see there is duplicate SA numbers so they drop the packet immediately. When it doesn't see any traffic coming through, it doesn't do any expensive calculation. Derek pointed out that the Kerberos authenticator contains a timestamp to prevent replays.

Another audience member also asked whether the Kerberos session key was big enough; the response was that the key is typed so it will be the right size for whatever crypto algorithm is being used.


KINK Working Group
Running IKE Phase 2 over Artificial Kerberos IKE SA
Alternative to user-to-user Kerberos in KINK