OAuth Working Group Meeting (IETF80, Prague) -------------------------------------------- Notes taken by Leif Johansson Chairs: Blaine Cook/Hannes Tschofenig - AD announce move of group to SEC area - security for oauth draft (draft-lodderstedt-oauth-securityconsiderations) presenter (lodderstedt): focus of the document is to give security guideline for implementors also read loddersted draft on security analysis to get the "why" (draft-lodderstedt-oauth-security) stephen f: make the distinction clearly in the draft lodderstedt: yes we try to hannes: the problem is we have lots of text floating about about security, question of which parts goes where. Now we have a more complete writeup. barry leiba: background: what needs to be in separate document and what goes elsewhere, other parts include text for implementors, protocol-developers and deployers hannes: please review, then security considerations text will be copied into the core document and a new WGLC will be done - mike jones: bearer token draft mike: go through list of feedback/changes from WGLC comments listed in Appendix B of the draft hannes: talk to registry question mike: will cover in the next point mike: talk about the error registry proposal, there has been quite a bit of debate about this and a compromise position may be evolving. seanturner: you need to carefully consider what process to require for registrations stephen farrell: expert review may be the right approach stephen farrell: lots of email on the list about this but why isn't there a discussion at the mic about this? Can't this discussion be managed better? Unfortunate that only one of the persons involved is here in person. Why is this taking up so much time? martin: could be that the list-thread on this is too large stefen farrell: whats the plan to resolve this? ehl (from jabber): decisions are made on the list and a resolution is a pending given new usecases from yesterday hannes: we could schedule a confcall to hash it out stephen farrell: just pick a date! you need a bit of planning to get this done mike: as an editor getting to a mutual accepable position of this is the only thing missing barry channeled ehl: ... missed this... barry: how is there ever a compromise on having a registry or not stephen farrell: only chairs can ever call consensus hannes: we've spoken to people who misunderstand this stephen farrell: we need to get a decision and move on mike: covering json token and client assertion credential hannes: could you summarize mike: I'd rather one of the users of it summarize it tlyu: where is this talked about mike: removed in draft 8, asked to be re-instated on the list but these questions have been ignored lodderstedt?: can it be added as an extension? lets get the core spec out, postpone this discussion tony nadalin: summarizes the proposal and use-case which is typically server2server authn lodderstedt: similar use-case in Deutche Telecom implemented as a private extension tony nadalin: we have deployments based on this feature from "wrap", we need it back in core hannes: you think extensions are 2nd class citizen tony nadalin: yes, weve stripped down too much, core spec is less useful hannes: do you care if its an extension? loddersted: yes but we would not be too upset, probably this needs more discussion, extensions would be worse mike: we need the chairs to make a consensus call hannes: we did but there was no clear consensus (basically 3 camps: core, extension and I want something different) mike: if there was not consensus to remove it why was it removed ehl (to tony): where was this in wrap? tony : will pull it up ehl: there is not consensus other that that we need new text leifj: iffy to remove a text wo wg consensus tlyu: lets stop talking process and start talking substance, when should stuff to in extension and not in core barry: stop talking process, respond to leifj: it depends on how text went into the document in the first place bill smith: review charter, why hasn't the group gotten 1.1 out the door? wrap isn't mentioned in the charter hannes: yes the charter should have been updated a while ago, 1.0 went through as independent submission stephen farrel: yes the wg knows what they do but the charter needs to be updated mike: what is missing at this point is a description of how non-browser apps would use oauth flows ehl (via jeffh): 1.1 ended up being rfc5849, also there is no experience to write normative text about non-browser apps mike: incredulous at that statement because google has done it already, they use oauth wrap because 2 isn't done if we can't do what they do with wrap using 2 we've missed an important motivation for this work ehl: google announced something tony: windows7 phones uses oauth wrap so we have implementation experience loddersted: we do to based on similar and proprietary work blane: .... is this useful to debate here? stephen farrell: is this another one of these recurring issues? resolve it! whats the status of the discussion around hard-coded keys in native apps? loddersted: summarizes that discussion mike: not having this one of the things stopping us completng the core spec, this is needed and important. there was previous text and was removed ehl (via jeffh): (on the google thing) they do js not in the way v2 does ehl: how about turning this deployment experience into deployed text? ehl: the section we're talking about that was removed was (section 3.2 from v11) and how was this about native apps? stephen farrell: we are here to talk about technical details! the wg needs to decide. hannes: everyone needs everyone in the base spec and getting everytying done very quickly, not possible hannes: .. something ... stephen farrel: guidance on how to move forward stpeter: claims made about what was in what section and was taken out, those claims can be easily substantiated or not by looking in tools. Do due-dilligence about the specifics! the wg can the review things hannes: looking at v11 at section 3.2 and describing the security properties and some of the discussion of the list around this tlyu: good chance this has signifficant impact on security properties, this means it should go into core tlyu: wrt native apps - we should also put this in core document. we should write text in core to say which criteria we use for putting things in core vs in extensions mike: .... ehl (via stpeter): only two minor issues left, client registry and [something else I missed] and security considerations ehl (via stpeter): client credential is a hook not a wholly interoperable feature, native apps are a whole new bucket stephen farrel: what other things are important to people? hannes: channels the arguments, explains the client authentication vs client assertion credential flows, overview of the arguments on the list ehl (via barry): native apps are a whole new bucket and so is client creds and not open issues lodderstedt: it was described in draft 11 and was removed this would be totally sufficient, we get lots of questions about native apps and this needs to be stated in the draft, we don't need to talk about extensions to this and the old text is less missleading than the current text stpeter: section 2.3 from v11 has text about native apps, revisit that text! ehl (via barry): [something about native apps and terminology] ehl: that text is useless mike: even pointing out the obvous would be a service to implementors that have not been involved in spec work loddersted: tony n: up until v12 we had text we've asked to have native app text be put back in and have had no reponse ehl (stpeter): its lip-service stpeter: we need consensus call about this: can we live with the text. the document editor serves the wg and can be instructed to put the text back in. ehl (barry): I don't recall a request to put it back. I'm not blocking on this. someone else has to build consensus stephen farrell: was this non-normative text? the wg needs to decide what to do for guidance for native apps blaine: often its related to UI and we should have guidance but this wg doesn't have UI expertice stephen farrell: agree but we're not talking about normative text, propose text tony n: we've asked to be put back in and we've added text in the security considerations about this stephen farrell: then thats it tlyu: hard to follow this discussion, suggest that text be included marked as "not yet consensus" in core until these discussions have been resolved shawn emery: [missed this] stpeter: to tonys point about having text about security text: non-normative text is good but we also need a security profile text for the types of apps that will use these flows. security profiles are not easy generally ehl (barry): I don't recall a request and I haven't rejected such a request hannes: ... ehl (stpeter): take the old native app text, clean-up and repost it stpeter: this is straight forward, can the chairs take a sense of the room? loddersted: [...] blaine: talk to a ux person so that a web developer can understand the text blaine: humming for putting the text back in ******* The room thinks the text on native apps should to back in and Tony volunteered to wordsmith mike: ask the question for client credentials stpeter: summarize the issue hannes: [summarizes] hannes: who would like to have client credentials back in the base spec? stpeter: was this normative or informative text (all): normative hannes: asks for hum on having client cred in base spec /// hum fails, hannes restart ehl: it was a misstake to remove it in v11 and was put in wo wg discussion thomas hardjono: not true - there was lots of discusison stephen farrell: summarizes hum ******** Sense of the room is to put the text back into the specification. lodderstedt: this will blow up work on the core spec thomas h: it won't blow up anything loddersted: we don't have consensus stephen farrel: ehl has a point in that some of this is undefined, this may block you later unless you nail this down more tightly ehl (stpeter): I'm 100% sure people are confused about this and don't know what they are humming about. stpeter: not channeling every line from ehl, exercising some selectivity scott cantor: I believe this is an extension point, allow people to write profiles. I would't use a saml-based example to avoid rat-holing. Its important to have the extension point in the base spec even if the extensions change the behaviour of the base spec blaine: we need normative useful text tlyu: extension points are useful but small well-defined holes are better than big ones. Text we talk about should talk about what kinds of things is envisioned for this extension point and this should go into the security analysis. lodderstedt: we already have an extensibility mechanism that covers this scott: agree that nice semantics is good but not always possible blaine: there is question around the text and not clear that the text represents what people want thomas h: I will draft new text ******* Thomas Hardjono will write new text to replace removed version 3.2 from v11 and post to list. Will talk to Scott about non-saml example. hannes: to scott: are you ok with extension points in the current spec? scott: to mike and tony: why are existing extension point not enough mike: not specific enough, you can handle client credentials/assertions wo defining a whole new flow stephen farrell: don't understand mike: removed section (3.2 v11) is pretty clear. ehl is correct you need a profile ontop of this but the removed text goes a long way. stephen farrell: so new text.... no saml? scott: saml too controversial mike: to thomas: will you retain the text and clarify or write new? thomas h: will write explanatory text, normative text can stay as is hannes: we need a specific case and semantics to ensure interop scott: we need to write normative text that specifies in detail how to process messages that contain client assertions scott: [analogy with saml extensibility - cf audio] ehl (stpeter): we are not talking about grant-types using assertions, we are talking about client auth which is barely define as it is, read draft-ietf-oaht-saml2-bearer how is new text talked about here different from this draft? tony: don't understand that comment at all stpeter: (interpreting) client could present a saml assertion as a credential scott: I understand ehl point but semantics of using assertion for user auth is just as well defined and might be useful, the draft referenced by ehl is about service authn [leifj: not sure I got this point down right] hannes: [...] scott: its basically a quiestion of different trust model, related to n-tier in enterprise so this sort of semantics is used ehl (blaine): why is this section not a general http auth scheme? mike thompson: but this is involving a 3rd party... stpeter: no this is about client authenticating with assertion of some form stpeter: good question: do we need to define something new? hannes: design team perhaps ehl (stpeter): why not use client auth for http instead of defining new technology? tlyu: is it about the tools? blaine: history about about php and md5 ehl (stpeter): clients now have the ability to do http auth wo problems hannes: perhaps form a design team stpeter: if client can use httpauth then why not use that for this? stephen farrell: ref to saag presentation about UX problems for http auth, design team sounds like a good idea stpeter: this is not about user interaction, this is all in the background so not sure that UX applies ************* hannes: will form a design team using text form Thomas as a starting point. Bring back proposal to WG. scott: just re-read the text, this is about authentication, the text is very clear hannes: with authn you show freshness etc scott and others protest this interpretation of the term "authentication" scott: the text as it currently reads is about authentication scott: assertions are a way to get around the issuance of long-term keys and passwords are just bearer tokens hannes and stephen: talk about the scope for the design team ehl (rlbob): I'n now opoosed. take all of this client auth out. - lodderstedt on oauth security goes through slides starting with objectives of the document, overview of I-D, Plan/Ideas. barry: this will be an non-normative reference from the base spec not to hold it up stpeter: whats the relationship between this and the security considerations in the base spec lodderstedt: refers to meeting already in notes above, scoping of security considerations doc ... discussion on scope of the document ... lucy: need a plan to merge scopes of berrys and loddersteds docs which have very different focus bill smith: [...] lodderstedt: my doc has broad scope aimed at more audiences lodderstedt: who has read the doc? hannes: wanted to pickup doc as part of charter stephen farrell: if its referenced from base then it makes sense to have in wg hannes: please read the document, will ask for WG adoption on the list in next couple of weeks igor: it is excellent starting point and it is the only one hannes: true but will allow for reading-time hannes: only 5 minutes yet - Mike Jones on json web token brief summary on bar bof. will try to come up with unified approach, there is also a jwt profile for oauth which is intentionally parallell - Zachary on use-cases document summary of UC document hannes: we need reviewers leifj: ask for volunteers and hold them to it hannes: who would do review: got volunteeers from lucy and tomas h who promised to do review on list - Mike Jones on simple web discovery summary draft - Finishing up the session hannes: come and volunteer for design team, thank you for showing up lucy: what happens with re-charter hannes: we'll update the charter based on what we are actually doing at the moment, then do a recharter for new work stephen farrell: the process is: demonstrate success and then think about next steps hannes: too long for IESG to review charters stpeter and other IESG members protest this ... the meeting breaks up ...