Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

Thanks for your review, Richard.  I'm replying to your DISCUSS about the audience being required below...

				-- Mike

> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard Barnes
> Sent: Wednesday, October 15, 2014 8:48 PM
> To: The IESG
> Cc: draft-ietf-oauth-assertions@tools.ietf.org; oauth-chairs@tools.ietf.org;
> oauth@ietf.org
> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth