[OAUTH-WG] OAuth Working Group Meeting at IETF 99 21-Jul-17

[Mike Jones <[e-mail]>]

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