Having an audience is an important part of keeping the assertions from being reused inappropriately.
I think the difference between this and PKIX is that a certificate references a private key so is in a sense only usable by the holder of that key. If we were talking about holder of key /Proof of Possession JWT and SAML assertions then perhaps there is a corner case for not specifying an audience. Using bearer assertions, I don't think the hypothetical flexibility gain is worth the inevitable security issues caused by not having an issuer, and people, not understanding the consequences of that. John B. On Oct 16, 2014, at 12:39 PM, Richard Barnes <[email protected]> wrote: > On Thu, Oct 16, 2014 at 8:29 AM, Mike Jones <[email protected]> > wrote: > 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. > > That all assumes that the issuer of the assertion intends to limit it to a > specific authorization server. That is not the case with many assertion > systems today, e.g., PKIX. > > > > 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. > > That's dramatically overstating things. The only security bet that is off in > that case is that the assertion is not limited to one authorization server. > Which may or may not be the issuer's intent. > > The only thing I could see justifying this requirement is something in the > overall OAuth architecture that requires authorizations to be scoped to a > specific authorization server. If that exists, add a citation and I'll > clear. Otherwise, this needs to be un-MUST-ed. > > --Richard > > > > > > ---------------------------------------------------------------------- > > 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
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
