2.6.5 Kerberized Internet Negotiation of Keys (kink)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-03-02


Derek Atkins <derek@ihtfp.com>
Jonathan Trostle <jtrostle@world.std.com>

Security Area Director(s):

Russell Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Sam Hartman <hartmans-ietf@mit.edu>

Mailing Lists:

General Discussion: ietf-kink@vpnc.org
To Subscribe: majordomo@vpnc.org
In Body: subscribe ietf-kink
Archive: http://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:

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
Mar 05  Review issues with kink-06
Mar 05  Submit kink-07
Jun 05  Reach consensus on necessary changes
Jul 05  Submit kink-08
Aug 05  WGLC
Sep 05  Submit draft to IESG
Jan 06  Begin Interop bakeoffs
Feb 06  Document interop results

No Current Internet-Drafts

Request For Comments:

RFC3129 I Requirements for Kerberized Internet Negotiation of Keys

Current Meeting Report

KINK Working Group
Friday, March 11, 2005

Co-Chairs: Derek Atkins and John Trostle

Minutes, edited from the jabber logs.

- Agenda Bashing

Nothing to add. We swapped some ordering due to time constraints.

- draft-ietf-kink-kink editorial status

The editor is not here.
We should have a document by next ietf.

- rfc1510 v krb-clarifications / kcrypto

Ken Raeburn, "kerberos and kink" summary of changes from 1510. quite a lot of changes, presenting ones relevant to kink. crypto split out into separate doc, treat as black box. fixed some bugs, cleaned up asn.1. compatibility with existing implementations rather than older spec. add ability to extend kerberos protocol in future. krb-error did not get checksum added as shown in some of the krb-revisions drafts. crypto rfc3961, black box crypto. simple operations/attributes. operations - how to generate keys from passphrase, random bits. req'd checksum for each cryptosystem. pseudorandom function based on encryption key; takes string of arb. bits, gives back random output string for key gen, other purposes. encryption/decryption have integrity checking built in (lit describes as authenticated encryption). treated as inseparable; newer auth encryption modes may make it difficult to separate them anyway. encryption not deterministic (all cryposystems use rand confounder). no assumption of fixed length output. decrypt w/verf; may have padding octets at end, so length may change on decryption (doesn't matter for krb due to asn.1 framing). checksum systems - MAC, not hash functions; fns to generate/verify. output not necessarily deterministic ... or fixed length.

question: what cksumtype have we defined already that's nondeterministic?

Jeff Hutzelman says md5-des, etc. are confounded i think

Sam Hartman: I believe some of the DES cksumtypes are nondeterministic [ verifies later that des-mac is non-deterministic ]

- 2401 v. 2401bis

Derek Atkins presents as Steve Kent could not attend.

Derek: steve couldn't be here today; he sent me a list. unfortunately he sent in email, so I cobbled together slides

Jeff H: are these slides available online?

Derek: download 2401bis; the list is in there.

Sam H: The slides are verbatim out of draft-ietf-ipsec-rfc2401bis

Derek: Processing model has been changed to address new scenarios. There is a new database - peer authorization database (PAD), which provides a link between IKE and SPD. The processing model based on decorrelation of the SPD; allows caching of SPD entries. If an implementation uses a decorrelated SPD, it should send the list of linked, decorrelated SPD entries via IKE v2 when negotiating an SA There is no longer a requirement to support nested SA's or "SA bundles"; instead this can be achieved through SPD and forwarding table configuration SPD entries were redefined to provide more flexibility. TOS (IPv4) and traffic class (IPv6) have been replaced by DSCP and ECN. The tunnel section has been updated to explain how to handle DSCP and ECN bits. DSCP values may be copied from a tunnel header to the inner header by a receiver, based on per-sa configuration controls. [10:26:35 AM] <jhutz> for tunnel mode SA's, an SG, BITS, or BITW implementation is now allowed to fragment before applying IPsec. This applies only to IPv4; for v6 only the originator may may fragment. 2401bis clarifies that for all traffic crossing the ipsec boundary (including ipsec management traffic), the SPD or associated caches must be consulted.

Sam H: the problem here is there are apparently a lot of impls that will take an incoming packet, find a key to decrypt it, and accept it, without bothering to check whether it's on the right SA

Mike Thomas: does that affect KINK?

Derek: 2401bis defines how to handle the situation of an SG with multiple subscribers requiring different IPsec contexts a definition of reserved SPIs has been added. text has been added explaining why ALL IP packets must be checked -- ipsec includes minimal firewall functionality to support access control at the IP layer

Mike T: It would be nice to get to the ones that might affect us

Derek: I know not all of these apply directly to KINK; steve didn't filter for me.

Sam H: Yes it would; this is not the most useful presentation. Steve Kent didn't have much time to prepare it.

