IETF
karp@jabber.ietf.org
Tuesday, 31 July 2012< ^ >
Room Configuration

GMT+0
[15:12:20] leebingice joins the room
[17:59:56] leebingice leaves the room
[19:56:34] Melinda joins the room
[19:57:30] You-WebEx joins the room
[19:57:30] David Cooper joins the room
[19:59:08] <You-WebEx> I'm getting an http error when trying to start the audio, is anyone else having a problem?
[20:00:55] <You-WebEx> Got it working, so nevermind. ;-)
[20:04:22] revathi joins the room
[20:05:44] leebingice joins the room
[20:05:53] <Melinda> I'll be jabber scribing - if you've got questions/comments for the mike, let me know
[20:06:15] <Melinda> draft status
[20:06:31] <Melinda> threat requirements - revised draft needed
[20:06:56] <Melinda> ospf analysis - iesg review and ietf last call requested
[20:07:10] <Melinda> tcp analysis - through wg last call, waiting for shepherd writeup
[20:07:29] <Melinda> ops model and key table docs in progress
[20:07:41] <Melinda> how close is key table to last call?
[20:07:57] <Melinda> ans: we hope it's close, but until we've had the discussions we aren't sure
[20:08:37] <Melinda> behind in our milestones and there aer no drafts for rsvp-te, isis, bfd, or lmp
[20:08:47] Satoru Kanno joins the room
[20:09:38] <Melinda> ??? asked if looking for authors - answer is yes.
[20:09:46] <Melinda> do any fit into existing documents|? no.
[20:11:01] <Melinda> does anybody have an interest in lmp? none in the room, take it to list
[20:11:39] <Melinda> for existing protocols, are people comfortable that gaps have been addressed/closed?
[20:12:09] <Melinda> the majority of today will be spent on key management
[20:12:38] <Melinda> ops model for router keying
[20:14:01] <Melinda> what's been done since last meeting: removed discussion about limitations introduced by the kiy IDs in key table
[20:14:24] <Melinda> section 3.3 name changed to "interactions with automated key management
[20:14:38] <Melinda> (from "protocol limitations from the key table")
[20:15:11] <Melinda> added statement that each routing protocol is responsible for defining the form of peer specification used by that protocol
[20:15:25] <Melinda> comments on defining scope of keys
[20:16:14] <Melinda> added discussion of notification mechanism
[20:17:04] <Melinda> no comments from the floor
[20:17:09] <Melinda> key tables
[20:17:35] <Melinda> abstract updated to clarify that document describes the operations as well as the schema
[20:19:40] <Melinda> updates on database structures: localkeyid replaced by localkeyname; peerkeyid replaced by peerkeyname
[20:19:52] <Melinda> direction has new value: "disable"
[20:20:14] <Melinda> interface: field may consist of set of implementation-specific strings
[20:20:40] <Melinda> textual conventions for key names and keys
[20:21:54] <Melinda> application of the database in a security protocol
[20:23:57] <Melinda> steve kent: first bullet item is confusing, should say that there needs to be a way to determine key for a given outgoing packet
[20:24:25] <Melinda> agreement
[20:24:57] <Melinda> discussion related to tcp-ao
[20:28:48] Robin Wilton joins the room
[20:29:02] sujing joins the room
[20:30:02] <Melinda> discussion f whether or not text on the extent of the need for protocols which retain per-flow state to manage their own keys is sufficient
[20:33:00] leebingice leaves the room
[20:33:08] <Melinda> steve bellovin: using the same keying material across all peers seems incorrect russ housley: it's not the same key
[20:33:51] <Melinda> question about key lifetimes. document includes start times and end times
[20:36:48] <Melinda> discussion of protocols with per-flow state (tcp-ao) knowing how/when to manage their own keys
[20:37:26] <Melinda> when do you use this table, and when do you do something beyond it?
[20:38:40] wilton@jabber.isoc.org joins the room
[20:38:53] <Melinda> who decides when to switch keys?
[20:39:17] <Melinda> using ikev2 with tcp-ao (uma)
[20:39:54] <Melinda> what are the changes since last version?
[20:40:15] <Melinda> extended to capture gatekeeper interaction with pad, and crypto key tables
[20:40:43] leebingice joins the room
[20:40:50] <Melinda> added stuff on other security databases not relevant to karp, and a few other minor modifications
[20:41:45] <Melinda> need text on glue logic
[20:43:20] <Melinda> gatekeeper interaction with pad
[20:45:23] <Melinda> gatekeeper interaction with crypto key tables
[20:46:31] <Melinda> message flow diagram (slide 6)
[20:48:21] <Melinda> Uma would like the draft to be adopted by the working group. We'll come back to it
[20:48:25] <Melinda> any questions for the mike?
[20:49:11] <Melinda> simplification of operations when deployed - uma
[20:50:17] <Melinda> motivations: minimize use of password-based authentcation, move from manual keys to kmp
[20:53:01] <Melinda> simplified peer authentication using router fingerprints
[20:55:42] <Melinda> how to publish router fingerprints?
[20:55:45] <Melinda> use slas
[20:55:48] <Melinda> should be part of pad
[20:56:03] <Melinda> net to resort to out-of-band public key validation procedures
[20:56:05] <Melinda> pgp word lists
[20:56:58] <Melinda> steve kent: pkcs#1 is rsa-specific, and we place a premium to algorithm agility
[20:57:41] <Melinda> if you're using x.509, will they be issued by CA or self-signed
[20:57:50] <Melinda> uma: goal is to not use ca
[20:58:35] <Melinda> steve: we want to minimize stuff haded around out-of-band, so there's a big tradeoff here that should be taken into account
[20:58:56] <Melinda> steve: ... and to have a way of revoking it
[21:01:14] <Melinda> steve: the inter-as and intra-as answers might be different. if you're doing this intra-as, there would be lots of ways to distribute fingerprints that would be acceptably secure. across as boundaries, we have rpki
[21:03:03] <Melinda> tero: currently most people are using passwords, next step is using pki, which people are not always willing to use
[21:06:42] <Melinda> susummary, looking for feedback and collaboration
[21:07:04] <sujing> mic: Identity based cryptography considered?
[21:07:41] <Melinda> atwood: key management and adjacency management for karp-based routing systems
[21:08:35] wilton@jabber.isoc.org leaves the room
[21:08:42] <Melinda> as the scope of the key gets smaller so does the attack surface
[21:16:02] <Melinda> discussion of group keying
[21:17:03] <Melinda> more detailed info on gdoi for scoping adjacencies
[21:20:21] <revathi> Hi Melinda, could you please let us know the question.. It was not audible
[21:21:38] <Melinda> Robin commented that increasing the granularity of the key scope (well, reducing the key scope) doesn't reduce the total attack surface but that it decreases the impact of a compromise of a given key
[21:22:40] <revathi> oh ok.. thank you..
[21:23:29] <Melinda> mahesh: the authors of two documents on ikev2 have agreed to meet
[21:24:26] <Melinda> brian: rather than fitting a group key management to everything, use pairwise dh where possible
[21:24:43] Robin Wilton leaves the room: Replaced by new connection
[21:24:44] Robin Wilton joins the room
[21:25:03] <Melinda> russ asked for consensus call on mailing list
[21:25:47] Melinda leaves the room: Computer went to sleep
[21:26:16] David Cooper leaves the room
[21:26:33] You-WebEx leaves the room
[21:27:14] Robin Wilton leaves the room
[21:32:59] revathi leaves the room
[21:33:11] sujing leaves the room
[21:34:41] Satoru Kanno leaves the room
[21:34:53] leebingice leaves the room
[22:25:43] Robin Wilton joins the room
[22:51:16] Robin Wilton leaves the room