OAuth Berlin IETF Meeting ------------------------- Notetaker: Ludwig Seitz (1st session) ** 14:00-15:30 Monday Afternoon session I -- Welcome and Status Update (15 min, Chairs) Hannes reports on the OAuth Security Workshop 14-15th July 2016 in Trier/Germany Hannes gives a summary on the milestones, the dates need to be updated to make them more realistic Discussion on the status of draft-ietf-oauth-jwsreq John Bradley: Draft has been stable for a long time, small comments need updates, should be done very soon. -- Brian Campell presents OAuth 2.0 Token Exchange draft https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ Example use case Current status Next steps Open issue: Addressing PoP tokens Justin via Jabber: Inbound tokens can be handled easily since the AS looks the things up. The AS doesn't validate the PoP request itself, but it looks up the token identifier John: We may have different levels of proof-of-possession Hannes: When will that work be completed? John: Need to work out the foundations and leave out the details for later in specific pop-specifications Phil Hunt via Jabber: Make clear that this doc is "bearer" only. PoP is more complex. Justin: Introspection (RFC7662) has forward looking PoP reference in an appendix, we should use that. Nat: draft requires STS to be the token endpoint? John provides clarification Hannes & Brian: Check out the proposal by Justin as a way forward. Mike Jones: If using token-binding you can move pop into the application and use bearer at OAuth level Mike: Recommend to check if token-binding issues also apply to token exchange use cases ctd. issues discussion: ID Tokens Tony: Claims of the subject and issuer combined together Brian: Does not understand Tony: Check email for details Mike: It's kind of a hack for OAuth token exchange, maybe ok hack, what are we trying to achieve? Is there a cleaner way to achieve this? John: Might have ugly architectural consequences Tony: Usecases where we want multiple tokens for one reuqest, chaining them to each other. John: Need a more detailed discussion to better understand the use case Hannes: Don't see a usecase, just a solution, want to see the usecase Brian: Will try to understand the usecase ctd. issues discussion: Title Brian: Comments and opinions on the title welcome. Hannes: Need two reviewers --- William Denniss presents OAuth 2.0 for Native Apps https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/ Demo videos of the user experience on 3 different smartphones ... and on a desktop environment ... and on a CLI interface WebView is going to be deprecated Different code libraries available for this are presented Todo: Implementation detail appendix for Windows Summary: Document stable, open issues resolved, suggest WGLC John: Also supports WGLC, note this is a BCP, needs to be updated to keep it current Would be good to have it out before we start to issue deprecations Brian: Support WGLC Justin via Jabber: +1 for WGLC Brian: How is the call-back handled in the CLI William: Using loop-back IP Brian: What about port matching? Hannes: Reviewers for the WGLC Brian, Dick, Torsten volunteer Mike: Will we get the new appendix before WGLC? William: Yes, will submit a new version this week Mike: Will have the MS developers look at this once it is available --- William Denniss presents OAuth Device Flow https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ Could be called "OAuth for limited input devices" Shows examples of code/documentation, asks for feedback if anyone knows more examples Olle Johansson: Define alphabetic (ref slide ??, presentation has no slide numbers) Leif Johansson: You can use proquint for this Torsten: Doc has no security considerations yet, what is the story for session fixation? William: Not managed to write it yet, will do Dick: Is there a mechanism for the device to identify itself? William: Not in the spec, but should be Dick: Did you intentionally exclude devices with no UX? William: If you have two-way channel you might have better ways to do this. Should not be excluded Dick: What if you don't have two-way? William: Use basic OAuth might work here Dick: The device might have a cert William: Will look into it. John: May be covered in ACE, should not overlap John: Might have some limited input device such as a remote control. Could use push-notifications to other user device? William: John: Popular flow: tree-factor authN should try to re-use Scott: Have a look at our draft (draft-hollenbeck-regext-rdap-openid), usecases were you cannot assume that you don't have access to a browser Olle: WG Stir: Create JWT for phone numbers, move away from digest-md5. Optionally use OAuth in the SIP protocol. Torsten: Working on OpenID extension to do out-of-band authN, need to coordinate with this work -- Mike Jones presents Authentication Method Reference Values https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ Document stable since long time, WGLC? William: +1 for WGLC, we are using this in production Torsten: +1 for WGLC, we use it as foundation for our works --- Hannes advertises OAuth sec meeting on Tuesday 18:20 meeting at the IETF registration desk Mike: Those interested in token binding, cooperate with tokbind come to meeting tomorrow. -- Mike presented metadata draft addressing the authorization server metadata use-case. https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/ Suggests that other uses cases such as the ones raised by Phil Hunt in Buenos Aires could be addressed by other drafts. Mike is drafting a resource-server spec, but it it's not yet ready. Discussion on signed metadata. Phil is happy with the proposal. Document renaming proposed that drops the word "Discovery". - Torsten and Brian Campbell supported – Mike asked the room if anyone objected, and nobody spoke up. Dick raised question of how the document will be signed. Answer: JWT. Brian Campbell question of token use. Phil: you want to know that you first discovery from the right place. How do you know the attacker has not misinformed the client. - we want to do discovery for SCIM. – we want to add email support. Nufurious resource server attack is a concern. John's mitigations for nufurious resource servers: a) backpointers at authoirsation server to say which resources are trusted. Medium mitigation because resources you trust may go bad. b) audience restriction, only issue token that is valid at an individual resource so they can't play it at a different resource c) use some sort of proof of posession so the resource can't replay to another resoruce d) There is no other magic pixy dust other than that. Brian notes that it may be hard for the authorization server to list all resource servers. You need audience restriction on the access tokens to prevent that. OAuth 2.0 Mix-Up Mitigation https://datatracker.ietf.org/doc/draft-ietf-oauth-mix-up-mitigation/ Andre: We should create a document to evaluate several mitigations and protocol extensions on offer. There may be mitigations where changes are only required on porovider side, others may be both If we try to develop prodider only chagnes it may be simpler We can compare mitigations by what protections they give us. Two missing security properties of OAuth. Most pragmatic: how complex is the mitigation. Analysis of mix-up mitigation. Mis-up where we include iss+client_id. Requries protocol changes on both provider and client. Addresses the authentication property. Doesn't cover authentication fully, only the attack itself. Another proposed mitigation: using POST binding only + Origin check Proivder + client Gives us an additional browser-level way to identify caller (identity provider) Justin notes: this doesn't work for native apps. Hannes: how do we proceed with the mix-up draft. Discussion on which approach can be implemented faster by both clients and servers. Tony: still don't have a clear view of all the attacks. Lots of drafts out there. Torsten: This draft only addresses 2 attacks. What about other attacks? We should create a BCP document for all attacks. Hannes: OK, but we also need to work out what the recommendation for mix-up. Andre: – I defined that there are 2 missing security properties most attacks fall into those categories – Authentication failure, containment failure. – Authentication: double-redirection protocol, doesn't have a good way to figure out who called the endpoint. All attacks caused because the authentication and redirection endpoints dont' know who calls it. – Containment failure: whenever something is leaked, code, token, they are leaked through known ?? we want to strengthen the security of the client redirection flows. John: given the inability to agree on normative changes, and the fact major IdPs don't want to keep reving their endpoints, we should document best practices now and rev the spec once and for all. Torsten: I agree. We will solve this one problem, but then another will show up. Code injection? Malicious users bind stolen codes to sessions. Andrew: doesn't see this as a huge threat. Justin agrees with John that we should write the BCP now and collect normative changes for a spec revision. -- Token Binding for OAuth and OpenID Connect and Implementations for the Token Binding Protocol https://datatracker.ietf.org/doc/draft-jones-oauth-token-binding/ https://datatracker.ietf.org/doc/draft-campbell-oauth-tbpkce/ https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ IETF token binding WG is about to finalize a set of documents. We wanted to look at how OAuth can use this as specified before they are done. Goals: specifiy a means of using token binding with OAuth and OpenID Connect Enable end-to-end testing to identify any gaps. Refresh tokens are easy to bind: just 1 channel. ID Tokens: 3 parties using 2 connections Access tokens more interesting: three parties using two or three TLS connections – a lot like the federated token binding use-case but some of the details are different The discussion of the parameter vs. the header consumed a lot of the token binding work group's time TODO: writeup api guidence. Like if you support a referred token binding id, you should provide applications a secure and appriorate way to for federated token binding this is not making specific requirements on APIs it's if you support certain functionality this is what you need to do * Discussion Tony: I assume that text will go into OAuth, not Token Binding Mike: That was not my expectations. John: I believe the goal was to have some sentances added to the token binding spec to the effect hta tif hte platform is providing referred token binding to applications it should provide an API for those applications to use it. Lief: and the privacy and security considerations to match. John: This doesn't force an application to provide referred token binding. Leif: Correct, guidence, non-prescriptive. Though people were worried about the privacy implementations. The reason this matters to OAuth, is that the natural way to do token binding is to use a referred token binding. If we believe that implemetnations will be able to do that. I know WIndows 10 can, and maybe google. Then it's reasonalble that the ysntax you use to achieve token binding is a referred token binding. William: voices support to that methodology, we have the representation of this pattern already, and the major implementations can support it – let's just use it! Dick: client may be accross multiple machines, may need Torsten: why have we not token-bound the front channel for the code redirect. Dirk's document includes that. John: we're not as smart as Dirk Torste: it would be valuable to have a mechanism to bind the code to the channel, we just mentioned the code injection attack. Tony: this is a bad way to proceed. We don't want to rev Dirk: the referred token binding draft wont' have the words "oauth" or "access token in it" Jeff: that's what I was going to say Justin: glad to see you're on board now Tony! Mike: number of places where token binding could also make sense, such as for JWT Client Authentication, and JWT Authorization Grants. Brian: My doc is mostly for native apps. Dirk's document explains it in a more neuenced way. The doc I wrote should be folded in 1 token binding doc. William: One thing we learnt from the security researchers last week in Trier is that it's a good idea to start out with your goals so they can be proved. In my discussions with Dirk is that by starting with the goal of "the MitM is on certain connections how can we make the whole thing secure", it is easier to prove, and we captured things like security the redirect. I'd like to see one comprehensive document. John: can we adopt token binding as a work item, taking into account dirk's document and possibly merging them into one document. Hannes: Lets see if people even want to adopt this: For: 13 Against: 0 Hannes: pop tokens: do we want to proceed with the symmetric implementation of pop or move it over to ACE? Mike: There are a bunch of Microsoft use-cases where they want to do application-level token binding for OAuth. To the second question on moving to ACE, that would scare me. John: I don't want to complicate both by merging pop and token binding. Hannes: how do we proceed with HTTP signing John: HTTP signging is hard, but Justin is doing an execellent job. There are end-to-end applications wher eit's useful but it has all the horrible baggage of OAuth 1, done in JWT and nothing makes it a bullet proof solution in all cases which makes the adoption slow. Some people may need it. Brian: We'd be better served by having less options and one set of protocols that does something instead of all these different Justin: Message level signatures are a nessescary thing. We could alternatively publish http signing as-is. Who would like to keep the doc in the group, and who would like to refocus the effort. Ludwig: we need synmetric pop for ACE if you dont' do it, we will. Who wants to continue http signing in this group? 0 Who prefers it to be abandoned? 3 Torsten: What value is key distribution if we abandon HTTP signing? Lucy: Can I ask for two sets of hums. Whether or not to do this metrics stuff here or move to ace. Then can we hum on whether or not to put on hold or abandon. Who wants to put http signing on hold? 5 Who is in favor of abandoning? 3 Symmetric key distribution: who is in favor of moving it to the ACE working group? 0 Who is in favor of keeping it here: 7 Abandon: 3