Derek: The tunnel section has been updated to clarify how to handle the ip options field and Ipv6 extension headers when constructing the outer header. SA mapping for inbound traffic has been updated to be consistent with changes made in ah and esp for support of unicast, anycast, and multicast SAs. Guidance has been added wrt how to handle covert channel created in tunnel mode by copying the dscp value to outer header. Support for AH in IPv4 and IPv6 no longer required. PMTU handling has been updated. Appendix on PMTU/DF/fragmentation deleted. Added text saying "The IPSP WG is a possible future source of guidance. One of their goals is to produce an ID on a "Security Discovery, Policy Exchange, and Negotiation Protocol."

Sam H: we just closed IPSP

Derek: Three approaches have been added for handling plaintext fragments on the protected side of the ipsec boundary. Added revised text describing how to derive selector values for SAs (from the SPD entry or from the packet, etc). Added a new table describeing the relationship between selector values in an SPD entry, the PFP flag, and resulting selector values in the corresponding SAD entry. Added appendix B to describe decorrelation. Added text describing how to handle an outbound packet which must be discarded. Added text describing how to handle a discarded inbound packet (one that does not match SA on which it arrive). IPv6 mobility header has been added as a possible next-layer protocol. IPv6 mobility header message type has been added as a selector. ICMP message type, code have been added as selectors. Selector "data sensitiviy level" has been removed to simplify things. Updated text describing handling ICMP error messages. appendix on "categorization of ICMP messages" has been deleted. Text for the selector name has been updated and clarified. The "next layer protocol" has been further explained and a default list of protocols to skip when looking for NLP has been added. The text has been amended to say this doc assumes use of IKEv2 or an SA management protocol with comparable features. Text has been added clarifying the algorithm for mapping inbound IPsec datagrams to SAs in the presence of multicast SAs. The appendix "sequence space window code example" has been removed. WRT IP addres and ports, the terms "local" and "remote" are used for policy rules (repl. "source" and "destination"). "Local" refers to the entiy being protected by the ipsec impl; "remote" refers to a peer entity(s). The terms "source" and "destination" still used for packet header fields.

Any questions/comments?

Mike T: maybe have derek go through the list quickly and see if anybody believes it affects us. did any of them actually affect kink at all?

Tero Kivenin: Discusses the changes.

Jeff H: yeah, the part abouf "IKEv2 or an SA management protocol with comparable features" affects KINK none of the rest sounded to me like it was of much interest to kink

Mike T: Ask tero whether we can have a normative reference to ikev2's sa creation payloads like we did with ikev1 to pick up these features? So here's my take: we can either just live with 2401 SA right now, put capability for 2401 and 2401bis into this draft, or have a second rfc to update vor 2401bis features

Sam H: I expect 2401bis to clear the IESG "very soon"

Mike T: I sort of like the latter. We directly use ikv1 sa creation by normatively referencing it. Part of this is that I'm not sure about the upgrade strategy. So if we can normatively reference parts of ikev2 in a future draft, that would make it a lot easier. We really don't want two different ways to access 2401bis negotiation, I think.

[ People seem to agree ]

Sam H: Tero, do you think that would be OK?

Tero: <shakes head> [ meaning yes ]

- discussion of open issues

KAMADA Ken'ichi : KINK issue list update (see slides)

[ update on issue list; most issues were closed. only three issues remain open ]

Jeff H: do we think kink needs its own key usages, or can it use the app numbers?

Jeff H: so, can anyone think of a reason why the U2U case shouldn't be simplified by having the initiator send his TGT, and making the responder talk to the KDC?  I'm not sure, but it seems like that would save a full round trip. Of course, you still have the problem of telling when to use U2U.

Mike T: I don't think that works... if I remember correctly

Derek: as I recall it can be a DoS attack against the responder.

Jeff H: Hm. yeah, I suppose that could be argued. the question is whether it is worthwhile to save a round trip at the expense of having to deal with the potential DoS in some less-good way (like rate limiting SA creation)

Sam H: Having a network request that requires another service to do a network request is not desirable. I.E. if you are initiating something, you should have to go do the leg work of talking to the KDC.

Mike T: They may in fact be disjoint connectivitywise with the kdc's. Say the one kdc is behind a firewall...

Jeff H: if they don't both have connectivity to the KDC, how did the responder get its tickets? But sam's point is well-taken.

Sam H: U2U cross-realm is the interesting case

Mike T: I still don't understand 12 -- can ken talk about it?

Jeff H: Ken left, and I don't remember what 12 is (it's not on the srceen anymore)

Sam H: What is 12?

Derek: #12 [**] Subsession keys (section 5 and 8) Are subsession keys ignored? (Ken Raeburn)

Sam H: I can discuss 12 if you like.

