KARP minutes: Start: 13:05 Welcome & Document Status (Chairs - 10 min) Slides note well agenda bashing minutes - Wes George jabber - Melinda Shore doc status - threats-reqs - substantial comments from IESG, authors reviewing, needs revision, group will need to re-review opsf-analysis - submitted to IESG, awaiting IETF LC tcp-analysis - passed WGLC, awaiting submission Acee Lindem (AL) - how close is keytable to last call? Chairs: we hope really, really close, pending discussions AL: timer on reviewing it? Milestones - we are behind, don't have WG Docs for several protocols (list in slides) Mahesh Jethanandani (MJ) - does RSVP-TE fall into existing docs so we can fold it in? There is a BFD auth doc in BFD WG , not sure if we need separate doc or mention Brian Weis (BW): does the doc use KARP design guide? No, so we need a seperate doc MJ: if you are looking for volunteers, I am willing to help Uma Chunduri (UC): ISIS doc - comments from Sam and other WG members, posted for WG adoption - wanted to know status BW: no other docs that do ISIS analysis, seems worth asking if that should be the WG doc, will take to list Anyone have an interest in LMP? - no one in room Next steps - looking for more volunteers for protocol docs Are all gaps met? additional analysis needed? - no comments in room Key mgmt analysis ongoing, majority of discussion today, gain consensus Core Documents Operations Model for Router Keying(Dacheng Zhang - 10 min) draft-ietf-karp-ops-model-03 updates since last version (see slides for details) no comments on this draft in room, not discussing next steps at this time Routing Protocol Analysis (No presentations requested) Key Management Database of Long-Lived Symmetric Cryptographic Keys(Dacheng Zhang - 20 min) draft-ietf-karp-crypto-key-table-03 Slides updates since last version (see slides for details) Steve Kent (SK): phrasing on slide 6 1st sub bullet is confusing - table has to have the way of determining which key is used for outgoing packet. That's not what it says - says "produce" outgoing packet - this is a filter spec, used to select row in key table. Only because I've done this a lot do I know that this really means - concerned that the doc will not be adequately informative. Dacheng agrees that this is the correct interpretation, will revise text to clarify. UC: all protocols need to look into the key table to secure packets, this is good. it's important to make distinction that this is inside of TCP-AO not the key tables SK: does the document explain what characteristics of TCP-AO as an example protocol require this break between what key table does and what protocol has to do for itself? Important this doc characterizes client/protocol requirements so that if you meet requirements, you have to do X. otherwise no way for reader to determine how much benefit using key table vs doing it yourself per protocol. Joel Halpern (JH): Wording in doc --- SK: I don't find that adequate - doesn't say why, only says if you need to do it, you need to do it Bill Manning (BM): may update tables as keys are added/removed -= triggers questions about volatility of the entries in the conceptual database - how do you signal a change and refresh?/ you don't How will it know to update its own table as keys are added/removed - not in document JH: point is that we wave at certain things and don't explain - we need to figure out how much explanation needs to be here, what needs to be in other documents, Anantha Ramaiah (AR): not sure where TCP-AO is coupled - more authentication material than MD5, but not sure I understand, not sure table and AO should be coupled Steve Bellovin (SB): last bullet on slide 8 - I agree w 1st sentence, but not clear that "all" setting is correct vs per peer Dacheng Zhang (DZ): in this case we don't care which interface the key will be used, we can say any or all - currently we specify all value in this field SB: agree you're not going to decide interface, but not necessarily use same keying material for all interfaces Russ Housley (RH), co-author: all in this case has to do with it applying to port, other field s in table that identify peer. Talking to that peer regardless of which interface SB: fine, but same keying material phrase is the problem MJ: database avoids need to build knowledge of security proto itself - does that include lifetime of the key itself? is that part of security proto? what about rollover? why? JH: current doc includes start/end times, send not before/after receive not before/after RH: responding to Bill - this doc should not address the issue you raised, they belong elsewhere. this is the database, not the access to the database, the kmp might implement to fill it. trying to create a common semantic for keys that are inserted manually and keys that are managed via automated kmp. things bill raises fall to automated kmp JH: thinking about Steve's and Bill's comments - is the desc on how TCP-AO interacts, is the answer to remove all of it? We have to do something better than what's here RH: point to make is if you're doing manual key management, how do you do TCP-AO BM: wasn't talking about database - question becomes how does a security proto that wants to update its tables know that new data is there or has been obsoleted. it has to show up somewhere if not in this doc RH: TCP-AO already tells you how to do key rollover BW: it has a mechanism, but not a trigger RH: but it has to do with dates - couldn't the table drive it SK: could seq rollover drive it? SK: my concern is not the same as Bill's - needs to provide enough guidance to those providing KMP interfacing with it UC: on the lifetime - full lifetime specified in this doc is not applicable to tcp-ao, not clear which field we need to use BW: why is this different from any other proto, we're talking about master key CH: which component send before/after, etc do you need to use? a single lifetime in seconds is the validator of the key BW: still talking about who decides when to switch keys Using IKEv2 with TCP-AO(Uma Chunduri - 15 min) draft-chunduri-karp-using-ikev2-with-tcp-ao-02 Slides updated based on prev mtg, esp comments from Tero discuss changes since last revision (see slides) requesting WG adoption JH: we'll come to adoption discussion later, other questions? no other questions or comments in room Simplified Authentication Method for KARP KMP(Uma Chunduri - 15 min) draft-chunduri-karp-kmp-router-fingerprints-00 Slides info draft, not creating anything new, is there a better way to do it that will simplify? SK: slide 5, you keep going back and forth between pkcs-1 and x.509 certs this is rsa-specific, not going to work when we are in an environment requiring algorithm agility - I'll pretend I'm a security AD UC: that's what Tero's draft covers SK: this may be ok because you're also saying use x.509 cert. that slide suggests you're having it issued by a CA, or is it self-signed UC: goal is not to use CA SK: ok don't put that on the slide, it's confusing. now on slide 8 - whole idea behind cert authorities is to minimize the amount of public info that has to be distributed in out of band secure fashion - this is going against the reason we created the tech in the first place. it's a big tradeoff you need to take into account UC: CA is to automate this SK: and to revoke it, so for any of these alternatives there is a way to deal with revocation, these others are not so standard ways to manage revocation - needs justification as to why this is better. is this an intra-AS distribution of info, which makes distribution of info easier, or inter-as. if inter-as, we have this infra in SIDR, why build another UC: if you don't have this method, you have to deploy PKI infra SK: which SIDR is providing UC: karp or kmp is getting the keys, pki infra SK: on an intra-as system lots of opportunities for distributing fingerprints that are acceptable secure. when you do it across AS boundaries, we have something that does this that you're saying "too hard" JH: if I can paraphrase - SIDR is already dealing with public keys and certs for routers. are you suggesting that those same keys and certs could be used for master security for TCP-ao to secure peer sessions? Randy Bush (RB): yes SK: close to it, I'd explain more, but let's go with Randy's more terse answer Tero Kivinen (TK) - slide 3 - the reason why we want to do this - most people are using shared secrets. next step is using PKI, but 4 different reasons why people aren't already doing it. Therefore they need something that isn't PKI. There's no problem with using PKI, it's there, but if they think that PKI is too hard for some reason, we may not be able to say why, that's why they want something between PKI and shared keys - better than shared keys, less overhead than PKI. You could share hashes using draft-farrell-decade-ni-09. UC: that summarizes well - we're not trying to reinvent PKI RB: make sure I understand - so using stuff in SIDR that is in deployment and RFCs is too hard? So we're going to reinvent? BW: We usually use fingerprints when there isn't a scaling problem, otherwise use of a PKI is more appropriate. UC: scaling/trust issue, PKI is the answer, this may be a solution when you don't have a scaling/trust issue BW: ops model I-D does discuss this briefly, review and see if more text needed. Automatic Key and Adjacency Management for Routing Protocols (Bill Atwood - 10 min) draft-atwood-karp-akam-rp-02 Slides as scope of key gets smaller, attack surface gets smaller green pucks are GCKS Robin Wilton (RW) : I endorse what you're doing. A nit about the framing of the problem. take your point about reduction of attack surface, but not sure that's what's going on. Attack surface is quantification of vulnerability. in a bounded system, segmenting keys may not reduce attack surface. it may reduce the impact of compromise Bill Atwood (BA): the work in this group makes assumptions about scope of keys and then build protocols based on that. We wanted to back off and see what the overall set of possibilities might be. would the choices made impact our ability to do things in the future, we think yes. JH: pending question about how we proceed on key management - resolution is on list, but want to frame and having discussion in room. will attempt not to mischaracterize everyone's work We have on unicast side 2 proposals based on IKEv2, significant differences, authors have talked, but still 2 proposals we have 2 proposals on multicast, most likely mergable instead - maybe well-served for one proposal for all, are we trying to build 1 or 2 solutions? open in charter so WG can address - didn't know the answer once we answer the question, what is the solution we want would like comments on the first question MJ: more specific on unicast key mgmt using IKEv2 - authors of 2 docs will meet after meeting to see if they can come up with a common solution JH: thanks! we have plan for one in each space, and a plan to combine them UC: we should try to use IKEv2, established proto, good operational experience - use for uni and multicast BW: we've discussed previously that if there's pairwise, we should use Diffie-Hellman to generate, still have to account for that RH: were you reporting a WG consensus call? If so, when was it made? BW: misrepresented, was saying just discussion RH: call on list please Session ends.... 2:25pm