Daniel Fett and David Waite (DW) hosted a great session on OAuth 2.0
Demonstration of Proof-of-Possession at the Application Layer
(DPoP)<https://tools.ietf.org/html/draft-ietf-oauth-dpop-00> at the virtualized
IIW<https://internetidentityworkshop.com/> this week. Attendees also included
Vittorio Bertocci, Justin Richer, Dmitri Zagidulin, and Tim Cappalli.
After Daniel and DW finished doing their overview of DPoP, I used some of the
time to discuss feedback on DPoP from Microsoft Azure Active Directory (AAD)
engineers. We discussed:
* How do we know if the resource server supports DPoP? One suggestion was
to use a 401 WWW-Authenticate response from the RS. We learned at IIW that
some are already doing this. People opposed trying to do Resource Metadata for
this purpose alone. However, they were supportive of defining AS Metadata to
declare support for DPoP and Registration Metadata to declare support for DPoP.
This might declare the supported token_type values.
* How do we know what DPoP signing algorithms are supported? This could be
done via AS Metadata and possibly Registration Metadata. People were also in
favor of having a default algorithm - probably ES256. Knowing this is
important to preventing downgrade attacks.
* Can we have server nonces? A server nonce is a value provided by the
server (RS or AS) to be signed as part of the PoP proof. People agreed that
having a server nonce would add additional security. It turns out that Dmitri
is already doing this, providing the nonce as a WWW-Authenticate challenge
value.
* Difficulties with jti at scale. Trying to prevent replay with jti is
problematic for large-scale deployments. Doing duplicate detection across
replicas requires ACID consistency, which is too expensive to be
cost-effective. Instead, large-scale implementations often use short timeouts
to limit replay, rather performing reliable duplicate detection.
* Is the DPoP signature really needed when requesting a bound token? It
seems like the worst that could happen would be to create a token bound to a
key you don't control, which you couldn't use. Daniel expressed concern about
this enabling substitution attacks.
* It seems like the spec requires the same token_type for both access
tokens and refresh tokens. Whereas it would be useful to be able to have DPoP
refresh tokens and Bearer access tokens as a transition step. Justin pointed
out that the OAuth 2 protocol only has one token_type value - not separate ones
for the refresh token and access token. People agreed that this deserves
consideration.
* Symmetric keys are significantly more efficient than asymmetric keys. In
discussions between John Bradley, Brian Campbell, and Mike Jones at IETF 106,
John worked out how to deliver the symmetric key to the Token Endpoint without
an extra round trip, however it would likely be more complicated to deliver it
to the resource without an extra round trip. At past IETFs, both Amazon and
Okta have also advocated for symmetric key support.
* What are the problems resulting from PoP key reuse? The spec assumes
that a client will use the same PoP key for singing multiple token requests,
both for access token and refresh token requests. Is this a security issue?
Daniel responded that key reuse is typically only a problem when the same key
is used for different algorithms or in different application contexts, when
this reuse enables substitution attacks. It's also the case that clients can
choose to use different PoP keys whenever they choose to.
* Could access tokens be signed? Having the DPoP key hash in the access
token is equivalent if the access token is integrity protected. But people
said that many deployments don't use structured access tokens in which the key
hash can be included. For instance, Ping Identity uses access tokens that are
just database indexes. Would access token signing be needed then?
* Why aren't query parameters signed? Daniel said that canonicalization of
query parameters that use different URL escape syntaxes for representations of
the same characters would likely result in interop problems. People said that
while SOAP deployments might have many logical endpoints differentiated only by
query parameters, that's no longer the normal pattern for REST systems.
Thanks for the great discussion!
-- Mike
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
