There seems two prevailing approaches: 1. The AS generates a symmetric key and encrypts it to a specific audience as part of/associated with the access token (KDC-type model). 2. The client attempts asymmetric use, and the resource server negotiates a symmetric key specific to it.
The first model has advantages in terms of potentially eliminating all API-level symmetric crypto and of simplifying/optimizing the first client/resource interaction. The second model has an advantage of being an extension of the asymmetric model, leaving the AS out of a non-authorization requirement of the resource server, and amortizes the cost of the crypto over the lifetime of the authorization (since the negotiated key can be reused with the next access token). The audience target for the token is no longer restricted by the shared secret, since you can negotiate a separate symmetric key per resource server. The first access of a resource does however have an extra round-trip. The first model has a single shared secret between the AS and RS, which would need to be somehow negotiated. The private key in the second model can create issues where a resource server is actually a distributed system like a CDN - draft-ietf-tls-subcerts is an effort to try to make that more robust in the TLS space. The second model's protocol may wind up using a ’service ticket’ style sharing of a symmetric key so that each RS node does not have to do their own challenge and key derivation on first communication, and to lighten the need for caching. Both systems wind up adding complexity around key rotation. The first model can report an issue with key rotation by using a 401 to trigger a refresh of the access token - the AS would know in this case the RS has a new symmetric key and take that into account with the new access token. The second model would trigger a renegotiation on the RS itself. Finally, it is worth considering that some secure elements (such as on iOS devices) do not expose support for symmetric keys, and SubtleCrypto in browsers will likely require any symmetric key to be imported such that the key itself exists in the Javascript sandbox unencrypted, at least for some period of time. Use of symmetric keys thus increases the risk of exfiltration, so the time between refreshes (or the access token lifetime in environments without refresh tokens) may be reduced in consideration. Under this reduced lifetime, amortization of asymmetric crypto may have less of an effect. -DW > On Nov 21, 2019, at 3:07 AM, Dick Hardt <dick.ha...@gmail.com> wrote: > > One take away I had from the meeting today, and form the mail list, is the > concern of doing asymmetric crypto on API calls. How about if we use the > Client's public key to encrypt a symmetric key and pass that back to the > Client in the token request response? > > EG: > > In response to the token request, the AS additionally returns a derived > symmetric key (SK) encrypted in a JWE using the Client's public key from the > DPoP Proof. > > The SK = hash( salt, R ) > > R and the salt version V are included in the access token > > The AS and the RS share salts with versions. > > The Client decrypts the JWE and now has a symmetric key to sign a Symmetric > DPoP Proof. > > The RS take R and V to calculate SK, and verify the signature of the > Symmetric DPoP > > Here is an updated flow: > > +--------+ +---------------+ > | |--(A)-- Token Request ------------------->| | > | Client | (DPoP Proof) | Authorization | > | | | Server | > | |<-(B)-- DPoP-bound Access Token ----------| | > | | (token_type=DPoP) +---------------+ > | | PoP Refresh Token for public clients > | | Symmetric Key JWE > > Client decrypts DPoP Symmetric Key > > | | > | | +---------------+ > | |--(C)-- DPoP-bound Access Token --------->| | > | | (Symmetric DPoP Proof) | Resource | > | | | Server | > | |<-(D)-- Protected Resource ---------------| | > | | +---------------+ > +--------+ > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
