Subject: Minneapolis KINK WG minutes

From: Jonathan Trostle <[email-masked]>
Date: Thu, 05 Apr 2001 22:43:03 -0700

Please send any additions or corrections in the next few days.

Jonathan

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
input 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.