I agree, it is in redundant in the JARM case. I find the text in https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html#name-security-considerations (the 4th paragraph where JARM & JWTs) are mentioned a bit confusing - I think it would be good to say something along the lines of:
Although integrity protection is not necessary to prevent mixup, any authorization response method that includes a JWT with an ‘iss' (for example, JARM or OIDC hybrid flow) will prevent the attack (assuming the client is validating the iss). I’m not entirely sure I understand what "MUST NOT allow multiple authorization servers to return the same issuer identifier during registration” means as I don’t think https://tools.ietf.org/html/rfc7591 returns the issuer? It might be clearer to say something like “When https://tools.ietf.org/html/rfc8414 is used the client MUST implement the validation described in https://tools.ietf.org/html/rfc8414#section-3.3. When authorization server details can be manually configured in the client, the client must verify that all issuer values are unique.” (Or at least something along those lines, I’m sure my wording can be improved. But if the client is correctly implementing rfc8414 or OIDC discovery [and does not have any manually configured authorization servers] then there’s no requirement for any further checks that the issuer is unique.) Joseph > On 3 Nov 2020, at 07:01, Vladimir Dzhuvinov <vladi...@connect2id.com> wrote: > > This can potentially occur. If JARM is used "iss" becomes redundant. To me > JARM is an "enhanced" iss. > > If both are included a sensible client should make sure the iss and the JARM > iss match. > > My suggestion is to not require iss when a JARM is present, but in case both > do occur to have the client check both. > > Vladimir > > On 02/11/2020 22:34, Takahiko Kawasaki wrote: >> Hi Karsten, >> >> The specification mentions JARM. Does this specification require the iss >> response parameter even when JARM is used? That is, should an authorization >> response look like below? >> >> HTTP/1.1 302 Found >> Location: https://client.example.com/cb?response={JWT}&iss={ISSUER} >> <https://client.example.com/cb?response={JWT}&iss={ISSUER}> >> >> Or, can the iss response parameter be omitted when JARM is used? >> >> A small feedback for the 3rd paragraph in Section 4: s/identifes/identifies/ >> >> Best Regards, >> Taka >> >> >> On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov <vladi...@connect2id.com >> <mailto:vladi...@connect2id.com>> wrote: >> Thanks Karsten, looks good to me now, no further comments. >> >> Vladimir >> >> On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote: >>> Hi all, >>> >>> Daniel and I published a new version of the "iss" response parameter draft >>> to address the feedback from the WG. >>> >>> Changes in -01: >>> >>> Incorporated first WG feedback >>> Clarifications for use with OIDC >>> Added note that clients supporting just one AS are not vulnerable >>> Renamed metadata parameter >>> Various editorial changes >>> >>> We would like to ask you for further feedback and comments on the new draft >>> version. >>> >>> Best regards, >>> Karsten >>> >>> -------- Forwarded Message -------- >>> Subject: New Version Notification for >>> draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt >>> Date: Sun, 01 Nov 2020 23:31:42 -0800 >>> From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> >>> To: Karsten Meyer zu Selhausen <karsten.meyerzuselhau...@hackmanit.de> >>> <mailto:karsten.meyerzuselhau...@hackmanit.de>, Karsten zu Selhausen >>> <karsten.meyerzuselhau...@hackmanit.de> >>> <mailto:karsten.meyerzuselhau...@hackmanit.de>, Daniel Fett >>> <m...@danielfett.de> <mailto:m...@danielfett.de> >>> >>> >>> A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt >>> has been successfully submitted by Karsten Meyer zu Selhausen and posted to >>> the >>> IETF repository. >>> >>> Name: draft-meyerzuselhausen-oauth-iss-auth-resp >>> Revision: 01 >>> Title: OAuth 2.0 Authorization Server Issuer Identifier in Authorization >>> Response >>> Document date: 2020-11-01 >>> Group: Individual Submission >>> Pages: 10 >>> URL: >>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt >>> >>> <https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt> >>> Status: >>> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/ >>> >>> <https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/> >>> Html: >>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html >>> >>> <https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html> >>> Htmlized: >>> https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01 >>> <https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01> >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-meyerzuselhausen-oauth-iss-auth-resp-01 >>> >>> <https://www.ietf.org/rfcdiff?url2=draft-meyerzuselhausen-oauth-iss-auth-resp-01> >>> >>> Abstract: >>> This document specifies a new parameter "iss" that is used to >>> explicitly include the issuer identifier of the authorization server >>> in the authorization response of an OAuth authorization flow. If >>> implemented correctly, the "iss" parameter serves as an effective >>> countermeasure to "mix-up attacks". >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org >>> <http://tools.ietf.org/>. >>> >>> The IETF Secretariat >>> >>> >>> -- >>> Karsten Meyer zu Selhausen >>> IT Security Consultant >>> Phone: +49 (0)234 / 54456499 >>> Web: https://hackmanit.de <https://hackmanit.de/> | IT Security >>> Consulting, Penetration Testing, Security Training >>> >>> Does your OAuth or OpenID Connect implementation use PKCE to strengthen the >>> security? Learn more about the procetion PKCE provides and its limitations >>> in our new blog post: >>> https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client >>> >>> <https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client> >>> >>> Hackmanit GmbH >>> Universitätsstraße 60 (Exzenterhaus) >>> 44789 Bochum >>> >>> Registergericht: Amtsgericht Bochum, HRB 14896 >>> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. >>> Christian Mainka, Dr. Marcus Niemietz >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <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
