clock sync and FAPI2 baseline

[Dave Tonge]

We have agreed to leave the DPoP nonce in the spec, partly because of clock sync issues.

However do we need to consider other parts of the spec, for example:

1. private_key_jwt - exp is required and iat is optional. A naive implementation of a client would probably set the exp as the current system time + 30 seconds. If the clock was set in the past this would cause a failure. If the clock was set in the future and iat was in the assertion then there would be a failure
2. TLS certificates - there could be failures if an out of sync system clock was set past the expiry date of a valid certificate

I don’t think there is much we can do about TLS certificates, but private_key_jwt may be an issue.

Looking at https://www.rfc-editor.org/rfc/rfc7523.html the relevant clauses are:

The JWT MUST contain an "exp" (expiration time) claim that
limits the time window during which the JWT can be used.  The
authorization server MUST reject any JWT with an expiration time
that has passed, subject to allowable clock skew between
systems.  Note that the authorization server may reject JWTs
with an "exp" claim value that is unreasonably far in the
future.

The JWT MAY contain an "nbf" (not before) claim that identifies
the time before which the token MUST NOT be accepted for
processing.

The JWT MAY contain an "iat" (issued at) claim that identifies
the time at which the JWT was issued.  Note that the
authorization server may reject JWTs with an "iat" claim value
that is unreasonably far in the past.

Do we need some clause in FAPI that relaxes those processing rules if private_key_jwt is used in conjunction with DPoP and server nonces?

‌

‌

‌

[Jacob Ideskog]

This is indeed something that should be addressed in the the FAPI spec.

The private_key_jwt has the JTI mechanism in the spec:

Section 3 bullet 7

The JWT MAY contain a "jti" (JWT ID) claim that provides a
unique identifier for the token.  The authorization server MAY
ensure that JWTs are not replayed by maintaining the set of used
"jti" values for the length of time for which the JWT would be
considered valid based on the applicable "exp" instant.

‌

Options

If a large +/- skew is accepted in the server, the JTI should be enforced to be unique and not seen during a reasonable period, which in this case would most likely be days.

So we could refine bullet 7 to something like this

For mobile clients a larger than normal clock skew may be required (hours to a few days).
If this is to be allowed by the AS, the JWT MUST contain a `jti` (JWT ID) claim that provides
a unique identifier for the token. For replay protection the authorization server 
MUST maintain a set of `jti` values it has seen during the skew window and reject any 
assertion with the same `jti`.

‌

This however does not protect against the scenario when someone intercepts and stops an assertion JWT being sent to the server, and use it later. Since the window of usage is larger other mechanisms would be required.

---

Another option would be to introduce a challenge similar to what was used in DPoP. This would break away more from the original spec, and impose changes on the client side which may not be acceptable.
Example

1. Client sends assertion JWT that has an invalid exp or iat (or nbf)
2. Server rejects the JWT but returns an error saying use_nonce
3. the client re-generates the JWT with the nonce included
4. Server accepts it even with exp and iat being off.

I.e. the nonce is not required, but required if the iat and exp should be ignored.

I think this feels like a new spec rather than a FAPI profiling of the current spec.

---

A third would be to use the HTTP Date header. When the server responds with an error based on invalid credentials, it should always respond with the HTTP Date header.

The client should use that to offset its clock, and re-generate a new client assertion based on the new time.

This puts some more burden on the client, but it uses existing mechanisms.

This introduces the risk that if the server is in the hands of an attacker, then it can use the Date header to get the client to generate JWTs in the future. We can’t think of other cases than man in the middle here, since TLS is in play and the aud claim should point to the server.

---

Regarding TLS, I agree there is not much that can be done, but I think the issue is much smaller since the certificates are usually more long lived than a client assertion jwt, and the TLS protocol already ensures that the client has access to the private key at the time the handshake is being performed.

‌

[Dave Tonge]

We discussed and agreed that the http date header could work well.

Joseph also made the point that this doesn’t prevent the pre-generation of private_key_jwt assertions and that we should call that out

[Nat Sakimura]

So, Dave, are you coming up with some text for this or should we ask someone to create it?

[Dave Tonge]

Yes, I will come up with some text

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/346/add-text-to-deal-with-private_key_jwt

[Dave Tonge]

PR merged