Hi Yoav,
https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-09 has been
published, which addresses your review comments in the ways proposed below.
Thanks again for your review!
-- Mike
From: Mike Jones
Sent: Wednesday, October 16, 2019 1:21 PM
To: Yoav Nir <ynir.i...@gmail.com>; sec...@ietf.org
Cc: draft-ietf-ace-cwt-proof-of-possession....@ietf.org; i...@ietf.org;
ace@ietf.org
Subject: RE: Secdir last call review of
draft-ietf-ace-cwt-proof-of-possession-08
Thanks a lot for your review, Yoav. Replies are inline, prefixed by “Mike>”…
-----Original Message-----
From: Yoav Nir via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>>
Sent: Sunday, October 6, 2019 11:52 AM
To: sec...@ietf.org<mailto:sec...@ietf.org>
Cc:
draft-ietf-ace-cwt-proof-of-possession....@ietf.org<mailto:draft-ietf-ace-cwt-proof-of-possession....@ietf.org>;
i...@ietf.org<mailto:i...@ietf.org>; ace@ietf.org<mailto:ace@ietf.org>
Subject: Secdir last call review of draft-ietf-ace-cwt-proof-of-possession-08
Reviewer: Yoav Nir
Review result: Has Nits
I have reviewed 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 primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.
I think the document shows that security aspects have been considered and
handled well. However, the document has issues with clarity and readability:
For starters, the Abstract and Introduction are nearly identical. The
Introduction could instead be used to explain the domain, who the "players" are
and what they are trying to accomplish. Instead, section 2 introduces the terms
Issuer, Presenter and Recipient with definitions that sound like the CA, the
End Entity and the Relying Party from PKI, with a little OAuth terminology
mixed in. There is no explanation about who this issuer is, and what the trust
model is.
Mike> This document structure is intentionally parallel to RFC 7800. In
particular, the Terminology section is there specifically to introduce the
players. Yes, editorially, this could have been done in the Introduction, but
this is the style typically used by OAuth, JOSE, COSE, and ACE specifications.
I’m reluctant to deviate from it in this particular specification unless
there’s a compelling reason to do so.
Mike> Who the issuer is is discussed in the last paragraph of Section 3. The
trust model is described in the last paragraph of Section 4 (Security
Considerations).
Mike> Therefore, unless there is a specific change that you want to suggest, I
propose to leave the Introduction and Terminology sections as is.
The Security Considerations section also has some problems. Quoting the second
paragraph:
Applications utilizing proof of possession SHOULD also utilize
audience restriction, as described in Section 3.1.3 of [CWT], as it
provides additional protections. Audience restriction can be used by
recipients to reject messages intended for different recipients.
Why? Why is the aud claim needed with a cnf claim (but not in other cases)?
Neither this document nor RFC 8392 provides insight as to when aud is
appropriate. That they allow recipients to reject messages not intended for
them does not sound like a security feature.
Mike> Having an audience in a token is a security feature, as it prevents a
legitimate token intended for one recipient from being replayed to gain access
at a different recipient. You’re right that this is useful/required in many
situations even when “cnf” isn’t being used. However, reviewers of drafts of
what became RFC 7800 wanted this text added to remind people that audience
restriction is often useful even when you have proof of possession, as it
defends against different threats.
Mike> To make this clearer, I propose to add this parenthetical remark at the
end of this paragraph: “(Of course, applications not using proof of possession
can also benefit from using audience restriction to reject messages intended
for different recipients.)” If you’d prefer different wording, please let me
know what it is.
Paragraph 3 says: "A recipient might not understand the "cnf" claim." This
re-affirms that we need an explanation of who the parties to this protocol are.
We generally don't send messages to recipients that don't understand them. Is
this a closed system with known entities, or is this a protocol where the
parties contact random other parties on the Internet?
Mike> Per my response to the Genart review, we’re already proposing to delete
this paragraph, as it’s not actionable. Note that the requirement to ignore
not-understood claims comes from Section 3 of RFC 8392 (which also was
inherited from RFC 7519), and so is not unique to this specification.
Mike> The exact parties to the protocol are dependent upon the application, as
discussed in the last paragraph of Section 4. This specification is defining
PoP key representations. It’s intentionally leaving the messages conveying
CWTs with “cnf” claims up to the applications using them. Again, this is
intentionally exactly parallel to RFC 7800.
I'd also lose some of the Introduction to Crypto in the second-to-last
paragraph.
Mike> I agree that this is overly pedantic. I propose to delete the
parenthetical “e.g.” clause at the end, which will make it once again exactly
parallel to the corresponding text in RFC 7800. Let me know if you’d a
specific further change to this paragraph.
Thanks,
-- Mike
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
