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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
