Hi, Glad to see DPoP moving forward as a working group item. I have a couple of comments on the current draft:
1. I recommend expanding the description of the threat model. It's not entirely clear to me what threats DPoP is expected to address, which makes it hard to evaluate whether DPoP meets its objectives. Section 2 states that the main objective is to prevent an adversary who set up a counterfeit AS or RS from replaying a received refresh token or access token at another server. Would it be possible to expand upon the description of this threat and how it may occur? Are there other situations where an adversary may be able to capture a refresh token or access token that should be mentioned as objectives to address - e.g. malicious / third-party JavaScript code? Presumably the counterfeit AS or RS will not have the same hostname (e.g. with an illegitimately issued server certificate) as the legitimate server, as otherwise DPoP wouldn’t provide protection. Why would the client send the refresh token to the wrong AS? For resource servers, why wouldn’t an access token audience restriction suffice? Is the concern that the access token might not contain an audience restriction, or might contain multiple audiences? (If the concern is that the resource server wouldn’t check the audience, I’d have a similar concern that it wouldn’t check a DPoP proof.) 2. DPoP currently does not provide any guarantees that the DPoP signature was freshly generated, as there is no nonce from the server incorporated into the signature. I assume there is no practical means for the server to send a nonce to the client to use with each request that wouldn't over-complicate DPoP. I also don't see any guidance in the draft about lifetime/rotation of each DPoP key or whether the same key can be used with multiple servers. My concern is that something analogous to this Kerberos PKINIT attack - https://mailarchive.ietf.org/arch/msg/krb-wg/pLgID35fNG1Zh_QJjgXH9vEbwoQ/ - could occur if DPoP signatures can be pre-computed by an adversary that somehow gains the ability to compute signatures with the private key but doesn't gain access to the private key itself. Could that potentially happen with malicious JavaScript code? The iat timestamp is insufficient since future values could be inputted with the signatures stored for later use. I could envision a private key potentially being re-used for a long period of time, and depending on how DPoP ends up getting used in practice, a private key being used with multiple servers? If guaranteeing some degree of freshness of the signature is a concern, one solution could be to incorporate the authorization code into the DPoP signature for token requests to the AS with grant_type=authorization_code, incorporate the refresh token into the DPoP signature for token requests to the AS with grant_type=refresh_token, and incorporate the access token into the DPoP signature for requests to a resource server. That would prevent pre-computing DPoP signatures before the authorization code / refresh token / access token is generated by the AS, as long as the recipient properly checks the DPoP proof. I'd also suggest adding guidance on rotating the DPoP key - e.g. mandate/recommend that the client create a new keypair for each token request? Thanks, Mike _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
