Thanks for your review, Richard. I'm replying to your DISCUSS about the audience being required below...
-- Mike > -----Original Message----- > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richard Barnes > Sent: Wednesday, October 15, 2014 8:48 PM > To: The IESG > Cc: draft-ietf-oauth-asserti...@tools.ietf.org; oauth-cha...@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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth