Re: [OAUTH-WG] draft-ietf-oauth-dpop-00 comments

[Brian Campbell <[e-mail]>]

Hi Mike,

Thanks for your interest in the work and review of the draft. As one of the
too-many authors on the document, I attempt to answer questions and respond
to comments inline below. Though I admit to not having necessarily adequate
answers to everything at the ready. And also apologize for the slow
response, which is somewhat related to not having necessarily adequate
answers.

On Wed, Apr 1, 2020 at 11:15 AM Peck, Michael A <[e-mail]> wrote:

> 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.
>

Yeah, there's definitely some room for improvement in this area. And you
are not the first to note the need. Complicating matters somewhat, however,
is that there's some disparity of opinions about the specifics of the
threat model and objectives. Despite that I do plan to work on trying to
expand and clarify the threat model, objectives, expected applicability,
etc. in the next revision of the draft.


> 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?
>

I'm hoping perhaps Daniel can help expand on this as the current text
originated with him. Although I think separate consideration of AS and RS
would be helpful because I think the factors involved in counterfeiting or
confusing them are pretty different.


> 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?
>

Probably, yeah. Although any JavaScript code that could exfiltrate tokens
could also likely be used to drive an attack directly. And that possibility
can devolve into questioning the value of key-binding or preventing
exfiltration at all (similarish criticisms have been levied at the HttpOnly
cookie flag and HTTP Token Binding). I'm sympathetic to that line of
reasoning to the point of finding it somewhat depressing. But I try and
avoid falling into full-blown XSS nihilism and (maybe stubbornly/naively)
still think there's some value in key constraining tokens. And, to your
point, a more detailed look at potential leakage/theft situations would be
useful.



>
> 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.


Yeah, an assumption (that admittedly should be made more explicit) is that
TLS/HTTPS with server authentication isn't broken.



> Why would the client send the refresh token to the wrong AS?
>

 Daniel maybe has some more ideas here but social engineering is the one
reason that I keep hearing. It's not super compelling but is a reason.



> 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.)
>

Audience restriction can work to prevent RS to RS token usage. But in
practice it has turned out that properly getting and using audience
restricted ATs is prohibitively cumbersome for many deployments.


>
> 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.
>

Keeping it relatively simple has definitely been a goal. And yeah, I can't
think of a practical way to do something like that without big changes. If
big changes are needed, the whole approach might be in question and
something like Neil's key agreement scheme that I mentioned in the last
interim
https://datatracker.ietf.org/meeting/interim-2020-oauth-02/session/oauth
could well be a better overall approach to consider.


> 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.
>

Some guidance would probably be useful.


>
> 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?
>

Trying to wrap my head around this and how it might happen but yes it would
seem that the kind of malicious JavaScript code (like XSS) that could
exfiltrate tokens or drive an attack directly could also pre-compute and
exfiltrate some DPoP proofs. I hadn't considered this and am honestly not
sure how problematic it is.


>
> 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.
>

That's an interesting consideration and along the lines (at least with
authorization code) of some of the conversations we had early on before the
first -00 draft was even written. And I've noticed that other signature
based proof concepts do typically propose having the signature cover the
access token (or hash thereof). Personally, I've gotten kind of attached to
the simplicity and consistency in the current draft of having the DPoP
proof be the same regardless of where it's presented. And I kind of cringe
at having to dig into the application layer to get at an authorization code
or refresh token value in order to verify the DPoP proof. Also considering
other grant types. So I don't want to move away from that too hastily.

But I suppose it depends on how much of a concern it is to ensure some
degree of freshness. And weighing that against the potential added
complexity of doing something like the above to try and get freshness. I'm
honestly not sure where I sit on it.


>
> 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?
>

A recommendation like that (new keypair per token request and subsequent
access token usage) probably makes sense. I think. In the case of a bound
refresh token issued to a public client, the lifetime of the keypair would
need to correlate with the refresh token (unless facilities are added to
enable dpop key rotation in that scenario).


>
> Thanks,
> Mike
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._