Current Meeting Report
Slides


2.5.4 Kerberized Internet Negotiation of Keys (kink)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 09-Oct-01
Chair(s):
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:
Done   Reach Consensus on requirements document
Done   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
Internet-Drafts:
No Request For Comments

Current Meeting Report

IETF KINK WG Meeting:
9-11AM Monday, December 10th, 2001.
Chairs: Derek Atkins and Jonathan Trostle

The agenda was presented. The topics to be discussed were the KINK protocol and extensibility.

KINK protocol

Mike Thomas released the .02 version of the KINK protocol specification.

The main changes are:

(a) dead peer detection is facilitated with the epoch field which has been added to the protocol messages. By detecting a change in the peer's

epoch value, a KINK protocol entity knows that the peer has gone down and come back up. Thus new SA's can be created, if necessary.

(b) The ack is now required in the SA create exchange if the initiator's

optimistic proposal is not accepted.

(c) KRB_ERROR messages MUST be keyed if the two peers share a secret key. This last change has the issue that existing Kerberos libraries will have to be modified to support this behaviour.

(d) Mike is registering the KINK payloads with IANA.

Extensibility

KINK extensibility was discussed. The main questions are: how does a KINK implementation handle a new payload that it does not recognize? Should payloads be treated as critical or optional? Charlie Kaufman indicated that a son of ike entity would reject a message with an unrecognized major version, but would continue processing a message with

an unrecognized minor version. Radia Perlman suggested that KINK might benefit from a mechanism that allows a peer to know that the other side supports a higher protocol version. Most, but not all, of the KINK protocol error messages will be authenticated, however. In the most common SA creation scenario, (AP_REQ, AP_REP exchange) any error messages would be authenticated.

In addition, Mike indicated that it would be good if KINK is useful for keying IPsec remote access VPN's.

Implementation Status and Future Plans

Derek asked who is planning on implementing KINK. In addition to Mike Thomas, four other people indicated they were planning on implementing the KINK protocol. The chairs plan to ask for WG last call in January, 2002.

Slides

IETF 52 KINK UPDATE