Minutes IETF99: oauth
minutes-99-oauth-01

OAuth minutes
=============

**** 13:30-15:30        Tuesday Afternoon session I ***

Scribe: Neil Jenkins

Last week there was an OAuth security workshop in Zurich. Info available
at https://zisc.ethz.ch/oauth-security-workshop-2017/

JWT Secured Authorization Request - now in IESG evaluation, comments
have been taken onboard. It's taken a while - some reasonably
substantial comments to deal with. An updated version of the spec will
be uploaded very soon.

## Mutual TLS Profile for OAuth 2.0.

Now in draft 2. Should not require major changes for implementation.
Hoping to go to working group last call soon. Approx 6 people in the
room have read the previous draft.

Comment: More algorithm agility needed; we should not hardcode use of
SHA-256. Answer: We can define new algorithms later with a new claim
name. Would need to register a new confirmation method under RFC7800.

Comment: An example would be good to show this in the spec. Will an
upstream registration be sufficient? If a new hash algorithm is defined
as a new confirmation method, it will flow down to JWT as well as
introspection.

Comment: Also how can the certificate be transmitted as part of this? It
can't at the moment. Answer: we decided to use the fingerprint because
we just want to be able to verify that the sender is in posession of the
certificate. The validation of the certificate is up to the TLS spec.

Comment: Did you consider using hash of public key info instead of whole
certificate? This is what's used in certificate pinning. This allows the
hash to stay the same if you reissue the cert, e.g. for a new expiration
date. Answer: the current solution seemed the most straight forward.
Didn't seem to big a burden to require clients to obtain new access
token if certificate reissued.

Comment: Short term certs (e.g. Let's encrypt) – you wouldn't want to
have to reissue access tokens that frequently. Counter-argument: access
tokens should be max 1h lifetime, so this should not be an issue.

Comment: Several assumptions have been stated. e.g. Tokens need to be
refreshed every 5min-1h. If draft is based on these assumptions, they
need to be in the spec.

Comment: In the JWS spec, where X5T is defined, it already gives an
example of how you would define one with new hashes. Can reference this
rather than repeating it. Don't define something just for the purpose of
defining it if it's never going to be used.

Conclusion: Doesn't seem to be too far fetched to go to WG last call
soon. Torsten will review. Justin will also be reading in depth. Paul
Grassi volunteered as well.

## Access tokens phishing

Mic drop. What a way to begin.

OAuth being used in context which is not web APIs. Assumptions in
original spec do not always hold.

Client wants to access RS via Standard API. Client is configured with RS
URL at runtime. This is a change to the OAuth trust model.

What if... The resource server is a bad guy? Could take the access
token and proxy through to the real resource server. The client would
never know.

What can we do? What if the client would know upfront which place is
save to send access tokens to? AS can return list of allowed resources.
But this puts the burden on client develops to keep secure. Since there
are more clients than servers, would be more robust to enforce at the
server level. Experience shows authors often get this wrong.

Can restrict access token to specific URL. Client has to ask for an
access token for a specific URL using the "audience" field. Could also
use the TLS certificate fingerprint. AS will refuse to issue token, or
even if it does it will not be valid when proxied to real RS.
Objections: AS may not know all the valid RSs. RS may be split across
multiple domains.

Comment: Issues with using cert: in a heavily distributed environment,
there may be a nunber of valid certs. Also cannot get cert from web
browser, so could not be used in web apps.

Proof of possession. Client obtains cert, signs request with cert and
includes the URL in the audience. Related to token binding/MTLS at
transport layer or signed request/jpop at application layer.

So... what should the BCP recommend?

Clarification: jpop refers to the application side of it. Comment: there
are use cases where access tokens are needed to be used with multiple
resource servers, and the URLs are not even known at time of issuance.
There also may be multiple certs.

Comment: different mechanisms have different threat models. One is about
stoping wrong receiver from getting token. But we are really worried
about the wrong client using the token. The more direct mechanism to
address this threat is the proof of possession.

Comment: Amazon is using audience restriction with URL.

Comment: Advantage of audience restriction is it doesn't require clients
to do new crypto, so is easier to implement.

Comment: there are benefits to indicating where you want to use the
access token (audience restriction); may return different access token.

Comment: deploying MTLS is a huge pain in the ass. Will probably only
happen for banks and other enterprise-level niche deployments. Token
binding very early days; remains to be seen if it will be widely
adopted. Application binding is really hard to get right, and be
interoperable.

Conclusion: Audience restriction seems to be the least worst option.
We will still pursue MTLS/Token Binding, but may not sufficient for
immediate needs. More discussion on the list needed.

## OAuth 2.0 Incremental Auth

Asking for access to everything up front is bad. Users should have
context of auth request. Better: the ability to request additional
scopes in subsequent requests resulting in a single grant representing
all scoopes granted so far.

Consent screen should only display new scopes. Single refresh token
issued for the union of all scopes. OAuth 2.0 does not stop this, so
many people have implemented this already for confidential clients.

Comment: why not sending refresh token with auth request? Will be
answered later.

Threat model: Mail client gets mail scope. Illigitemate app impersonates
other app. Requests other scope, gets both back.

Implementation details: existing grant must be valid in its own right.
Client ids must match.

Alternatives:
* Could also pass previous grant in the auth request. Can't do this
  because would be passing it in a GET request.
* Use access token as proof of existing grant. Drawback: more
  susceptible to attack.

Google's OAuth server already supports incremental auth for
public clients.

Comment: Second request asks for user to choose account. Is this
neccessary? Answer: no, we support openid connect, so can pass username
in second request.

Question: Do you detect if the user account is different between to
previous request? Yes, that needs to be validated too.

Comment: incrementally adding profiles over time means users may not
notice how much access the client is building up about them. Useful for
profiling; privacy concern. Answer: you could do this attack without
incremental auth, just by getting 10 separate tokens instead of 10
incremental ones. This just makes it more developer friendly.

Comment: it's not transparent to the end user that it is additive and
that revoking any one scope will now revoke all. (User may grant just
one extra access scope, but then want to remove just that scope.)
Answer: this is an implementation details.

Comment: better UI to show what's already been granted as well as what
extra is being requested.

Comment: The term "auth" is ambiguous in spec name.

Comment: Should indicate in the authentication request which instance of
the client is making the request, so you can revoke e.g. on your phone
but not your computer.

Demo code only available for iOS at the moment. A bit premature to do
call for adoption, but topic is in scope. More feedback needed.

Please read and review. Torsten, Nat, and John volunteered.

## JSON Web Tokens Best Current Practices

Early draft still. JWTs often depolyed insecurely, but are now being
used in many IETF protocols.

Please review and discuss content, particularly as it applies to your
use cases.

About 10 people in the room have read the document.

Comments: Definition of "typ" is toothless. Have you considered doing
something at the JOSE layer? Answer: concern not everyone is
implementing "critical" correctly. It's not clear this will be better.

Comment: new profile could define use of "typ" in such a way that use
against old profile would break without old profile having to know about
new profile. Will be taken to list.

Comment: are some of these points actionable real things? e.g.
compression. Or is it just FUD? Deprecating some profiles of RSA? We
should get expert review. It's bad news if you get stuff wrong: only
compress if you've carefully reviewed that this usage is safe.

Comment: PKCS 1/1.5 used TLS BCP to opinionate about algorithms, so it's
legit to do in this draft.

Should the work be adopted in this group? A clear "yes" consensus from
the room. If not already in the charter, will fix this soon.

Brian volunteered to review.

**** 9:30-11:30 Friday Morning session I ***

Scribe: Mike Jones

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