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 <email@example.com>
J Trostle <firstname.lastname@example.org>
Jeffrey Schiller <email@example.com>
Marcus Leech <firstname.lastname@example.org>
Marcus Leech <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: subscribe 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).
Reach Consensus on requirements document
Meet at San Diego IETF to review drafts
Reach Consensus on base draft protocol
Conduct WG last call on base draft prototol
Begin Interoperability bakeoffs
Document interoperability results. Make decision to recycle or move forward
KINK meeting, 1pm 2001/08/09, Blenham room
protocol update (michael thomas)
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)
general editorial pass
Last Call soon?
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
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?
IKE phase 2 PFS group is actually in the quick mode SA payload
- More errors?
- 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?
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.