App Auth Q & A RFC 8292 BCP 212

App Auth RFC8292 BCP212 Q&A

Tuesday 1G

Convener: William D. & John

Notes-taker(s): Sarah Squire

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

Cookie theft and man-in-the-middle attacks are a big problem, and we'd like to solve them.

Currently token biding is implemented in Chrome, Edge, and IE. It's on by default in Redstone 2. Microsoft added it at the OS level, so IE inherited it because IE uses Windows' TCP.

Mozilla is looking at it.

Protocol flow:

User agent (UA) generates a key pair

SP is scoped by ETLD+1 (the top level domain and whatever string comes before that)

The UA key pair signs an HTTP header which sends mutually negotiated exported key material (EKM) to the SP, which can include the public key

SP creates a signed token with the public key of the device so you don't need to maintain the state at the server

Then when you receive a cookie that contains stuff that you signed, you can tell that it's not being replayed by a different browser.

This binding lasts until you remove the cookies for a particular site.

Question: When SP writes a cookie for the HTTP header, what is it signing?

Answer: It's signing the cookie, and putting the opaque value of the public key in the cookie

In the case of an IdP and RP using an OAuth flow, an RP can ask the user agent to provide its token binding ID to the IdP. In that case, the UA would sign over the EKM using both the IdP's token binding ID and the RP's token binding ID. Then it can create a token with proof-of-possession (a token that is only considered valid if it is presented by someone who can prove they have control of the private key associated with the public key in the token).

In the case of FIDO, the FIDO challenge response would include the token binding ID. The FIDO authentication server can then verify that it's using the right TLS channel and initiate a proof-of-possession challenge.

Q: Can you do it withe a PIV card?

A: No, all you get with that is mutual TLS to the user agent.

There are flaws in channel ID. Channel ID uses exported key material, so it's vulnerable to a number of TLS attacks. The FIDO specs still say channel binding, but they are subject to whatever the browser supports, so effectively, they're using the EKM flow.

Token binding is in the last stages of review before it becomes and RFC in the IETF.

Q: What about network hardware implementations?

A: Nginx and Facebook have implemented it. Layer 7 working on it. There is an apache module. There are complexities with Java that Oracle hasn't fixed. Java doesn't implement the latest version of TLS. You can implement it through a reverse proxy, and the working group is working on a standard for that. If you're doing load balancing, you have to do that anyway because that's where it terminates.