[08:09:57] --- matatcisco has joined
[08:46:28] --- warlord has joined
[09:01:08] --- Melinda has joined
[09:01:28] --- tlyu has joined
[09:01:36] --- hartmans has joined
[09:01:48] --- nov has joined
[09:02:16] <hartmans> Mike, do you have audio?
[09:02:20] <tlyu> warlord: should have document by next ietf
[09:03:10] --- jhutz has joined
[09:03:14] <tlyu> ken raeburn "kerberos and kink"
[09:03:35] <tlyu> [mike futzing]
[09:03:55] <tlyu> ken: summary of changes from 1510
[09:04:16] <tlyu> ken: quite a lot of changes, presenting ones relevant to kink
[09:04:28] <tlyu> ken: crypto split out into separate doc, treat as black box
[09:04:37] <tlyu> ken: fixed some bugs, cleaned up asn.1
[09:04:55] <matatcisco> I'm here (hear) now
[09:04:56] <tlyu> ken: compatibility with existing implementations rather than older spec
[09:05:16] <tlyu> ken: add ability to extend kerberos protocol in future
[09:05:30] <tlyu> ken: krb-error did not get checksum added as shown in some of the krb-revisions drafts
[09:06:00] <tlyu> ken: crypto rfc3961, black box crypto
[09:06:14] <tlyu> ken: simple operations/attributes
[09:06:47] <tlyu> ken: operations - how to generate keys from passphrase, random bits
[09:07:01] <tlyu> ken: req'd checksum for each cryptosystem
[09:07:44] <tlyu> ken: pseudorandom function based on encryption key; takes string of arb. bits, gives back random output string for key gen, other purposes
[09:08:07] <tlyu> ken: encryption/decryption have integrity checking built in (lit describes as authenticated encryption)
[09:08:36] <tlyu> ken: treated as inseparable; newer auth encryption modes may make it difficult to separate them anyway
[09:08:56] <tlyu> ken: encryption not deterministic (all cryposystems use rand confounder)
[09:09:04] <tlyu> ken: no assumption of fixed length output
[09:09:46] <tlyu> ken: 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)
[09:10:25] <tlyu> checksum systems - MAC, not hash functions; fns to generate/vfy
[09:10:42] <tlyu> output not necessarily deterministic
[09:10:51] <tlyu> ...or fixed length
[09:10:52] <jhutz> what cksumtype have we defined already that's nondeterministic?
[09:11:12] <tlyu> jhutz, md5-des, etc. are confounded i think
[09:11:45] <jhutz> next: 2401 vs 2401bis, Derek Atkins and Steve Kent
[09:11:56] <jhutz> warlord: steve couldn't be here today; he sent me a list
[09:12:09] <jhutz> warlord: unfortunately he sent in email, so I cobbled together slides
[09:12:16] <hartmans> I believe some of the DES cksumtypes are nondeterministic
[09:12:36] <jhutz> jhutz: are these slides available online?
[09:12:36] --- raeburn has joined
[09:12:44] <jhutz> warlord: download 2401bis; the list is in there.
[09:13:18] <hartmans> The slides are verbatim out of draft-ietf-ipsec-rfc2401bis
[09:13:31] <jhutz> warlord: processing model has been changd to address new scenarios
[09:13:45] <jhutz> warlord: there is a new database - peer authorization database (PAD), which
[09:13:56] <jhutz> provides a link between XXX and XXX [slide gone too fast]
[09:14:09] <raeburn> between IKE and SPD, I think
[09:14:10] <jhutz> the processing model based on decorrelation of the SPD; allows caching of SPD entries
[09:15:20] <jhutz> if an implementation uses a decorrelated SPD, it should send the list of linked, decorrelated SPD entries via IKE v2 when negotiating an SA
[09:15:45] <hartmans> Yeah, des-mac is non-deterministic
[09:15:54] --- Jeffrey Altman has joined
[09:16:00] <jhutz> 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
[09:16:00] <raeburn> anyone in jabber who's not in the meeting room? (anyone listening to audio?)
[09:16:13] <hartmans> mat is not here
[09:16:52] <jhutz> spd entries were redefined to provide more flexibility [not typing details into jabber]
[09:17:13] <matatcisco> yes I am
[09:17:15] <jhutz> > mat is not here he's not "matatcisco" ?
[09:18:14] <matatcisco> it's ok on audio feed
[09:18:31] <raeburn> good. sorry, we lost audio for a minute...
[09:18:36] <jhutz> 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
[09:18:45] <jhutz> [actually, I just tripped]
[09:18:52] <hartmans> By not here i meant in the room
[09:19:00] <matatcisco> no, I'm in SF
[09:19:03] <jhutz> DSCP values may be copied from a tunnel header to the inner header by a receiver, based on per-sa configuration controls
[09:19:22] <jhutz> for tunnel mode SA's, an SG, BITS, or BITW implementation is now allowed to fragment before applying IPsec.
[09:19:34] <jhutz> This applies only to IPv4; for v6 only the originator may may fragment
[09:19:58] <jhutz> 2401bis clarifices that for all traffic crossing the ipsec boundary (including ipsec management traffic), the SPD or associated caches must be consulted
[09:20:48] <jhutz> hartmans: 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
[09:20:53] <matatcisco> does that affect KINK?
[09:21:14] <jhutz> warlord/slide: 2401bis defines how to handle the situation of an SG with multiple subscribers requiring different IPsec contexts
[09:21:25] <jhutz> a definition of reserved SPIs has been added.
[09:21:51] <jhutz> 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
[09:22:00] <matatcisco> it would be nice to get to the ones that might affect us
[09:22:07] <jhutz> warlord: I know not all of these apply directly to KINK; steve didn't filter for me
[09:22:23] <hartmans> Yes it would; this is not the most useful presentation. Steve Kent didn't have much time to prepare it.
[09:22:29] <jhutz> slide: the tunnel section has been updated to clarify how to handle the ip options field and ipv6 extension headers when constructing the outer header
[09:22:54] <jhutz> 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
[09:23:01] <matatcisco> maybe have derik cdr through the list quickly and see if anybody believes it affects us.
[09:23:15] <jhutz> guidance has been added wrt how to handle covert channel created in tunnel mode by copying the dscp value to outer header
[09:23:22] <jhutz> support for AH in IPv4 and IPv6 no longer required
[09:23:26] <jhutz> PMTU handling has been updated.
[09:23:30] --- blilly has joined
[09:23:31] --- blilly has left: Disconnected
[09:23:34] <jhutz> appendix on PMTU/DF/fragmentation deleted
[09:24:18] <jhutz> 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.""
[09:24:38] <jhutz> hartmans: we just closed IPSP
[09:24:57] <jhutz> slide: three approaches have been added for handling plaintext fragments on the protected side of the ipsec boundary.
[09:25:15] <jhutz> added revised text describing how to derive selector values for SAs (from the SPD entry or from the packet, etc)
[09:25:34] <jhutz> 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
[09:25:40] <jhutz> added appendix B to describe decorrelation
[09:25:50] <jhutz> added text describing how to handle an outbound packet which must be discarded
[09:26:15] <jhutz> added text describing how to handle a discarded inbound packet (one that does not match SA on which it arrive)
[09:26:37] <jhutz> IPv6 mobility header has been added as a possible next-layer protocol. IPv6 mobility header message type has been added as a selector
[09:26:46] <jhutz> ICMP message type, code have been added as selectors
[09:26:57] <jhutz> selector "data sensitiviy level" has been removed to simplify things
[09:27:15] <jhutz> updated text describing handling ICMP error messages. appendix on "categorization of ICMP messages" has been deleted
[09:27:25] <jhutz> text for the selector name has been updated and clarified
[09:27:46] <jhutz> the "next layer protocol" has been further explained and a default list of protocols to skip when looking for NLP has been added
[09:28:01] <jhutz> the text has been amended to say this doc assumes use of IKEv2 or an SA management protocol with comparable features
[09:28:19] <jhutz> text has been added clarifying the algorithm for mapping inbound IPsec datagrams to SAs in the presence of multicast ASAs
[09:28:29] <jhutz> the appendix "sequence space window code example" has been removed
[09:28:36] <jhutz> s/ASAs/SAs/
[09:28:55] <jhutz> WRT IP addres and ports, the terms "local" and "remote" are used for policy rules (repl. "source" and "destination")
[09:29:21] <jhutz> "local" refers to the entiy being protected by the ipsec impl; "remote" refers to a peer entity(s)
[09:29:34] <jhutz> the terms "source" and "destination" still used for packet header fields
[09:29:39] <jhutz> <whew>
[09:29:45] <jhutz> warlord: any questions/comments?
[09:30:31] <matatcisco> did any of them actually affect kink at all?
[09:30:52] <jhutz> someone take over; I can't understand tero
[09:31:15] <jhutz> mat: yeah, the part abouf "IKEv2 or an SA management protocol with comparable features" affects KINK
[09:31:52] <jhutz> none of the rest sounded to me like it was of much interest to kink
[09:32:16] <matatcisco> ask tero whether we can have a normative reference to ikev2's sa creation
[09:32:24] <matatcisco> payloads like we did with ikev1
[09:32:40] <matatcisco> no, I don't think so
[09:33:23] <matatcisco> to pick up these features?
[09:33:47] --- tanupoo has joined
[09:35:55] <warlord> matatcisco: are you listening to the audio?
[09:35:59] <matatcisco> yes
[09:37:15] <matatcisco> 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
[09:37:23] --- raeburn has left: Disconnected
[09:38:30] <warlord> hartmans expects 2401bis to clear the IESG "very soon"
[09:39:00] <matatcisco> for
[09:39:19] <matatcisco> I sort of like the latter
[09:40:04] <matatcisco> we directly use ikv1 sa creation by normatively referencing it
[09:40:32] <matatcisco> part of this is that I'm not sure about the upgrade strategy
[09:41:12] <matatcisco> so if we can normatively reference parts of ikev2
[09:41:27] <matatcisco> in a future draft, that would make it a lot easier
[09:41:39] --- kivinen has joined
[09:41:59] <matatcisco> we really don't want two different ways to access 2401bis negotiation, I think
[09:42:22] <matatcisco> [tel] go-ahead
[09:42:45] <matatcisco> mic
[09:43:08] <warlord> okay
[09:43:16] <matatcisco> so the punt went through the goalpost?
[09:43:18] <jhutz> hartmans: tero, do you think that would be OK?
[09:43:23] <warlord> yes
[09:43:26] <jhutz> tero: <shakes head>
[09:43:38] <matatcisco> groovy
[09:43:40] <jhutz> ??: so, does that mean yes?
[09:43:48] <jhutz> tero: <shakes head again>
[09:44:55] <jhutz> (audio level OK?)
[09:44:58] <matatcisco> yes
[09:44:59] --- masahiro has joined
[09:45:01] <warlord> tero: does "shakes head" mean "yes" or "no"?
[09:45:40] <jhutz> (the current speaker sounds really quiet to me; I can turn up the gain on him a bit if it will help)
[09:45:53] <matatcisco> he's coming in fine for me
[09:46:38] <jhutz> do we think kink needs its own key usages, or can it use the app numbers?
[09:46:43] <jhutz> OK
[09:47:09] <jhutz> you don't have a noisy projector next to you, I bet :-)
[09:47:15] <matatcisco> nope :)
[09:50:10] <jhutz> 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.
[09:50:46] <jhutz> Of course, you still have the problem of telling when to use U2U
[09:50:55] <matatcisco> I don't think that works... if I remember correctly
[09:50:55] <warlord> jhutz: as I recall it can be a DoS attack against the responder.
[09:53:02] <matatcisco> I still don't understand 12 -- and ken talk about it?
[09:53:07] <matatcisco> can
[09:53:14] <jhutz> 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)
[09:53:23] <hartmans> Having a network request that requires another service to do a network request is not desirable.
[09:53:37] <jhutz> ken left, and I don't remember what 12 is (it's not on the srceen anymore)
[09:53:41] <hartmans> I.E. if you are initiating something, you should have to go do the leg work of talking to the KDC
[09:53:56] <matatcisco> they may in fact be disjoint connectivitywise with the kdc's
[09:54:14] <matatcisco> say the one kdc is behind a firewall...
[09:54:39] <jhutz> if they don't both have connectivity to the KDC, how did the responder get its tickets?
[09:54:52] <jhutz> but sam's point is well-taken
[09:54:53] <hartmans> u2u cross-realm is the interesting case
[09:54:59] <hartmans> What is 12?
[09:55:04] <warlord> #12 [**] Subsession keys (section 5 and 8)
[09:55:12] <warlord> Are subsession keys ignored? (Ken Raeburn)
[09:55:15] <jhutz> ah
[09:55:19] <hartmans> I can discuss 12 if you like.
[09:55:36] <matatcisco> are we just blowing through these and discuss later?
[09:55:43] <warlord> matatcisco: yes
[09:55:45] <jhutz> apparently.
[09:56:21] <hartmans> If you want to do something else we could try
[09:57:12] <jhutz> I think discussing 12 is a good idea. Discussion u2u might also be a good idea, but I'm not sure if it can be solved today.
[09:57:21] <jhutz> I'd like to touch on key usages.
[09:57:36] <jhutz> I'm fairly happy with the resolutions I saw to the other Kerberos-related issues
[09:58:25] <jhutz> 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.
[09:58:51] <hartmans> You really do not want to wait for 1510ter
[09:59:12] <matatcisco> right... I'm cool with nuking the krb-error keying
[09:59:28] <jhutz> 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...
[10:00:16] <warlord> sam: #12. field in ap-req for subsession keys
[10:00:28] <warlord> in gssapi, key in tkt..
[10:00:55] <warlord> client proposes a key in its message. acceptor proposes a new key, using client key and session key. acceptors key is used.
[10:01:09] <warlord> another option: diff keys in different directions
[10:01:12] <warlord> another: not use subkey
[10:01:19] <matatcisco> but isn't the subkey as well??
[10:01:24] <warlord> issue: session key coul dbe long-lived
[10:01:24] <matatcisco> it's in the same ticket
[10:01:36] <warlord> matatcisco: no, subkey is in AP-REQ
[10:01:39] <jhutz> no. a subkey can be negotiated for each AP-REQ/AP-REP
[10:01:54] <matatcisco> so our use of nonce is the moral equivalent
[10:02:02] <jhutz> So reusing the same kerberos ticket for another connectioin/session does not mean you have to reuse the same key
[10:02:38] <jhutz> It might be; I've not read that part of your doc in enough detail yet.
[10:02:50] --- kazunori has joined
[10:02:56] <warlord> sam: propose same thing as gssapi.. client subkey overrides session key; server subkey overrides client subkey
[10:03:50] <matatcisco> of the subsession key
[10:03:56] <matatcisco> yes it does!
[10:03:57] <warlord> nonce: no, it's not integrated into the crypto
[10:04:13] <matatcisco> it's used to generate the key!
[10:04:27] <jhutz> mat, can you give me a ref to the part of the document I should look at for this?
[10:05:17] <matatcisco> if we're using kcrypto, does that imply use of the subsession key
[10:05:26] <matatcisco> I don't know what that means!
[10:05:53] <warlord> no.. subsession key is an optional field.
[10:06:09] <warlord> "MUST not send. SHOULD ignore on receive"
[10:06:17] <warlord> we should take to the list.
[10:06:17] <matatcisco> my feeling is that if it ain't broken now, we shouldn't change it
[10:07:04] <jhutz> No. kcrypto has no effect on this question
[10:08:15] <matatcisco> which issue are we on?
[10:08:23] <warlord> 37
[10:08:24] <matatcisco> thx
[10:08:40] <jhutz> 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.
[10:09:10] --- hartmans has left: Disconnected
[10:09:39] <warlord> good. that means our conclusion to #12 is okay.
[10:11:12] <warlord> jhutz: we can use key usages, send mail to cliff to get them registered. we don't need to wait until 1510ter.
[10:13:04] <jhutz> correct
[10:13:19] <matatcisco> mic!
[10:13:25] <jhutz> yes, I think your conclusion to #12 is ok
[10:14:04] <jhutz> hartmans: I think we can close #37 if there is consensus on the new text for section 8
[10:14:06] <warlord> #37. Assume 37 is closed. Note that sam will have to read/review ike.
[10:14:41] <jhutz> oh... one of the nonce's is non-optional, right?
[10:14:45] <warlord> concern: 4.3 wasn't enough detail for NULL/zero-length string.
[10:15:01] <matatcisco> kewl
[10:15:16] <warlord> okay. 37 closed.
[10:15:32] <matatcisco> respect my trip :)
[10:15:36] <warlord> Okay, #2
[10:16:22] <warlord> when do you use U2U? Pad?
[10:16:44] <warlord> decide which principle to use? use PAD?
[10:16:52] <matatcisco> pad? what is that?
[10:17:01] <warlord> KINK has principle of remote host in the PAD
[10:17:09] <warlord> PAD is a 2401bis concept
[10:17:11] --- nov has left: Lost connection
[10:17:12] --- Melinda has left: Lost connection
[10:17:12] --- Jeffrey Altman has left: Lost connection
[10:17:12] --- kazunori has left: Lost connection
[10:17:12] --- kivinen has left: Lost connection
[10:17:12] --- tanupoo has left: Lost connection
[10:17:12] --- masahiro has left: Lost connection
[10:17:13] <jhutz> warlord, are you asserting or quoting sam?
[10:17:25] <warlord> sorry, i'm quoting sam
[10:17:58] <warlord> [sam] auth based on errors from kdc.
[10:18:09] <warlord> [sam] other side must have way to say "use U2U this time"
[10:18:16] <jhutz> 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.
[10:18:32] <jhutz> Three issues:
[10:18:39] <jhutz> (1) what principal to use -- needs to be in PAD
[10:18:50] <jhutz> (2) whether to use U2U -- PAD, or learning from remote side.
[10:18:58] <jhutz> you can use KDC errors for optimization, but can't depend on them.
[10:19:04] <matatcisco> I don't think we violate the "depend" maxim
[10:19:20] <jhutz> (3) in cross-realm U2U, in what realm do you rendesvous?
[10:20:17] --- kivinen has joined
[10:20:53] --- masahiro has joined
[10:20:54] <warlord> [jhutz] initiator gets ticket in target realm
[10:21:20] --- masahiro has left: Logged out
[10:21:56] --- nov has joined
[10:22:09] <warlord> [sam] people believe it will work with the target's realm.
[10:22:18] <warlord> [sam] if that's the case, it is clearly the right thing
[10:22:23] <matatcisco> that's how it was all explained to me by matt hur and sasha
[10:23:14] <matatcisco> right... this was discussed in great depth a long time ago
[10:23:29] <jhutz> 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.
[10:23:40] <matatcisco> me too :)
[10:24:14] <matatcisco> yep
[10:24:19] <jhutz> 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
[10:24:47] <jhutz> 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
[10:24:54] <matatcisco> only work...
[10:25:10] <jhutz> When the next version of the document is published, I'll look at it
[10:25:33] <matatcisco> ok... it's going to take me a while to slog through it... I can honestly use some help on the kcrypto stuff...
[10:25:58] <jhutz> raeburn's your man for kcrypto. but it's really pretty straightforward, or at least we hope it is.
[10:26:18] <matatcisco> mostly it's my vague familiarity, and getting the wordsmithing correct
[10:26:42] <matatcisco> yeah, I guess I can take a stab at it and send him the sections
[10:26:48] <matatcisco> to see if they look right
[10:27:15] <jhutz> probably not a bad idea
[10:27:37] --- tlyu has left: Logged out
[10:28:47] --- kivinen has left: Lost connection
[10:28:47] --- nov has left: Lost connection
[10:29:11] --- jhutz has left: Disconnected
[10:30:00] --- matatcisco has left
[10:33:54] --- Melinda has joined
[10:34:49] --- warlord has left
[10:35:03] --- Melinda has left
[10:46:57] --- wej has joined
[10:54:49] --- nov has joined
[11:04:16] --- nov has left: Disconnected
[11:07:27] --- tlyu has joined
[11:07:34] --- tlyu has left
[12:27:59] --- wej has left: Logged out
[21:17:45] --- Jeffrey Altman has joined