Holder of key JWT is still in draft and we don't have a clear way to present the proof to the token endpoint.
Brian and I started discussing that last week as I happen to have a use case for a PoP JWT assertion flow in some other spec work. I think that there is enough difference between bearer and PoP that doing a follow on profile for SAML and JWT that can also cover the proof presentment mechanisms makes the most sense. I would go with restricting this to Bearer and MUST for audience, and removing the audience requirement explicitly in the PoP profiles. There are people who need the bearer version 6 months ago, I don't want to do anything to hold it up based on future work. I am happy to help with a SAML PoP/HoK draft as a follow on. The SAML subject confirmation stuff is relatively clear so it is mostly defining the presentment mechanisms like mutual TLS and a self signed assertion. (we need to be careful not to conflate client authentication and token proof, as they are different and might both be used at the same time. John B. On Oct 16, 2014, at 7: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. > > --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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