Jeff H: I think discussing 12 is a good idea. Discussing u2u might also be a good idea, but I'm not sure if it can be solved today.

Jeff H: I'd like to touch on key usages. I'm fairly happy with the resolutions I saw to the other Kerberos-related issues the KRB-ERROR proposal annoys me, but we don't yet provide what you need and you may not want to wait for RFC1510ter to be published.

Sam H: You really do not want to wait for 1510ter

Mike T: right... I'm cool with nuking the krb-error keying

Jeff H: 1510ter is supposed to go to WGLC by august.. If that happens, I'd guess it would be published around this time next year. It could take longer...

Sam H: #12. field in ap-req for subsession keys in gssapi, key in tkt.. client proposes a key in its message. acceptor proposes a new key, using client key and session key. acceptors key is used.
- another option: diff keys in different directions
- another: not use subkey

Sam H: issue: session key could be long-lived

Mike T: but isn't the subkey as well?? it's in the same ticket

Derek: matatcisco: no, subkey is in AP-REQ

Jeff H: no. a subkey can be negotiated for each AP-REQ/AP-REP. So reusing the same kerberos ticket for another connectioin/session does not mean you have to reuse the same key.

Mike T: so our use of nonce is the moral equivalent of the subsession key.

Jeff H: It might be; I've not read that part of your doc in enough detail yet.

Sam H: propose same thing as gssapi.. client subkey overrides session key; server subkey overrides client subkey re nonce: no, it's not integrated into the crypto

Mike T: yes it does! it's used to generate the key!

Jeff H: Mike, can you give me a ref to the part of the document I should look at for this?

Mike T: if we're using kcrypto, does that imply use of the subsession key I don't know what that means!

Sam H: no.. subsession key is an optional field. "MUST not send. SHOULD ignore on receive". we should take to the list.

Mike T: my feeling is that if it ain't broken now, we shouldn't change it

Jeff H: No.  kcrypto has no effect on this question

Mike T: which issue are we on?
Derek: 37
Mike: thanks

Jeff H: at first glance, the key derivation described in section 8 looks like the use of the nonce is sufficient to make it not necessary to use subkeys.

Derek: good. that means our conclusion to #12 is okay.
Jeff: correct

Jeff H: we can use key usages, send mail to cliff to get them registered. we don't need to wait until 1510ter.

Mike: mic!

Jeff H: yes, I think your conclusion to #12 is ok

Sam H: I think we can close #37 if there is consensus on the new text for section 8

Derek: #37. Assume 37 is closed. Note that sam will have to read/review ike.

Jeff H: oh... one of the nonce's is non-optional, right?

Sam H: 4.3 wasn't enough detail for NULL/zero-length string.

Derek: okay. 37 closed.

Derek: Okay, #2. when do you use U2U? Pad? decide which principle to use? use PAD?

Mike T: pad? what is that?
Derek: PAD is a 2401bis concept

Sam H: KINK has principle of remote host in the PAD. Auth based on errors from kdc. other side must have way to say "use U2U this time"

I think KINK needs to know in advance what principal it's going to talk to, whether it is U2U or not. Obviously if it's not U2U, you have to know what service to request a ticket for. But even in the U2U case, you can't just trust the other guy's assertion of what principal you should auth to.

Three issues:
(1) what principal to use -- needs to be in PAD
(2) whether to use U2U -- PAD, or learning from remote side. you can use KDC errors for optimization, but can't depend on them.
(3) in cross-realm U2U, in what realm do you rendesvous?

Mike T: I don't think we violate the "depend" maxim

Jeff H: initiator gets ticket in target realm

Sam H: people believe it will work with the target's realm. if that's the case, it is clearly the right thing.

Mike T: that's how it was all explained to me by matt hur and sasha right... this was discussed in great depth a long time ago

Jeff H: this morning I read the expired -06 draft, since nothing newer was in the I-D repository. In that document, the intiator was supposed to send a TGT-REQ and do U2U if and only if it got an error from the KDC indicating it "can't get a service ticket" for the responder.

Mike T: me too :)
Mike T (to Jeff H): yep

Jeff H: The problem with that is the KDC can't always know that -- the issue is whether the responder knows its key/password, or only has tickets presumably you can't get a service ticket for a PKINIT-only client, but there can be other cases where you have to use U2U

Mike T: only work...

Jeff H: When the next version of the document is published, I'll look at it

Mike T: ok... it's going to take me a while to slog through it... I can honestly use some help on the kcrypto stuff...

Jeff H: raeburn's your man for kcrypto. but it's really pretty straightforward, or at least we hope it is.

Mike T: mostly it's my vague familiarity, and getting the wordsmithing correct yeah, I guess I can take a stab at it and send him the sections to see if they look right

Jeff H: probably not a bad idea


Kerberos and KINK
2401 v 2401bis
KINK issue list update