Thanks for your review, Richard. I'm replying to your DISCUSS about the
audience being required below...
-- Mike
> -----Original Message-----
> From: OAuth [mailto:[email protected]] On Behalf Of Richard Barnes
> Sent: Wednesday, October 15, 2014 8:48 PM
> To: The IESG
> Cc: [email protected]; [email protected];
> [email protected]
> Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17:
> (with DISCUSS and COMMENT)
>
> Richard Barnes has entered the following ballot position for
> draft-ietf-oauth-assertions-17: Discuss
>
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> "The assertion MUST contain an Audience that identifies the Authorization
> Server as the intended audience. Assertions that do not identify the
> Authorization Server as an intended audience MUST be rejected."
>
> Could you please identify the threat model within which this "MUST" is
> required?
> This requirement doesn't follow from any of the threats elaborated in Section
> 8.
Sure, this is to prevent a legitimate assertion intended for one authorization
server being captured by the attacker and sent to a different authorization
server. Unless there's an audience for the authorization server to check,
there's no way for the authorization server to reject assertions intended to be
used by a different server. Using the audience is the normal way to prevent
this attack.
> The Audience is only necessary if the Issuer wishes to constrain the set of
> Authorization Servers with which an assertion may be used. So ISTM that this
> should be "MAY contain..."
Constraining the set to the intended server is basic to the security
guarantees. If I can take a server intended for server1 and get server2 to
accept it, all security bets are off.
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> "keyed message digest" -> "Message Authentication Code"
>
> That's the proper terminology [RFC4949], especially since there are MACs that
> are not based on digests.
>
> "This mechanism provides additional security properties." -- Please delete
> this or
> elaborate on what security properties it provides.
>
> Section 8.2 should note that "Holder-of-Key Assertions" are also a mitigation
> for
> this risk.
>
>
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
