Minutes IETF99: oauth
minutes-99-oauth-00

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

<<TBD: insert here>>