Open Web authentication BOF =========================== MONDAY, March 23, 2009 1300-1500 Afternoon Session I Room: Continental 4 Jabber logs: http://jabber.ietf.org/logs/oauth/2009-03-23.txt Jabber Scribe: Jeff Hodges ht: bof @last ietf charter discussion on list blaine: don't want to say "won't change oauth at all" ht: don't want to wordsmith chart here want to use time here wrt sec aspects eran rewrote spec rich barns: why this in apps area rather than sec area? lisad: had disc 4 mos ago, have disc w/sec ads, reqs http exp, & sec exp, will have both here. but Lisa was "there" and willing to sponsor the original BoF ---- Eran: there's an -01 draft rev wants to demote the redirect-based flow as being the default, he's happy i.e. the initial setup is req'd, but 2nd part is alterable tried to simplify terminology, make it more aligned to "web/http" terminology ? asks why retained "consumer key" term ehl: didn't want to make prot changes (that is name of a "parameter"), didn't want to break present impls etc. ht: (explains that want to not mess with how prot works now, estab just a starting place) ?: flow diagrams would be good jh: I have done some, just use them, tho sanity check please ehl: interoperability is the issue he's really interested in (as well as sec review) here's list of stuff he's ident'd and is nec to agree on... * no req'd sign method * 3 techniques for passing params from client to server -- not one prefered * endpoint http methods ekr: to what extent if any do you want (prot metadata)? ehl: (points to that item on list) * endpoint http methods -- spec only rev's POST, nothing req'd * spec documentation/disco metadata disco -- how much want to do here, how much not here * client reg consumer_key, consumer_secret -- out of spec for now, manual stdz this? * error codes and error handling huilan lu: scope of work going forward? ie linking delegation and HTTP methods? blaine: hl: there's more gen usecases, eg SIP, XMPP, etc... blaine: to what extent can we generalize these things or not? we agreed to work on something as compatible as possible with current oauth ht: explains that it is difficult as yet to be alble to say just what is in scope or not... blaine: so nothing has really happend since last ietf, so hard to say.... ehl: in chart proc, ques was raised "do we want to go higher layer an define general deleg method, and then bind to http?" so oauth is spec to http now, but http specific, so good exercise to do generalization, but someone needs to step fwd and do it, disc so far is wrt usecases.... steve norris ?: sync clocks? shd'n't be in there... ehl: the whole way spec uses nonces is ... .incomplete steph farrell: spec helped by deciding sig method and little things like that but harmed by doing the "bigger" things, eg discovery, so do those things later ehl: discovery isn't well-addressed in the spec presently, so if we don't address it, spec will be "incomplete" and need to be clear about that rich barnes: want to be clear about the notion of generalization, main confusion wrt present doc is that that isn't there, and so wasn't clear to be able to derive the sec model in present spec, and so doing the abstraction may actually make sec model more cleaar. rich volunteers and ekr volunteers too. thomas hardjono: does ietf doc superseed orig version? and also what about authn "user" ? ehl: no superseed, and not trying to do authn th: shud this be called a framework? ehl: this work isn't deprec the old work cuz the old work is "there" and isn't "going away" old spec is more of a "best practice" thomas hardjono: does this imply oauth 1.0 is deprecated? ehl: no ht: no... blaine: call it oauth 1.1 ? (ekr suggeste4d) th: is deliverable one spec or mult specs? ht: current draft chart mentions one ekr: spec has two things: a prot, and also a framework for exchanging these toks, estab them, etc. major strength of frmwk is that it is applicable to various other prots blaine cook (BC): what we're trying to do is codify these estab'd approaches ehl: ... hlevangong: What about the 2-legged scenario(s) - will there be clarifications in this work as to what use case(s) they cover etc.? ehl: sentiment at prior IETF was not to look at two-legged scenarios samehartman (sh): a good two legged case would be useful ekr: was going to speak in favor of 2legged, but changed mind that was joke i guess but if going to go thru this pain to do 3legged, shud do 2legged too.. seth from yahoo Seth Fitzsimmons : signatures are closely tied to the http binding.... in favor of more general signature doc that can be applied to XMPP etc ehl: new slide: security * signature scope prot has been design to supp primitive dvlop environ, eg php, javascript, etc. don't have access to the raw data * secrets in clear if not using tls, then they are in clear * dos attacks vulnerable do to the two steps, client-side step is easy/cheap, plus w/callbacks, no way for server to know to send user to a safe place (sam hartman observation in sec review) -- identity of client isn't verified, so server might redirect client back to some bad place blaine: want to get these issues out in open so can discuss them ? meadhbh.siobhan: does anyone remember MOSS? after PEM created a prot that allowed us to have two sep impls that conformed but didn't interop -- keep this in mind plesase ehl: new slide - New Features * alt token methods * body hash * lang pref paul hoffman: we have lots of these feats in http, u saying "those don't work for us, need to reinvent", but if is a full http citizen, then picking and choosing from existing http services doesn't make sense ekr: how much is the limited sofwr enviorn influence the prot design? bc: the lang stuff, if want to do init auth on another machine, an it's localized to a diff lang, then if try to use on another machine with diff lang localization, then it might not work ehl: there's a big concern with the redirect flow ... some sights don't want to redirect users away and just hope that they come back .... now, wrt http lang pref headers, dunno why use of them is broken today, but they aren't that useful today, so people brought up the lang pref cuz they want to tell a site they use one lang, and then get redir'd to another site, want that 2nd site to have that lang pref set a lot of this is not likely to be inlcuded in the core spec, but we need to metion it... ? of yahoo, a supporter of lang pref: so want a way for user to goto partic site with lang pref, set it, and go to another site in dance and use same lang ted hardie: a way to make this work fairly globally, want to be able to pass lang prefs around, but if depending on the prot to perform properly wrt authz is separable -- ie you want it to work without lang context, can't depend on it --- bc: there's things on list we can discuss.... ht: but want to do charter stuff bc: orig chart had 2legd stuff outta scope... seems there is sentiment in room on whether 2legged is in scope lisa: yes can do hum on that, and also wants to see hum on whether there's going to be a working group zachary: ? nonces ? bc: nonces are there to prevent replay attacks, sep from creds -- timestamps are there to prevent resource exhaustion on the nonces sh: if do 2legged, want to do good job on it, i.e. will need mut authn and channel binding -- so if we can get people to do those, want to ensure they are in-scope ekr: SCRAM mechanism is also being worked on, would be nice if IETF standardized on one challenge/response mech instead of 10... otherwise, has big list of little nitpicks, guess can send them in email sh: we've developed lotsa solns for same problems, likes that (wrt scram) ekr: nice if can make list of what all we all want and then prioritize... sh: while we're getting ponies, can we get protected way that i'm asking for a feature, and we can get secure impl... (satirical comment) ekr: would be nice to have some idea of PHP4 constraints going in ... eran ehl: want to get this spec in current form at least cleaned up and pub'd can we see if we can agree on the charter? maybe useful to go through charter again looking at changes based on today's discussion -- ht: we should thk JOn Peterson as RAI area director (gave him a bottle of wine...) jp: is this in return for my silence on the charter? -- ht: at end of chart, we wonder about 2legged scenario ehl at mic more or less describes what it is ht: takes show of hands wrt including 2legged hannes: vote on including 2-legged in scope: 20 or so in favor, 2 opposed bc: actually what we want is to look at oauth as a way to move fwd and not break bkwards compat, if there's sec issues and interop issues then can break bkwds compat, but need good reason huilan lu: maintiaing state on svr good enuff reason to brk bkwds conpat? lisa: good argument is good reason phoffman: from lessons of smime, need to decide early what's in and what's out, else WG will last forever -- i.e. ref'g bkwds interop with outside spec might not be good idea -- smime WG got tangled in knots with arguments about what's "important enough" to justify compatibility breakage, very hard to "compare" importance bc: if there's a big problem sec-wise, want to fix right away, but if just "sorta nice", then we're not going to do it ph: but.... sfarrell: think can constrain wrt prot version wrt bkwds compat bc: do we have a charter we can agree on? lisa: if we include 2legged and water-down bkwds compat lang, do we have something we can agree with? vote: many hands supporting this proposed WG, none opposed ht: bof concludeds @ 1424h ============================================================================