I am good with it as is. I think we have the flexibility to add HoK later.
I mostly wanted to point out that it is really only in that later HoK profile where omitting audience is safe. If I had the power to remove the DISCUS I would. John B. On Oct 17, 2014, at 12:56 PM, Brian Campbell <bcampb...@pingidentity.com> wrote: > These drafts define the use of bearer assertions. The only mention of HoK > style assertions is at the end of > https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3 which > notes that the "rules defined in this document are intended to support a > client presenting a bearer assertion to an authorization server. The use of > holder-of-key assertions are not precluded by this document, but additional > protocol details would need to be specified." > > The requirement of having audience is for bearer assertions only (and we > agree need to be that way for bearer) and not intended to preclude anything > for HoK assertions. > > Does that change your opinion? Is there something that could be added or > removed or clarified to allay concerns? > > > > On Thu, Oct 16, 2014 at 6:54 PM, John Bradley <ve7...@ve7jtb.com> wrote: > 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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
