The working group will not require changes to either IPsec (RFC 2401), or Kerberos (RFC 1510).
|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|
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.
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.
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.
IETF 52 KINK UPDATE