NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Derek Atkins <warlord@mit.edu>
J Trostle <jtrostle@cisco.com>
Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>
Marcus Leech <mleech@nortelnetworks.com>
General Discussion:ietf-kink@vpnc.org
To Subscribe: majordomo@vpnc.org
In Body: subscribe ietf-kink
Archive: www.vpnc.org/ietf-kink/
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).
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 |
50th IETF KINK WG Minutes:
Agenda:
Requirements Last Call
Protocol Update
Open Issues
Next Steps
REQUIREMENTS LAST CALL:
The requirements draft is draft-ietf-kink-reqmt-02.txt. No comments have been received during WG Last Call and the draft will be sent to the IESG shortly. (It may be necessary to update the requirements document to reflect WG consensus on PFS in KINK - see below).
PROTOCOL UPDATE:
Michael Thomas presented an update on draft-ietf-kink-kink-00.txt. To do items include a security considerations section, and additional protocol work for user-user authentication. For user-user, the case where the initiator obtains a service ticket from the KDC is already part of the specification, and one question is whether either the wakeup or the more DoS resistant version proposed by Derek on the WG mail list should be added to the specification. The latter two serve as a mechanism to allow an initiator to indicate to the responder (which could be a pkinit user device) that the responder should obtain the service ticket and send an AP_REQ to the initiator (see below). Mike is implementing the specification in his spare time.
OPEN ISSUES:
Derek initiated the discussion on open issues by presenting several protocol questions to the WG. There are currently two KINK protocol drafts: draft-ietf-kink-kink-00.txt and draft-ietf-kink-ike-over-kkmp-00.txt.
(1) Should the protocol specification use a complete IKE phase 2 quick mode payloads or use a non-IKE compliant set of ISAKMP payloads?
(Note: the first draft in the preceding paragraph takes the second approach whereas the second draft takes the first approach). Several people advocated using the complete IKE phase 2 quick mode due to ease of implementation and deployment. Michael Thomas stated that it is not in our charter to modify IKE and Tero stated that we are not modifying IKE. Tero favors the complete IKE approach to facilitate code reuse. Bill Sommerfeld proposed that we partipate in the son of IKE discussion, and he prefers the complete IKE phase 2 quick mode since it would be less work. Michael Thomas is concerned that there would be too much temptation to have consistent code base with son of IKE and wants a clean break with IKE. Matt Hur concurred and doesn't want to get bogged down with son of IKE. Barbara Fraser stated that son of IKE is not an issue here, and that son of IKE could be limited to bug fixes and cleaning up the specification. Tero believes that we should not wait for son of IKE and that we should copy IKE by value. William Dixon favors the first approach due to the quick mode filtering of his implementation.
Overall, the consensus of the WG was in favor of the first approach (use the complete IKE phase 2 quick mode payloads).
(2) Encode a new ISAKMP Kerberos payload and include KINK completely within the IKE framework, or ignore ISAKMP/IKE and build our own Kerberos packet.
Bill Sommerfeld stated that the second option is not much more work than the first option. The consensus of the WG was to select the second option.
(3) Should the KINK protocol allow a handoff option in the user-user authentication case, where handoff is defined as allowing the initiator to communicate to the responder that the responder should obtain a service ticket targetted at the initiator and send a Kerberos AP_REQ to the initator?
WG consensus here is that the KINK protocol should include a handoff option. The two possibilities are:
(a) wakeup (a single message from the initiator to the responder with the initiator's principal name and realm).
(b) the proposal from the WG list discussion (uses 3 messages and adds protection against DoS attacks).
There was strong WG consensus in favor of (b). The KINK protocol will include (b) as an option.
(4) PFS: Should the KINK protocol
(a) ignore PFS,
(b) wait for the Kerberos WG to add a PFS capability to Kerberos,
or
(c) use the IKE phase 2 PFS ?
Tero stated if we choose not to use IKE phase 2 PFS, we would need to disallow it in phase 2. Michael Thomas favors leveraging what the Kerberos WG does for PFS. Ken Raeburn: the Kerberos WG has just started to discuss PFS, KINK shouldn't wait for the Kerberos WG. Doug Engert: the Kerberos WG could take this up. Jonathan Trostle: Kerberos needs it anyway. The WG consensus here is that we should not ignore PFS, but also that we should take it from somewhere else as opposed to specifying it ourselves.
Michael Thomas: in favor of simplicity, MUST NOT do PFS. Bill Simpson: MAY's cause interoperability problems. Tero: decide if it is a MUST NOT. Michael Thomas: MUST NOT require PFS to be part of KINK. Brian Weis: PFS should be either a MUST or a MUST NOT. Tero: PFS only a MAY in IKE. No AD nput on this issue (Marcus Leech was present and we asked him). Further discussion of PFS in KINK will be on the WG email list. Matt Hur asked if the requirements document needs to be updated to reflect the WG consensus on PFS.
NEXT STEPS:
J. Trostle asked who was planning on implementing the KINK protocol. Seven people raised their hands; it is likely there will be multiple implementations of the KINK protocol. J. Trostle will come up with a new milestone list and dates. Tero and Michael Thomas will work together to create a draft of the KINK protocol that reflects the WG consensus on the questions above. We will target August or earlier for WG last call on the KINK protocol draft. There is an IPSEC interoperability bakeoff starting on August 13th in Helsinki, and it would be good to participate with the KINK protocol.