[00:55:18] tlyu joins the room
[00:55:24] <lukeh> morning
[00:55:33] <tlyu> hi
[00:56:01] semery joins the room
[00:57:25] Melinda joins the room
[01:01:38] spturner joins the room
[01:01:47] <spturner> how's the audio?
[01:01:51] <lukeh> fine
[01:01:54] <spturner> great
[01:01:57] <lukeh> I can tell it's Leif
[01:02:03] <spturner> it sure is
[01:02:04] <tlyu> sounds ok, a little clipping
[01:02:12] <lukeh> yes, Tom has a point
[01:02:16] scottcantor joins the room
[01:02:16] <lukeh> but I can understand it :)
[01:02:17] <tlyu> not nearly as bad as some other sessions i've heard this week though
[01:02:19] stpeter joins the room
[01:02:41] <spturner> it goes to 11
[01:02:48] <lukeh> hehe
[01:02:48] yoiwa joins the room
[01:03:50] hartmans@mit.edu/barnowl joins the room
[01:04:10] stpeter has set the subject to: ABFAB WG | http://tools.ietf.org/wg/abfab/
[01:06:22] <tlyu> if the long drop-down list doesn't crash your browser...
[01:07:12] <hartmans@mit.edu/barnowl> So, we didn't end up with webex?
[01:07:33] <scottcantor> I found the page, but I'm listening to the stream at the moment
[01:07:50] <tlyu> i'm on the mp3 stream
[01:09:41] <Melinda> I'm also on the audio stream
[01:09:59] stpeter leaves the room: Logged out
[01:19:05] sftcd joins the room
[01:19:16] Klaas Wierenga joins the room
[01:19:32] buckeyeskeeve joins the room
[01:20:55] hartmans@mit.edu/barnowl leaves the room
[01:21:59] scottcantor leaves the room
[01:24:57] =JeffH joins the room
[01:29:28] hartmans@mit.edu/barnowl joins the room
[01:31:04] <=JeffH> draft-lear-abfab-architecture-00.txt being discussed
[01:31:11] <=JeffH> Steve Farrell at mic
[01:31:54] <=JeffH> ques: are you going to eval priv properties of all the EAP mechs ?
[01:33:26] <=JeffH> ans: IAB has written on priv at high level recently; in terms of EAP mechs, user confidentiality is an aspect here (eg one can't tell its me auth'g); .....
[01:34:06] LZHULAPTOP joins the room
[01:34:12] <=JeffH> Leif: its in our charter that techs we develop need to have "sufficient" priv properties, but not every spec needs to have a priv considerations section
[01:34:34] <=JeffH> steve; if there's not this info for eap methods, then how can u meet that charter goal?
[01:35:09] <=JeffH> HT: IAB doc, while still at early state, they can help us to write the stuff we need to....
[01:35:49] <=JeffH> leif: summarizing: point is we need to have "sufficient priv controls" and eval that
[01:36:10] <=JeffH> sam: we can say "these are methods we've eval'd and they have foo priv properties...."
[01:37:29] <=JeffH> we can look at a couple EAP methods and assess them; Identity hiding is one prop of some eap methods, and so those ones address this for us; but if there's other priv properties we need we need to eval eap methods we want to use in light of this
[01:37:43] <=JeffH> leif: Sam -- can you write up that question for list?
[01:38:10] <=JeffH> sam: am not sure this particular suggestion warrants being called out separately from other priv issues
[01:38:13] <=JeffH> ? at mic
[01:39:47] <=JeffH> good to have priv concerns; there's a trend to work towards priv-by-design; so if rolled into arch design process, have this; there's sugg to handle priv in way similar to how we try to address sec when designing protocols, which would be a good thing; 
[01:40:24] <=JeffH> leif: your sugg/observation is good of course; this is in scope in WG cuz stipulation was made at BoF; 
[01:40:44] <=JeffH> [hannes continues with preso]
[01:42:29] <=JeffH> sam presenting on draft-ietf-abfab-gss-eap
[01:43:07] <=JeffH> title slide
[01:43:12] <=JeffH> slide 1 current status
[01:46:17] <=JeffH> slide 2: missing details to fill in
[01:46:48] <=JeffH> <actually denoted as slide 3 cuz title slide apparnetly was #1>
[01:47:51] <=JeffH> slide 4: missing parts discovered
[01:48:50] <lukeh> Netnews? :)
[01:49:03] <tlyu> yeah some of us still use it
[01:49:18] <=JeffH> slide 5: oid and mech naming
[01:50:13] <Klaas Wierenga> netnews is where i get my nba games
[01:51:16] <tlyu> i need to look at NegoEx (for krb-wg) because it's supposedly necessary for PKU2U
[01:51:32] joseph.yee joins the room
[01:51:50] <=JeffH> lzhu @ mic
[01:52:02] <=JeffH> [ missed his comment... ]
[01:52:24] <=JeffH> wrt negoex -- sam will work with Leif on it
[01:53:23] <=JeffH> show of hands to see if registry of names is useful --- mech name, oid, sasl name, guid
[01:53:47] <=JeffH> 3d col has "foreign key" to SASL reg 
[01:54:14] <=JeffH> do folks feel this is good idea?  (alexey thinks so....)
[01:54:50] <=JeffH> lzhu @mic:  one can always put this together oneself, other than guids these are reg'd
[01:55:21] <=JeffH> sam: iana has only some oids reg'd; this shud be First come first served
[01:55:31] <tlyu> OIDs are hierarchically managed
[01:56:07] <lukeh> maybe also JANET have an OID but ... no better/worse than PADL
[01:56:34] <=JeffH> what OID arc to ujse?
[01:56:54] <=JeffH> issue is "at what point do we get OID?" -- don't want to wait too long
[01:57:22] <=JeffH> lzhu:  why doesn't gssapi use guids?
[01:57:31] <lukeh> !
[01:57:43] <=JeffH> sam: gssapi uses OIDs per specification
[01:58:00] <lukeh> well, last components
[01:58:12] <=JeffH> Alexey doesn't really care where OID comes from
[01:58:32] <=JeffH> AI: Leif/Klaas/Sam to figger out OID thing sooner rather than later....
[01:58:34] <spturner> Nor does Sean ;)
[01:58:42] <=JeffH> slide 6: gss channel binding
[01:58:52] <spturner> I've seen some people wait to get an OID and others get one early
[01:58:58] stpeter joins the room
[01:59:16] hardjono@mit.edu joins the room
[02:00:47] <tlyu> IANA has the security mechanism OID arc under SMI
[02:01:42] <=JeffH> lzhu: require channel manager to impl ?  CBs are optional yes?
[02:01:57] <=JeffH> require CB to be impl'd i guess
[02:02:06] <=JeffH> leif: require non-empty CBs ?
[02:02:10] <lukeh> currently in my mech_eap implementation, CBT - whilst encapsulated in an extension token - is mandatory to implement
[02:02:18] <lukeh> as in, it's a critical extension token
[02:02:20] <=JeffH> lzhu: CBs are optional yes?
[02:02:22] <lukeh> but it is optional to a user
[02:02:27] <lukeh> as Sam says.
[02:02:42] <=JeffH> sam; yes, a particular app doesn't have to use CBs
[02:02:45] <spturner> http://www.iana.org/assignments/smi-numbers ?
[02:03:01] <lukeh> I agree with Sam - dealing with channel binding interop in SASL GS2 is horrendous
[02:03:02] <=JeffH> lzhu: complexity with CBs
[02:03:08] <tlyu> spturner: yes
[02:03:21] <=JeffH> sam: yes, have that complexity. GSSv2 (?) has facilities to help with that
[02:03:27] <buckeyeskeeve> GS2
[02:03:28] <lukeh> jeff: SASL GS2
[02:03:43] <=JeffH> igor f:  ?
[02:04:16] <stpeter> Igor Faynberg
[02:04:28] <=JeffH> sam: GSS has wrap token that is sign & encrypt
[02:04:31] <=JeffH> igor: thx
[02:04:40] <=JeffH> [ thx for help :) ]
[02:04:49] <spturner> so we need to go to Denis Pinkas to get an OID?  He's no longer at Bull.
[02:04:52] <stpeter> =JeffH: call me Ishmael
[02:04:57] <=JeffH> slide 7 : naming proposal
[02:05:14] <spturner> we should get that reassigned to IANA
[02:05:25] <stpeter> spturner: +1
[02:05:47] <=JeffH> spturner: LOL
[02:06:37] <tlyu> spturner: how do you get Pinkas out of that? he's only the ref for SPNEGO.
[02:06:44] <=JeffH> hannes(ht): use for "names" in AAA ?
[02:06:51] <hardjono@mit.edu> Service discovery?
[02:07:01] <=JeffH> sam: used loosely (?)
[02:07:08] <hardjono@mit.edu> UDDI over again?
[02:07:23] <=JeffH> ht: names used in diameter .... name effectively set by AAA client ?
[02:07:49] <sftcd> sean: carlisle might be easier, but denis does still use that same email addr 
[02:08:08] <=JeffH> sam: so u get it (the name) .... may not map onto AAA realm (?) .... not hard to get straight, just have to define what it is ..... 
[02:08:10] <spturner> Is that the From the reference column.  Assumed that they are the person in charge of the arc.  E.g., for PKIX it's Russ
[02:08:41] <sftcd> sean: pretend this is a variant of spkm and ask carlisle
[02:08:49] <=JeffH> slide 8: naming -- not that simple
[02:09:01] <spturner> ;)
[02:09:48] <tlyu> spturner: says nothing about registration procedures. also we'd logically go under 1.3.6.1.5.5 (security mechanisms), not 1.3.6.1.5.5.2 (SNEGO)
[02:10:58] <=JeffH> slide 9: naming - where we are
[02:11:27] <=JeffH> slide 10: error tokens
[02:12:22] <spturner> okay so then we're trying to get #15 assigned under 1.3.6.1.5.5.  This ought to not be too hard.  I'll shoot an email off to ask who we need to talk to.
[02:12:46] <=JeffH> leif as individ: wud be great to do this w/o redesigning GSSAPI... :)
[02:13:01] <=JeffH> sam: interesting point
[02:13:08] hardjono@mit.edu leaves the room
[02:13:12] <=JeffH> leif: was thinking of vendor status
[02:13:19] <lukeh> what's vendor status?
[02:13:28] <=JeffH> sam: great for sspi but wud help for gssapi
[02:13:31] <=JeffH> (?)
[02:13:44] <=JeffH> [ i may have miss-heard/parsed ]
[02:13:56] <=JeffH> slide 11: proposed extension tokens
[02:14:32] <=JeffH> leif: this wud be gssapi ext ?
[02:14:36] <lukeh> this is a typed hole in the GSS EAP protocol
[02:14:40] <=JeffH> sam: nope, doesn't involve any gss changes
[02:14:49] <=JeffH> slide 12 -- skipped
[02:14:49] <lukeh> in which things like channel bindings, etc, are shovelled.
[02:14:58] <=JeffH> slide 13: PROT_READY
[02:16:16] <=JeffH>   slide 14: IANA token Registry
[02:17:26] <=JeffH> leif: this wud be a reg of GGS mechs?
[02:17:42] <=JeffH> sam: no, reg of token types used by RFC4121, not abfab specific
[02:17:58] <=JeffH> need to ask kerberos if they are ok with this (krb, not kitten)
[02:18:05] <=JeffH> krb WG
[02:18:37] <=JeffH> if we want krb to do registry, they need to add to their charter..... thus we shud do it.....  [ AD heads nodding in affirmative...]
[02:18:57] <spturner> registering it in one of our docs is fine
[02:19:01] <=JeffH> slide 15: DISCUSSION
[02:19:42] <=JeffH> all ? used by abfab would be coming back as SAML attrs in SAML assertion
[02:20:10] <=JeffH> HT: what does this specifically mean?
[02:20:29] <=JeffH> leif: there are implications for how attrs are protected .... but not big deal on where they come from
[02:20:48] <=JeffH> leif: saml attrs are semantically diff from AAA attrs.....
[02:21:25] <=JeffH> HT: AAA provides full freedom, so have seen xml-encoded policies schlepped around "in AAA"
[02:21:49] <=JeffH> leif: deployment issue -- u'll have stuff, attrs, from mult layers, and will schlep around
[02:22:06] <=JeffH> sam: people will do more complex things than we were anticipating
[02:22:42] <=JeffH> draft-ietf-abfab-aaa-saml-00
[02:22:47] <=JeffH> Josh Howlett presenting
[02:22:57] <=JeffH> slide 1: problem stmt
[02:23:59] yoiwa leaves the room
[02:24:21] yoiwa joins the room
[02:24:59] yoiwa leaves the room
[02:25:17] yoiwa joins the room
[02:27:36] <=JeffH> slide 2: design considerations
[02:30:19] <=JeffH> mike jones (?):  reading the doc, it seems diameter is penalized cuz doing more frag than normally req'd
[02:30:52] <=JeffH> HT: AAA work in past has leveraged both diameter and radius 
[02:32:17] <=JeffH> HT: diam vs radius": major differences; forces design diffs; see diameter design considerations;  in this setting, shlepping saml assns, but if also schlepp SAML msgs, if u want to do that, then u must really go for diameter app
[02:33:19] <Klaas Wierenga> mark jones i think it is
[02:33:22] <=JeffH> sam: we need to be our own diameter app all the time; an attr we define might be useful for diameter stuff in general eg voip; needs to be in charter, but not in this doc; diam issues diff than radius issues; need to do new doc, doesn't change this one (leif) 
[02:33:40] <=JeffH> sam: but there are cases where can have diam - radius proxies....
[02:33:44] <=JeffH> ht: never solved that
[02:33:57] <=JeffH> sam: do we need to consider them?
[02:34:07] <=JeffH> ht: ans varies from time to time
[02:34:28] <=JeffH> ht: in one doc, have tried to address this quest in past, but shud avoid that pain if we can
[02:34:29] hardjono@mit.edu joins the room
[02:34:36] <=JeffH> sam: (agrees)
[02:35:17] <=JeffH> Mark Jones and HT have volunteered to do the Diameter-based spec
[02:35:26] <=JeffH> slide 3: design considerations cont'd
[02:37:00] <=JeffH> wrt to SAML considerations
[02:37:20] <=JeffH> [aside: see also: How to Study and Learn SAML <http://identitymeme.org/doc/draft-hodges-learning-saml-00.html> ]
[02:40:28] <=JeffH> leif (individ): if i wanted to do attr aggregation, i wud need ability to do what corresponds to attr queries, need to do it over abfab......
[02:40:38] <=JeffH> sam; can do over ratsec (?)
[02:41:12] <=JeffH> ht: nope, wud be a new radius (query?) type....
[02:41:15] <lukeh> Depends on whether you want to do it at the time of authentication or not
[02:41:34] <=JeffH> sam/leif/josh: if one has creds one cud do this...
[02:43:07] <=JeffH> ht: slippery slope, need to read radius design consids doc .... what is assumed behavior of radius server .... the issue of what the expected dynamic behavior is..... doesnt support fancy queries .... if query uses a data type that doesn't corresp to any defined radius attr, then server impls wud need to be updated......
[02:43:18] <lukeh> we need to upgrade to support EAP CBs?
[02:43:22] <lukeh> regardles
[02:43:34] <lukeh> this hasn't been discussed?
[02:44:13] <=JeffH> sam: notes that attr query use case ... can make radius svr look like (?) .... wud prefer to send something in both directions.
[02:44:24] <=JeffH> slide 4: design approach
[02:45:12] <lukeh>  can't the object type be determined from the XML?
[02:45:19] <lukeh> why do we need a separate type field?
[02:45:40] <=JeffH> u want to ask that question at mic?
[02:45:49] <buckeyeskeeve> lukeh: of course you could generalize beyond SAML that way too...
[02:46:00] <lukeh> then why not another RADIUS attribute
[02:46:02] <lukeh> are they that precious?
[02:46:13] <=JeffH> slide 5 current design
[02:46:23] <=JeffH> slide 6: current design cont'd
[02:46:30] <=JeffH> "construct type"
[02:47:33] <lukeh> my preference is for separate RADIUS attributes, unless there's some reason that we're running out
[02:47:42] <=JeffH> slide 7  current design cont'd
 
[02:47:44] <lukeh> I note that JANET has a namespace for RADIUS attribute types that is probably largely unassigned
[02:47:47] <=JeffH> " construct" 
[02:49:02] <Klaas Wierenga> lukeh: i think their namespace is even *unused*, afaik they use only some attributes out of the SURFnet namespace
[02:50:00] <=JeffH> jim schaad(js): need more than one saml asssn schlepped? need to tag origination
[02:50:06] <=JeffH> josh: good point
[02:50:15] <=JeffH> slide 8 input required
[02:50:16] <buckeyeskeeve> shipping more than one is a good argument for using a Response too
[02:51:21] <=JeffH>   ? at mic:  what do u mean about "naked assertion" ?
[02:51:35] <=JeffH> josh: that's an assn not encapsulated in a saml prot element
[02:51:52] <=JeffH> assn normall wrapped in a response elem
[02:54:45] <=JeffH> 4. Technical discussion (25min)
[02:55:13] <=JeffH> sam: krb wg folks are thinking of adding x-realm key estab to their charter -- folks here shud follow that
[02:55:22] <=JeffH> and participate as necessary/approp
[02:55:38] <=JeffH> [ krb meets tomorrow Fri ]
[02:55:58] <=JeffH> HT: are there plans for doing interop say at nxt IETF meeting?
[02:56:25] <=JeffH> leif: impl work is done by moonshot proj, sep from WG, wg chairs cant speak to this.....
[02:57:13] <=JeffH> sam: we do this stuff all the time  ...... we're expecting to do an interop event / testing during 2CQ2011
[02:57:37] <=JeffH> sam: code expected to be open source and available in early Nov-2010 (manage expectations tho)
[02:57:44] <=JeffH> HT: which code?
[02:58:26] <=JeffH> sam: what we have now, have gss impl, AAA lib, ?, some shib extensions, a SASL GSS impl
[02:58:39] <=JeffH> need on top of that: ext to radius svr, etc....
[02:58:45] <=JeffH> lots left to be done
[02:58:56] <lukeh> right, biggest missing pieces are no EAP channel bindings and no UI
[02:59:21] <=JeffH> leif: moonshot folk get together, those are not WG meetings, folks are not missing out on stdz effort if one misses moonshot meetups
[02:59:31] semery leaves the room: Disconnected
[03:00:02] <=JeffH> sam: try to avoid stdz discussion in moonshot context -- try hard to send stds comments/ques to approp stds lists
[03:00:11] <=JeffH> see project-moonshot.org
[03:01:06] <=JeffH> leif: if folks want to have an interop event co-loocated with IETF mtg, need to talk with chairs 
[03:01:24] <=JeffH> sam: volunteers to coord such event @ prague IETF meeting
[03:01:54] <=JeffH> mic lines drained --- meeting over -- see u in Prague
[03:02:06] <hardjono@mit.edu> bye all.
[03:02:11] <Klaas Wierenga> ciao
[03:02:14] <lukeh> ciao
[03:02:17] lukeh leaves the room
[03:02:19] Klaas Wierenga leaves the room
[03:02:19] joseph.yee leaves the room
[03:02:24] hardjono@mit.edu leaves the room
[03:03:28] sftcd leaves the room
[03:04:29] buckeyeskeeve leaves the room
[03:06:21] =JeffH leaves the room
[03:09:14] yoiwa leaves the room
[03:09:26] spturner leaves the room
[03:12:29] LZHULAPTOP leaves the room
[03:13:48] tlyu leaves the room
[03:32:08] semery joins the room
[03:51:51] Melinda leaves the room
[03:59:15] stpeter leaves the room: Disconnected: connection closed
[04:45:43] semery leaves the room: Disconnected
[04:57:29] semery joins the room
[04:58:19] semery leaves the room
[05:03:32] stpeter joins the room
[05:03:58] LZHULAPTOP joins the room
[05:13:58] stpeter leaves the room
[07:01:33] LZHULAPTOP leaves the room
[15:04:47] LZHULAPTOP joins the room
[15:05:43] LZHULAPTOP leaves the room