Support other method of HoK than TOKB

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2017-03-03

There are cases that you want to have other way of HoK than TOKB, e.g., In a platform that cannot support Token Binding, or when TLS is terminated before the OAuth server.

So, only HoK should be required and not TOKB. TOKB should be made into an option to support HoK.

---

Bitbucket status: closed

Bitbucket origin: issue 75

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2017-03-03

Re: #75

→ <<cset 43d7386>>

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2017-03-03

Suggested alternative HoK method.

Key Distribution

https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03

How to use it...

There is draft-ietf-oauth-signed-http-request but I think that's an overkill.
We just want to authenticate+authorize the client against resource endpoint.
So, something very short and sweet should be created.

In essence,

• Client either makes or gets nonce. Typically by hitting the resource, it gets a nonce in "401 Unauthorized" response. e.g.,

#!http

    HTTP/1.0 401 Unauthorized
    Server: HTTPd/0.9
    Date: Wed, 14 March 2015 09:26:53 GMT
    WWW-Authenticate: Named nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093"

• Client signs the nonce and put it in the Authorize header together with the access token. e.g.,

#!http
    GET /resource/1234 HTTP/1.0
    Host: server.example.com
    Authorization: Named at="access.token.jwt", s="jws.of.nonce"

[bitbucket-import-issues]

Originally submitted by ve7jtb (John Bradley) on 2017-03-03

Brian and I discussed this approach last year at the security workshop.

This would also require changes to the RS.

It is probably better than Justins proposal.

It would work with symetric or asymetric keys.

The thing we questioned was spec overload.
Will people do this, token binding (basically this but the nonce is the EKM) and mutual TLS?

[bitbucket-import-issues]

Originally submitted by SaschaZeGerman (Sascha Preibisch) on 2017-03-10

I think changes to the resource server are not too concerning. FAPI API's are new API's that have to be implemented anyways.

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2017-03-21

So, just to update, OAuth JPOP is available as

• https://bit.ly/oauth-jpop; and
• https://tools.ietf.org/html/draft-sakimura-oauth-jpop-01

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2017-03-21

Financial_API_WD_002.md Re: #75 . s/HOKTBD/JPOP\

→ <>

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2017-03-29

Reviewed JPOP in the Monday OAuth session.

There was a great desire to do only one way.

Subsequently, we had a design F2F meeting among people interested on Tuesday and came to the conclusion to
just go with x5t#s256 cnf method. This means we do not need Signature Method anymore.
Also, we will merge with X.509 client authentication draft so that developer needs to only read a single document.

Brian Campbell is working on it right now to be reviewed in Friday session.

Basically, what happens is the following:

1. the token endpoint gets the content of SSL_CLIENT_CERT, which is a PEM version of the client cert and convert it to DER and take sha256.
2. Associate it with the access token. (Format is proprietary to the authorization server and the resource)
3. Return the access token.
4. Then, the client just sends the access token like bearer token but over the client cert authenticated channel.
5. Upon receipt of it, the resource gets SSL_CLIENT_CERT and calculates x5t#s256 and compares it with the x5t#s256 that is associated with the access token.

The rationale for using x5t#sha256 are following:

We could have done it with SSL_CLIENT_M_SERIAL and SSL_CLIENT_I_DN but this will not be applicable when self issued certificates are to be used e.g., the mobile applications. x5t#s256 will be more robust.

ASK: Would we get a push back from OBS that we do not use DN?

[bitbucket-import-issues]

Originally submitted by ve7jtb (John Bradley) on 2017-03-29

We are still checking The DN at the AS.

They can still validate the cert in any way they like at the RS.

From a security point of view comparing the DN or a hash of the DN is equivalent. The hash of the cert is potentially more secure as it stops most of the validation errors at the RS.

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2017-04-04

MTLS draft will be going to be OAuth WG item.

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2017-04-04

We discussed on the call to update the reference to JPOP - to the new MA TLS draft:
https://www.ietf.org/id/draft-campbell-oauth-mtls-00.txt