Last Call Review of draft-ietf-oauth-jwsreq-30

Request Review of draft-ietf-oauth-jwsreq
Requested rev. no specific revision (document currently at 30)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-10-02
Requested 2020-09-18
Requested by Roman Danyliw
Authors Nat Sakimura, John Bradley, Michael Jones
Draft last updated 2020-09-25
Completed reviews Opsdir Telechat review of -09 by Warren Kumari (diff)
Secdir Telechat review of -09 by Stephen Kent (diff)
Genart Telechat review of -09 by Joel Halpern (diff)
Opsdir Last Call review of -11 by Warren Kumari (diff)
Secdir Last Call review of -11 by Stephen Kent (diff)
Genart Last Call review of -11 by Joel Halpern (diff)
Secdir Last Call review of -30 by Watson Ladd
Genart Last Call review of -30 by Joel Halpern
Assignment Reviewer Watson Ladd 
State Completed
Review review-ietf-oauth-jwsreq-30-secdir-lc-ladd-2020-09-25
Posted at
Reviewed rev. 30
Review result Serious Issues
Review completed: 2020-09-25


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.

Watson Ladd