Re: [OAUTH-WG] OAuth Working Group Meeting at IETF 99 21-Jul-17
Justin Richer <jricher@mit.edu> Fri, 21 July 2017 15:55 UTC
Return-Path: <jricher@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F1E13178B for <oauth@ietfa.amsl.com>; Fri, 21 Jul 2017 08:55:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haFRjG1WQ6DG for <oauth@ietfa.amsl.com>; Fri, 21 Jul 2017 08:55:10 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B53131935 for <oauth@ietf.org>; Fri, 21 Jul 2017 08:55:09 -0700 (PDT)
X-AuditID: 1209190e-69dff70000004181-02-597223da7f21
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 64.05.16769.BD322795; Fri, 21 Jul 2017 11:55:07 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v6LFt577029138; Fri, 21 Jul 2017 11:55:06 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v6LFt4jP030719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Jul 2017 11:55:05 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <7659AE15-7BB6-4106-85C7-DC780B13C424@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1FD25D9D-429D-4AA2-862D-7E9DA0540A50"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 21 Jul 2017 11:55:03 -0400
In-Reply-To: <CY4PR21MB0504BECECAE0BFB0E13D906FF5A40@CY4PR21MB0504.namprd21.prod.outlook.com>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
To: Mike Jones <Michael.Jones@microsoft.com>
References: <CY4PR21MB0504BECECAE0BFB0E13D906FF5A40@CY4PR21MB0504.namprd21.prod.outlook.com>
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAKsWRmVeSWpSXmKPExsUixG6nontbuSjS4PxnIYu90z6xWJx8+4rN gcljyZKfTB6tO/6yBzBFcdmkpOZklqUW6dslcGX0HzQu2LGYpWL2wX72BsYXl5i7GDk4JARM JGZd8ehi5OIQEljMJDF3128WCGcjo8S10z9YIZyHTBLLP8xm72Lk5GATUJWYvqaFCcTmFbCS mHm0lRXEZhZIktg/+y4jyFReAX2J3ueMIGFhAQ+JBe9mgpWzALU+ejgHzOYUiJU4vuUcWDmz gLpE+0kXkLCIgI7E44vf2EBsIYEYia5VD1lAbAkBWYlbsy8xT2Dkn4Vk2SyEZRBhbYllC18z Q9iaEvu7l7NgimtIdH6byLqAkW0Vo2xKbpVubmJmTnFqsm5xcmJeXmqRrrFebmaJXmpK6SZG UFBzSvLtYJzU4H2IUYCDUYmH14ClKFKINbGsuDL3EKMkB5OSKO/ddYWRQnxJ+SmVGYnFGfFF pTmpxYcYJTiYlUR4mwSAynlTEiurUovyYVLSHCxK4rziGo0RQgLpiSWp2ampBalFMFkZDg4l CV5BJaBGwaLU9NSKtMycEoQ0EwcnyHAeoOGhIDW8xQWJucWZ6RD5U4z2HJtm/PzGxPFqwn8g eej3ie9MHMdApBBLXn5eqpQ4b7oiUJsASFtGaR7cZFDCSnh72PQVozjQo8K8WSDDeYDJDm72 K6C1TEBrH7kVgKwtSURISTUwttS8m3rmoe/yuayX497UGm4PYuzbdumQ0Zqz04KSTcRbFZqP LLr+IVMxX3LV1xW7X7xfuGPNM9Elb9aWzzp83XL/zEgxrfD9h54Y7Kmuuzpjz8TYnN8WGy5/ YtX5bKzUdupVzu6n3Foc8pwHXrutPZOyR3Pt4YfrcpirjO9G/zr5LNU2pdDCKVSJpTgj0VCL uag4EQAlUb8VMwMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/LB1SgoT280MlzUfDkGK2xHCcdlo>
Subject: Re: [OAUTH-WG] OAuth Working Group Meeting at IETF 99 21-Jul-17
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jul 2017 15:55:13 -0000
So even though I withdrew my suggestion of adding a parameter to device flow, that was only because my own direct reason was addressed, and I support adding it back in for all the reasons that Annabelle and Dick and John and others brought up in conversation. — Justin > On Jul 21, 2017, at 8:59 AM, Mike Jones <Michael.Jones@microsoft.com> wrote: > > OAuth Working Group Meeting at IETF 99 21-Jul-17 > > William Denniss presented on the Device Flow > > Justin Richer discussed a suggestion to add another parameter that he'd made on the list > William Denniss clarified that the client constructs the URL - not the server > Justin withdrew his suggestion > Justin will review the text and suggest clarifications to help people from misunderstanding it in the way that he did > > Annabelle Backman suggested that there be a separate parameter that contains the clickable URL > Annabelle suggested that there be a separate parameter for that URL > Then we don't have to standardize the URL for the user_code > It would allow the server to use a different URL for that > Dick Hardt suggested that the user code be URL safe > Annabelle: People implementing clients may not always be reading the specs > David Robin: There's an opportunity to send people straight to the final URL > Nat Sakimura: Our implementation sends both the URL and the user_code > > Nat: It's easier to enter Japanese characters than ASCII in Japan > We should allow the code to be Unicode > Dick Hardt: Amazon recently looked at what can be entered world wide > He said that numbers work really well > William: Maybe we can suggest that numbers be used as a best practice > I do not want to prevent the use of letters because it would bring our implementation out of compliance > Mike Jones: Microsoft also uses letters in the codes > > Nat: If we are targeting QR codes, send the QR code directly > QR codes are used on ATM machines in Singapore and Australia > If it's going to be an image, it should be a separate parameter > > Annabelle: Trying to tailor the spec to particular delivery mechanisms would take us down a huge rathole > Dick: It's not clear we're really trying to achieve interop > William: Justin and I did interop testing with both of our implementations > Dick: Amazon is using independently written implementations > In the Alexa world, there are many third parties producing devices that we want to be able to make calls into Alexa > > John: I am influenced by the arguments that having a different endpoint for the pre-composed URL than the user typeable one is a good idea > I don't know that we should add the QR code directly > Apps could use introspection to get a QR code or sound files but that doesn't have to be in the standard > Third party clients operate with YouTube and other services > > William: There are two changes we're discussing > 1. Having a second endpoint for the pre-composed URL > 2. Saying that the user code should be URL safe, with numbers recommended > > William: If we make it Unicode, we should use a different URL > > Mike Jones: Adding a separate endpoint is a big change > John: The change is to have a separate parameter for the composed URL - not a separate endpoint > Anything internationalized immediately leads us to sending a composed URL > Using a different endpoint is an implementation choice - not something for the spec > The client needs to know the script that it's going to display > A Korean printer might use Korean script in Korea but a different script in South America > Nat: Numbers are the best choice internationally > Annabelle: The more complicated we make the display requirements, the more use cases we'll exclude > John: UTF-8 may not be displayable on all devices and the right fonts might not even be installed > Annabelle: We are suggesting a new parameter with a URL value - not a new endpoint > > Leif Johansson: Has anyone done a security analysis on this? > We shouldn't do these changes without another last call > > David Robin: Are we deprecating what's shown on the screen or is that option still on the table? > (On the screen, the client was shown merging the different pieces of information) > Maybe client composition should never be done > It's either opaque with the third parameter or you need to do composition the way the draft is now > > Annabelle: The current draft does describe Security Considerations about remote phishing > William: We try to prevent phishing by asking the user if they have the device in their possession > > Lucy Lynch: These are big enough changes to require another working group last call > > William: There's no requirement that you poll at any particular rate > > Mike Jones: From an engineering perspective, why do people want to do things differently than what's currently specified? > Dick: We looked at this and saw some of the issues > > William: The other major change being considered is defining new authorization parameters > device_id, device_model, device_name > This is to support device revocation > They are all optional > > Annabelle: This does not seem unique to the device flow > William: I agree but it's worth solving for the device flow > Annabelle: If we're overly prescriptive with what information is being sent, we could end up ruling out use cases we haven't thought of > Hannes Tschofenig: This came up in Chicago > We might want to do some form of authentication > These parameters are intended for revocation, but they could be used for authorization as well > William: I'm not trying to capture every possible parameter for every use case > Google does have use cases for these parameters > Dick: The device ID is problematic > The other two new parameters are useful > William: The device ID lets the authorization server group requests > Annabelle: If this is happening at the AS, it could assign an ID on its own > Annabelle: Model and name present a potential phishing risk > Hannes: The AS can't infer the device name > Annabelle: The AS should match the client ID to the device type > > William: If we add these parameters we need to add Security Considerations > William: We shouldn't enable display of random hacker-generated text > > Dick: The model allows multiple different things on a device > For instance, enabling Netflix on your Roku - not just enabling the device > > John: Device ID is a correlatable identifier > Some manufacturers go out of their way to prevent multiple applications from knowing that they're on the same device > This is its own thing and should be in its own spec > Let's finish the device spec and consider this a separate add-on > Lucy: I think that John summarized this correctly > I could drive a truck through this > Hannes: The context of this spec made discussing these possible parameters reasonable > > Justin Richer: This loops back to Mike's question about why people are bringing this up now > People have been implementing something like this for years > Now people are reviewing the spec and asking if it fits the use cases they've had for years > We are seeing more and more devices where this functionality makes sense > I think this should be a separate spec > I wrote such as spec in 2010 draft-richer-oauth-instance-00 > This has applicability in other places and it's a big ball of wax > It's too much to try to slip this in at the last minute > > Brian Campbell: Maybe we could accomplish this without device ID > We would lose grouping but that would alleviate a lot of the privacy concerns > Dick: You only need a locally scoped identifier > The global one is the one that's a problem > > William: There is running code > Google's implementation complies with -06 > MitreID implements it > Justin and William did some interop > Hannes: There are other open source implementations > > ================ > > Brian Campbell presented on OAuth Token Exchange > > It is a framework enabling token exchange > The participants need to know what kinds of tokens are suitable for their use cases > Draft -09 included small changes to address actionable WGLC feedback > Hannes will review feedback that didn't appear to be actionable > Brian believes it's ready for Hannes' write-up > John: Write it up > > ================ > > Brian Campbell presented on OAuth Token Binding > > Provides proof of possession for OAuth tokens > The 3 core Token Binding specs are very close to the request for publication > The last OAuth Token Binding spec version added introspection language and IANA registrations > Brian added an open issue about the need to allow distributed Web Server clients to opt out of token binding for refresh tokens > Shared access to a public key may be difficult or impossible problem > Sharing on demand generated client-side keys is very hard > Dick Hardt: It's not going to happen > Brian: The real value is Token Binding the access token > There are other means of securing the refresh token > There are two ways we could do this > Toggle the behavior based on client registration metadata > Or provide a run-time toggle with a parameter > The metadata parameters already largely exist > Mike Jones: I think the metadata approach is reasonable > I don't want to think about the security implications of providing a parameter to disable a security feature at runtime > Brian: I think the metadata approach is reasonable > John Bradley: I agree with using metadata > > John Bradley: As a separate issue, we may eventually decide we need a parameter to explicitly communicate the referred token binding separately from the Sec-Token-Binding header > There are more discussions needed on the parties using the bound tokens > William Denniss: Is this only for confidential clients? > Brian: Yes > William: We don't want to encourage people to opt out very often > John: We do have a mutual TLS option so there are more than one ways to achieve proof of possession > William: Authorization servers could say that access token binding is mandatory > > Brian: Should the scope include standardization of Token Binding for JWT Client Authentication for RFC 7523 > John: We should write this down because it's only self-evident how to do this to a very small set of people > Brian: We would write down how to use the cnf/tbh claim in the context of RFC 7523 > Hannes: Please write this down > > Brian: We need to remove the reference to the expiring resource metadata draft > Brian: I have ideas how to keep the intent but simplify > We would still describe how to detect and respond to attacks > > Brian: This is still early > Client library support is still sparse > We have things to learn from deployments > > Dick: Is pushing Token Binding through to the end-application after TLS termination in scope? > Brian: No, but the Token Binding WG just accepted a document about this > draft-campbell-tokbind-ttrp > Dick: This doesn't provide the same guarantees as other application-layer PoP mechanisms > Brian: This relies upon trust between the TLS terminator and the application > Brian: I don't know a way to tightly bind this end-to-end > Dick: The verification is happening at the application > Dick: I believe that Microsoft is encrypting the token > Dick: The problem is that the TLS terminator is in a different trust domain than the application > It's trusted to terminate TLS but not to manage the token or do authentication or authorization > Dick: What's being done in the Token Binding working group doesn't solve this problem > > John: I asked Tony Nadalin to provide information about this > Including the possible use of additional Token Bindings > Andrei Popov: I'm not familiar the higher-level functionality being referenced > If you're terminating TLS, that's where end-to-end ends for TLS functions, such as Token Binding > You're trusting that the TLS terminator is passing correct information to you > Hannes: We need to update our OAuth PoP documents > End-to-end PoP is definitely in scope for the OAuth WG > Dick: You didn't solve anything > Dirk Balfanz: It sounds like you already have a proof-of-possession implementation > Dick: We have a non-standard way in which Amazon API calls are made > There is a secret, you sign the request, and it's verified at the application level > Hannes: Is it HTTP signing? > Dick: Yes > It prevents a compromised TLS proxy from changing the request > Justin Richer: I did look at the Amazon spec when writing the OAuth HTTP signing spec > There were lots of problems with parameters being reordered, etc. in OAuth 1 implementations > Hannes: I would like Dick to look at the current OAuth HTTP signing spec > Maybe that will solve the issue that Dick is describing > Dick: That doesn't build on Token Binding > Justin: They are orthogonal > You could do both Token Binding and application-level PoP > Dick: What I like about Token Binding is that you don't have to do client-side management of a key > Token Binding lets you get many of the characteristics of PoP without client-side key management > Hannes: What are the right next steps for this issue? > Dick: I want Token Binding with end-to-end guarantees > Dick: Most of our deployments have TLS proxies > Brian: This isn't in scope for this document because the problem isn't specific to OAuth > Brian: This is also applicable to Token Bound cookies > The same issues occur for cookies > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
- [OAUTH-WG] OAuth Working Group Meeting at IETF 99… Mike Jones
- Re: [OAUTH-WG] OAuth Working Group Meeting at IET… Justin Richer