2.6.5 Kerberized Internet Negotiation of Keys (kink)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01


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:



Reach Consensus on requirements document



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 meeting, 1pm 2001/08/09, Blenham room

agenda bashing

protocol update (michael thomas)
draft status
changes done:
added status command (for QM notifications)
make use of QM explicit
clarified padding rules
hopefully the same as ISAKMP
added valid kerberos errors, plus a KINK internal error type
errors copied from RFC1510
perhaps need more guidance on error recovery
header rearranged a bit
reserve some bits for something mike can't remember
added PFS, security considerations
per consensus of last meeting
clarified U-U and Encryption wording
misc others (noted in the draft)
to do:
general editorial pass
Last Call soon?

implementation status

cisco implementation under way for past month
relatively few snags from draft
cross between FreeS/Wan Pluto (ISAKMP) and kerberos
-> named "goofy"
most MUST/SHOULD features implemented
General: Create/Delete/Status/GetTGT

still need optimistic keying and integration with pluto

quick mode sanity check:
- use quick mode payloads, but isn't quick mode per se.
- uses ID, SA, Nonce, and KE
- does not use HASH or ISAKMP header
- Nr (responder nonce) is optional
- use Quick Mode payload ordering.

- are KINK payloads registered as ISAKMP payloads?
- Diffie-Hellman group for PFS
put in KE payload?
Tero Kivinen:
IKE phase 2 PFS group is actually in the quick mode SA payload
- More errors?
- finer-grained

- Default service
jason thorpe suggests "kink/...@REALM"

sam hartman regarding host principal vs. service princ. points to kerberos FTP..

thor simon: host vs. service-specific:
tradeoff is: do you force the admin to put more stuff in the KDC database, or do you let compromise of one of the other services also comprimise KINK

apparent consensus: don't reuse host princ.

- Hash/Encryption and IPsec SKEYID uses service key using subkey might be more appropriate, but use of nonces make this roughly equivalent. seems to be OK with everyone to do our own key derivation based on service key and nonces..

Ack reliability (extended discussion)
[different from ISAKMP]

wording about optimistic create, pessimistic delete needed

wording about consequences of ACK being dropped..

SA creation: don't want to install outbound SA until the other side has inbound installed..

options: install SA after timeout anyway?

initiate back?

tero/sommerfeld: retransmit both msg 1 and msg 2

sommerfeld: both ends retransmitting leads to risk of sorceror's apprentice problem, but exchange is short..

extended discussion ensued regarding 2 vs. 3 msg exchanges for create..

no problem with 2-msg exchange for anything other than CREATE..

several alternatives discussed for CREATE..

- for CREATE, if short circuit, skip ack.
(short-circuit == responder picked first choice and did not add a nonce)
(no consensus for/against)

- for CREATE, w/o short circuit
(responder injects nonce or picks something other than the first proposal).
unanimous: always send ACK..

suggestions (no consensus):

always require server to supply nonce data?
tradeoff (always forces 3 message exchange, but avoids a config knob..)
add verbiage to the draft ("if you have a bad RNG on the initiator, a good RNG on the responder won't save you..")

2 message exchange as worthy goal?? (sense of WG: leaning towards yes, but not clear)

some discussion of acks vs dead peer detection and loss of synchronization..

some discussion of whether ack is actually necessary.. seems to be down to "nuke it" vs "need to think about it.."

need more verbiage in documents on when to install SA's.

open discussion?

nothing more..


KINK Status