On Thu, Oct 16, 2014 at 3:20 PM, Richard Barnes <r...@ipv.sx> wrote: > You guys are all arguing that having an Audience can be useful. I don't > disagree. I disagree that it should be REQUIRED in all cases. > > The Google vulnerability that Brian raised was an interesting read, but as > John points out, it only applies to Bearer Assertions. There's no security > requirement at all for holder-of-key assertions to have an audience, since > they can't be replayed by someone who doesn't hold the key. > > I could agree that an audience should be REQUIRED for bearer assertions. > Since they are vulnerable to replay, Audience protects against the > Authorization Server re-using the token. (It would be good to say this > explicitly in the doc, actually.) But for holder-of-key assertions, the > Audience should be OPTIONAL. Note that this requires that instance > documents define the difference between bearer assertions and holder-of-key > assertions, so that implementations can enforce these requirements. > > So it seems like there are two solutions here: > 1. Scope the document to bearer assertions only, and keep the MUST > 2. Keep the current scope, make Audience OPTIONAL for holder-of-key > assertions, and define the difference in the instance docs. >
I'll also offer a third resolution: 3. Show me that the WG discussed this question and made the decision to forbid holder-of-key assertions without an Audience parameter. --Richard > --Richard > > > > > > > On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt <phil.h...@oracle.com> wrote: > >> 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
