[OAUTH-WG] Secdir last call review of draft-ietf-oauth-jwsreq-30

[Watson Ladd via Datatracker <[e-mail]>]

Reviewer: Watson Ladd
Review result: Serious Issues

I generated this review of this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving security requirements and
considerations in IETF drafts.  Comments not addressed in last call may be
included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

Two minor issues: On page 4, "This offers an additional degree of privacy
protection." should be reworded. I don't think it makes sense in context, where
authenticity was discussed.

It took me a while to understand what the by reference method is: maybe the
intro should say via URL instead of by reference.

And now for the thorny isssues with this draft. Signatures and encryption are
different. And encrypting a signed blob doesn't mean the signer encrypted it.
Then there are a plethora of methods specified in the draft  to authenticate
the blob, which will give different results in maliciously constructed
examples. The security considerations section should discuss what the encrypted
vs signed choices give in the way of security, and it doesn't. This makes me
worry.

Looking at the cited reference for attacks, I see the fix is to include
information about which IPD was used by the RP. But the draft before us doesn't
mandate that. It's not clear than how the cited attack is prevented by the
draft. Saying that the communication through the user-agent is subject to
manipulation, and this prevents it, ignores that the attacker in that position
sees a lot more. The user-agent as resource owner modifying the requested
resources is a very funny sort of attack: can't they do what they want with the
resources since they control the access?

Key management is ignored. This is a very important issue, especially
considering the potential problems with the reuse of JWT. I'd like to see a
recommendation that keys be separated by intended uses, rather than limiting
particular fields in an ad-hoc manner.

Then we have section 11. What section 11 introduces is an entire new dramatis
personae, the Trust Framework Provider, with no prior discussion of what it is
or a reference to where it is defined and a good number of statements about how
it works that aren't really  clear what they mean from the document to me.

My biggest concern is that these issues are signs that the problem this draft
is trying to solve and the mechanisms to solve it haven't been analyzed as
thoroughly as they should have been. Without that sort of thorough analysis
it's not certain that the mechanisms actually solve the problem and it's not
clear what the recommendations to implementors have to be to preserve those
properties.

Obviously this draft has had a long and tortured history with multiple reviews,
 and what I'm suggesting needs to happen is a lot of work. But it's essential
in any security protocol to do this analysis and be clear about what is, and
what is not, protected by the protocol.

Sincerely,
Watson Ladd