It is also important for a non-protocol purpose. Liability. If a 3rd party uses an assertion that was not intended for it, it cannot obviously hold the asserting party responsible.
Phil @independentid www.independentid.com phil.h...@oracle.com On Oct 16, 2014, at 8:43 AM, Brian Campbell <bcampb...@pingidentity.com> wrote: > Thanks for your review and feedback, Richard. Replies are inline below... > > On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes <r...@ipv.sx> wrote: > 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. > > 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..." > > > > The audience restriction let's the issuer say specifically what relying party > is allowed to consume the assertion, which ensures that the client can't use > it somewhere else that it wasn't intended and that the relying party that > receives the assertion can't turn around and use it to access some other > service. > > Strictly speaking, you are right that the audience is only necessary if the > Issuer wishes to constrain the set of Authorization Servers with which an > assertion may be used. But the Issuer really really really should make that > constraint and fully understanding the implications of not doing so is > difficult and unlikely. > > There was a vulnerability in Google apps SAML a few years back that > demonstrates how important audience restriction is and how it can be > difficult for even very sophisticated providers to get it all right. I > haven't had time to read it again to make sure but I think that this is the > paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf > > I don't see what value allowing audience to be omitted brings other than that > it is academically a possibility. But requiring it (hopefully, if the > requirement is followed) helps reduce the possibility of a whole bunch of > security problems that folks likely won't foresee. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "keyed message digest" -> "Message Authentication Code" > > That's the proper terminology [RFC4949], especially since there are MACs > that are not based on digests. > > OK > > > "This mechanism provides additional security properties." -- Please > delete this or elaborate on what security properties it provides. > > Will delete. > > > Section 8.2 should note that "Holder-of-Key Assertions" are also a > mitigation for this risk. > > > OK > > > _______________________________________________ > 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
