Channel Binding for Open ID Connect

Session Topic: Channel Binding for Open ID Connect

Wednesday 2G

Convener: Mike Jones/Breno

Notes-taker(s): Roshni Chandras

Tags for the session - technology discussed/ideas considered: OpenID Connect, Channel ID, Channel Binding

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

TLS Mutual authentication

• end-user auth technology
• certificate for user identity
• no relationship to server user authentication
• should involve user content

Because of these assumptions, it is not practical for user-facing actions, but is now used in server-server communication -- this works well in a closed environment where you control large parts of the stack.

TLS Channel Binding

Authenticate device (context) rather than the user

- public keys / no trust chain requirement

- no steps by the user for provisioning since your machine can now autogenerate a binding.

- isolation of which keys are used to communicate with each server based on same-origin policy

The same privacy model that browsers currently have in place for cookies will work well for keys/TLS Channel IDs

Side-note:

TLS Raw Public Keys

- public keys / not bound to the same origin

- bound to access token or some other oauth construct

- uses same container TLS uses for certificates (certificate pay-load container)

(No need to define a separate field in TLS)

- but doesn’t solve the problem of certificate hinting

Back to TLS Channel Binding:

TLS Session Resumption

another feature of TLS Channel IDs.

- server recognizes when it sees the device again

- provides the ability to manage sessions ~ cookie memcache infrastructure

TLS Channel ID

- automatically managed by TLS infrastructure

(if we rekey the same cert, this breaks - requires reauth, WAI)

You can now bind artifacts to this context.

Application layer code on both sides of the connection are able to inspect Channel ID and use it in protocol messages (signed or encrypted) - the recipient pulls out the channel ID and ties application layer state to a particular channel setup so that if the message arrives on the wrong channel, it can be tossed (example, capture and replay)

The channel ID can be used in application/protocol state - the server could create an integrity protected cookie with channel ID in it. If the cookie leaks, this context cannot be reused.

Q. Can you clear cookies and keys separately?

Yes, but you’ll need new cookies if you reset keys.

You can use channel binding without protocol support if UA supports Channel IDs and the client and Authzn server have the same origin. If they do not, we need protocol support.

IETF Cross Certifying Channels

secure and ID token E2E from an OpenID provider or Oauth server.

Refer to diagram:

Naive method:

Put channel ID available to browser and the server in the ID token. Won’t work. Client compares channel ID received to the one used and they don’t match.

However, there is an authoritative party that knows both channel IDs - the browser, where the communication is moving through, typically by a redirect, is in possession of the private key material for both channels.

So, we create a message containing each channel ID signed using the other channel ID. Having both signatures is the cryptographic proof that the same party holds the information for both channels.

If the 302 redirect to the client had a flag that said “please emit channel pari proof as a param, possibly in an HTTP header to the client”, the client would then look in the ID token, see the channel ID (ch1) and look in the header -- “do I have proof that ch1 is paired with ch2 (my channel ID)?” and accepts the ID token as coming from 2 channels transiting the same device.

The TLS channel binding is not aware of user consent to give information to the server, since channel binding should be independent of the application. The browser also does not need to know what is being protected by the channel ID, therefore, we can’t use raw public keys alone.

Q. Is it sufficient to include Channel ID (ch2) in the request to the server?

A. This still allows MITM attacks, diminishing the value of the channel binding. It also does not provide E2E proof.

Q. What about browsers talking to an app on a phone?

Open Q with room for discussion:

How do we extend this exercise to the code flow?

There’d be a 3rd channel ID. Handling the client-browser-server issue is harder to solve and the expectation is that the code flow won’t be as hard.

Note about the 302 redirect and cross-certification:

The 302 redirect is one of 3 mechanisms in modern browsers that cause cross-domain communication in a controlled manner

- location reference from one origin causes a message to be sent to a different origin

- there are limited ways to do this, and at the same time as the cross-origin communication is occurring, with the consent of the parties involved, you can cross- certify the channel IDs.

However, there are two other mechanisms: POST message and CORS. If we have a cross-certification mechanism, both W3C and the browser community will want it to be applicable to all 3 cross-domain communication mechanisms.