[Openid-specs-ab] Issue #1161: Key rotation should require a delay between publishing a key and starting to use it? (openid/connect)

Filip Skokan panva.ip at gmail.com
Mon Mar 23 08:54:59 UTC 2020


Gentlemen,

while this discussion is great (and very much rehashes a jose WG threat
from many years ago I came across a few weeks ago), it's not relevant for
what Joseph is trying to get to the bottom of.

Let me try a different angle,

In the certification suite, as part of the dynamic profile we have a
mandatory test `OP-Rotation-RP-Sig` in which the RP requests an access
token from the tested OP, then changes its signing key and requests another
access token.

This test is implemented with a set of mechanisms that in itself aren't
required for the profile (private_key_jwt client authentication and refresh
token exchange).

While searching for a new way of testing this mechanism (which seems to be
using request object signatures rather than client auth) Joseph looked at
existing certified solutions' logs only to realise the suite has been
passing them altho they've been failing the exchange that tests the
rotation.

The reason why e.g. my own implementation would always fail this test is
that it is trying to prevent an undocumented DoS by limiting the rate at
which it is willing to go fetch the client's jwks_uri over the wire.

OIDC Core 10.1.1 Rotation of Asymmetric Signing Keys
<https://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys>
suggests that

The signer can begin using a new key at its discretion and signals the
> change to the verifier using the kid value.


This in itself is valid and fine, until there's a new `kid` for every
request. Making the OP hit the RP's jwks_uri on every e.g. authorization
request with a request object. A malicious actor may forge an
authentication request with a request object with a random `kid` value,
this would result in the OP making countless trips to the RP's jwks_uri. A
disaster waiting to happen. A throttle mechanism in place can be e.g. that
the OP will only fetch the jwks_uri upon the new `kid` signal if it already
didn't do so less than a minute ago.

It's because a mechanism like this, which we agreed makes sense, that we
cannot devise a test that we could ensure all implementers can pass.

So the WG questions

   1. should we do something about that language to suggest that signature
   recipients may omit fetching external jwks_uri resources if they already
   did so recently?
   2. should we extend the attestation statement
   <https://openid.net/wordpress-content/uploads/2015/04/OpenID-Certification-Attestation-Statement.pdf>
to
   allow for other rotation tests to be attested to allow implementers to have
   mechanisms that protect their infrastructure.


Best,
*Filip*


On Mon, 23 Mar 2020 at 08:08, Tom Jones via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Just add the exp. With the understanding that exp MUST mean - not valid
> for signing or encryption.  Validation and decryption can occur at any
> time, but validation should also consider the iat of the doc signed. That
> should be less than the exp of the key.
>
> thx ..Tom (mobile)
>
> On Sun, Mar 22, 2020, 10:49 AM Torsten Lodderstedt <
> torsten at lodderstedt.net> wrote:
>
>> You are right. The problem with JWKS_URI as far as I understand is, there
>> is no lifecycle status indication in the sense the OP could leave the key
>> in the list but deactivate it or valid from/to time fields. This kind of
>> information  could be added by using X.509 certs, which is rather untypical
>> in the OIDC space.
>>
>> > On 22. Mar 2020, at 18:35, Tom Jones via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> wrote:
>> >
>> > this is not good advice. A signing key may need to be used for
>> validation for may years after the signing occurs. The signing key MUST be
>> retained for a period of time that corresponds to the effective life of the
>> document signed.  Encryption keys are different in that the lifetime of the
>> decryption of the object may be different than the time frame when a
>> document needs to be validated and is entirely an internal function. The
>> public key used for encryption can be changed at any time and the only one
>> retired IN THE PUBLIC KEY CERTIFICATE.
>> > Peace ..tom
>> >
>> >
>> > On Sun, Mar 22, 2020 at 9:28 AM josephheenan via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> wrote:
>> > New issue 1161: Key rotation should require a delay between publishing
>> a key and starting to use it?
>> >
>> https://bitbucket.org/openid/connect/issues/1161/key-rotation-should-require-a-delay
>> >
>> > Joseph Heenan:
>> >
>> > [
>> https://openid.net/specs/openid-connect-core-1\_0.html#RotateSigKeys](https://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys)
>> says:
>> >
>> > > Rotation of signing keys can be accomplished with the following
>> approach. The signer publishes its keys in a JWK Set at its `jwks_uri`
>> location and includes the `kid` of the signing key in the JOSE Header of
>> each message to indicate to the verifier which key is to be used to
>> validate the signature. Keys can be rolled over by periodically adding new
>> keys to the JWK Set at the `jwks_uri`location. The signer can begin using a
>> new key at its discretion and signals the change to the verifier using the
>> `kid` value. The verifier knows to go back to the `jwks_uri` location to
>> re-retrieve the keys when it sees an unfamiliar `kid` value. The JWK Set
>> document at the `jwks_uri` SHOULD retain recently decommissioned signing
>> keys for a reasonable period of time to facilitate a smooth transition.
>> >
>> > ‌
>> >
>> > The “signer can begin using a new key at its discretion” seems
>> potentially problematic - discussion within the certification \(around a
>> test intended to test RPs rotating keys, see [
>> https://www.heenan.me.uk/~joseph/oidcc\_test\_desc-phase1.html#OP\_Rotation\_RP\_Sig](https://www.heenan.me.uk/~joseph/oidcc_test_desc-phase1.html#OP_Rotation_RP_Sig)
>> \) revealed that OPs in larger distributed deployments will in some cases
>> not react immediately to keys being added and a new kid being found. For
>> example to prevent a DoS attack an OP may well decide not to refetch a JWKS
>> it has fetched in the last 60 seconds.
>> >
>> > I would suggest tweaking the text so that “The signer can begin using a
>> new key at its discretion” becomes something like “The signer should wait
>> at least a few minutes after it publishes the new key and then can begin
>> using a new key at its discretion”
>> >
>> > ‌
>> >
>> >
>> > _______________________________________________
>> > Openid-specs-ab mailing list
>> > Openid-specs-ab at lists.openid.net
>> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> > _______________________________________________
>> > Openid-specs-ab mailing list
>> > Openid-specs-ab at lists.openid.net
>> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20200323/ee0146c1/attachment-0001.html>


More information about the Openid-specs-ab mailing list