[Openid-specs-mobile-profile] Issue 52 CIBA Pairwise Identifiers Structuring Text
John Bradley
ve7jtb at ve7jtb.com
Mon Jun 12 18:50:19 UTC 2017
The problem is that the jwks_uri is not unique to CIBA. People can and do register it for other sorts of signed requests or encrypted responses.
Remember this is to stop correlation, and that can happen between legitimate clients with legitimate credentials.
My concern is a client can register a jwks_uri and someone else's redirect URI and AIU during registration and then do CIBA polling if registration and response are decoupled.
The issue is that SIU currently assumes the client gets the response via a redirect that must exactly match one of the ones registered.
CIBA breaks that logic.
So we added the post back URI and a rule to check it as you cant do postback without a registered URI that exactly matches.
You could register bogus redirect or postback URI and never use them in CIBA polling.
Assuming that we don’t allow http basic or any form of symmetric key with CIBA polling.
We have two options I can think of:
1. Always have registration require that the JWKS URI is in the SIU. (This would be a breaking change to existing deployments.)
2. Have the client also register that it wants to do CIBA polling and only check for those clients.
Both are CIBA specific changes to registration. The second CIBA would also need to mention to prevent people who haven't registered for polling from doing it if pairwise identifiers are used.
John B.
> On Jun 12, 2017, at 4:26 AM, Axel.Nennker at telekom.de wrote:
>
> Inline – long – sorry.
>
> From: John Bradley [mailto:ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>]
> Sent: Freitag, 9. Juni 2017 15:11
> To: Nennker, Axel <Axel.Nennker at telekom.de <mailto:Axel.Nennker at telekom.de>>
> Cc: James.H.Manger at team.telstra.com <mailto:James.H.Manger at team.telstra.com>; openid-specs-mobile-profile at lists.openid.net <mailto:openid-specs-mobile-profile at lists.openid.net>
> Subject: Re: [Openid-specs-mobile-profile] Issue 52 CIBA Pairwise Identifiers Structuring Text
>
> You could leave CIBA to say use the sector identifier URI.
> CIBA mandates that a sector_identifier_uri is registered at registration time and that the OP MUST validate that siu.
> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.4 <https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.4>
> “If the OpenId Provider uses Pairwise Identifiers then a sector_identifier_uri MUST be specified for all Clients using CIBA.”
>
> I am guessing that you agree CIBA should say that the post back URI MUST be registered to use post back.
> You are guessing correctly:
> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#client_notification_endpoint <https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#client_notification_endpoint>
>
> The question is where do we say that registration needs to error if the postback URI registered is not in the SIU.
> Why? The notification_endpoint_uri might be https://neu.example.org/ <https://neu.example.org/> and the siu might be https://siu.example.com/ <https://siu.example.com/> while another client of the same group might register a notification_endpoint_urihttps://foo.example.org/ <https://foo.example.org/> and the same siu. The OP MUST check that the person registering one client and then the other has the authority to use the same siu. Using James’ example: At registration time it MUST be impossiblemalware.org <http://malware.org/> to register itself for the same siu as good.com <http://good.com/>. This is true for front-channel and back-channel. CIBA does not introduce a new threat. If a bad client can register for an existing siu then then OIDC and CIBA have a problem.
>
> The more complicated question is for polling you don't want to allow someone to register with a redirect URI in someone else's SIU.
> Right. But there is no redirect_uri in polling. There is no redirect_uri in CIBA at all.
>
> Normally all the flows use the redirect URI but in the CIBA case it is not used so it provides no check.
> Right but all CIBA requests are authenticated and that is the check and all metadata for the client is fixed. W
> While in front-channel the request to the authentication endpoint is not authenticated because here the user authenticates NOT the client.
> In CIBA the Client is authenticated at the authentications endpoint and at the token endpoint.
>
> All metadata for the authenticated client is registered at registration time.
> - If notification is used then the OP uses the registered notification_endpoint_url.
> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#issuing_successful_token <https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#issuing_successful_token>
>
> If polling is used then the client is authenticated and the auth_req_id is the correlation to the authentication request.
> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#token_request <https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#token_request>
>
> We don’t want someone pretending to register for code but doing CIBA to bypass SIU verification.
> SIU validation is done at registration time. It is not possible to bypass it by using CIBA. There is no siu parameter which could be used in CIBA to do that.
>
> Since post back requires registration the check can be done in registration.
> CIBA requires a siu if pairwise identifiers are used at this OP and that Sector Identifier Validation is at registration time.
> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.4 <https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication.xml?at=default#rfc.section.4>
>
> We probably need some other registration element required to use CIBA polling so that the registration can be rejected if the JWKS URI is not in the SIU, and stop clients from doing polling if they have not registered the new element.
> The OpenID.Registration spec leave all of this open. There is no relationship between the siu and the content of the redirect_uri array.
> OIDC and the registration spec require that the metadata is validated but does not talk about how this is done. This could all be paper and lawyers.
>
> That is the only way we could isolate the SIU spoofing issue to Registration.
>
> A example would be to register a CIBA_response_type polling/postback. and do the appropriate check at registration.
> That way if you are using postback you don't need to worry about registering a JWKS_uri in your SIU.
> That is what CIBA is saying: if the Client wants notification then you must register a notification_endpoint_url. If the Client wants to sign something then it must register a jwks_uri.
>
> The client would need to register separate client_id for the different response methods, so that may be a downside unless you allow them to register multiple values.
> If the OP supports front-channel and back-channel for one client_id and the client has registered a redirect_uri and a notification and the OP uses the same endpoint for front-channel and back-channel authentication requests then the OP can still distinguish between the two modes because if the authentication request has a redirect_uri parameter then the request is a front-channel request and has to follow all requirements of OIDC or MODRNA authentication or if it does not have a redirect_url in the authentication request then it must be a CIBA request and follow all requirement of CIBA.
>
> We need something like that to keep the logic in registration.
>
> It seems like a lot of quite specific CIBA stuff to have in registration so some of it should at-least be referenced from CIBA.
> There is nothing CIBA specific to siu validation at registration time. The OP must validate siu at registration regardless of front-channel or backchannel.
>
> John B.
>
>
> On Jun 9, 2017, at 4:53 AM, <Axel.Nennker at telekom.de <mailto:Axel.Nennker at telekom.de>> <Axel.Nennker at telekom.de <mailto:Axel.Nennker at telekom.de>> wrote:
>
> Using the example from http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation <http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation>
>
> The siu is https://other.example.net/file_of_redirect_uris.json <https://other.example.net/file_of_redirect_uris.json>
> And in the context of pairwise identifier algorithms the content of that file is irrelevant because what feeds into that algorithm for all clients in that group is exactly “other.example.net <http://other.example.net/>” and nothing else.
> That is
> sector_identifier === “other.example.net <http://other.example.net/>”
> in https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg <https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg>
>
> This value of sector_identifier does not change whether the Client uses Polling or Notification or needs a jwks or not.
>
> I think that these are separate topics.
>
> CIBA demands a sector_identifier_uri to enable pairwise subs and I still don’t see why this topic is related to whether the Client polls or uses notification or signed somethings.
> If the CIBA Client wants to be notified then it _additionally_ needs to specify a notification_endpoint_url at registration time.
> If the CIBA Client wants to sign something then it _additionally_ needs to specify a jwks_url.
>
> If CIBA would not have sector_identifier_uri being mandatory at registration time then CIBA would need to talk about _default_ values for sector_identifier_uri.
>
>
> // Axel
>
>
> From: Manger, James [mailto:James.H.Manger at team.telstra.com <mailto:James.H.Manger at team.telstra.com>]
> Sent: Freitag, 9. Juni 2017 02:02
> To: Nennker, Axel <Axel.Nennker at telekom.de <mailto:Axel.Nennker at telekom.de>>; ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>; openid-specs-mobile-profile at lists.openid.net <mailto:openid-specs-mobile-profile at lists.openid.net>
> Subject: RE: [Openid-specs-mobile-profile] Issue 52 CIBA Pairwise Identifiers Structuring Text
>
> > My hope was that by making sector_identifier_uri mandatory we would get rid of all the special cases with jwks_uri and whatnot.
> > Isn’t that true?
>
> No.
>
> > So if someuses CIBA then there MUST be a siu at registration time and CIBA does not care how that is validated.
> > Making my life too easy?
>
> Wishful thinking, Axel ;)
>
>
> An OP needs proof that an app is entitled to use a sector_id before revealing the subs associated with that sector_id.
> A new app merely quoting a sector_id in its registration is not proof. It shows the app wants that sector_id, but it doesn’t show that the other apps using that sector_id want to share subs with this new app. It doesn’t prevent a malicious app quoting another group’s sector_id.
>
> So the content at a sector_identifier_uri needs to identity each app that is entitled to use that sector_id (host part of siu). It does so by listing a URI that each app needs to control to operate. For “normal” OIDC an app’s redirect_uri is sufficient; for CIBA with notifications an app’s client_notification_endpoint is sufficient; for CIBA with polling and asymmetric signatures an app’s jwks_uri is sufficient; for other cases the tuple {iss, client_id} could work.
>
> Hence CIBA needs to add that, at registration, the OP needs to confirm that siu lists client_notification_endpoint (to enabling notifications) or jwks_uri (to enabling polling with asym sigs).
>
> --
> James Manger
>
>
> From: John Bradley [mailto:ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>]
> Sent: Donnerstag, 8. Juni 2017 18:56
> To: Nennker, Axel <Axel.Nennker at telekom.de <mailto:Axel.Nennker at telekom.de>>
> Cc: openid-specs-mobile-profile at lists.openid.net <mailto:openid-specs-mobile-profile at lists.openid.net>
> Subject: Re: [Openid-specs-mobile-profile] Issue 52 CIBA Pairwise Identifiers Structuring Text
>
> Validation of the sector identifier is part of registration.
>
> The client registers its client_notification_endpoint as a new element. (Shouldn't that be an array vs a single URI if the request allows notification_uri to be specified? otherwise why send it in the request?)
>
> The registration process needs to check those URI against the URI in the JSON file returned from the sector_identifier_uri.
>
> I dont think registration is going to get updated anytime soon so it probably needs to be explained in this spec for those IDP that allow notifiction_uri to be specified.
>
> All AS should always use the sector_identifier_uri as the key for generating ppid. Nothing in that changes.
>
> I think for the polling we need to specify the client JWKS endpoint in the sector_identifier_uri as well.
>
> It is just a URI so that should not be an issue.
>
> If the registered jwks uri is not in the file then don’t allow polling.
> I know this precludes the use of symmetric keys but I think that may be a reasonable trade off if someone wants to use this with polling.
>
> John B.
>
>
>
> On Jun 8, 2017, at 3:38 AM, <Axel.Nennker at telekom.de <mailto:Axel.Nennker at telekom.de>> <Axel.Nennker at telekom.de <mailto:Axel.Nennker at telekom.de>> wrote:
>
> Hi all,
>
> can this issue be closed?
> https://bitbucket.org/openid/mobile/issues/52/ciba-pairwise-identifiers-structuring-text <https://bitbucket.org/openid/mobile/issues/52/ciba-pairwise-identifiers-structuring-text>
>
> The sector_identifier_url is now mandatory to be specified at Client registration time.
> Validation of the sector_identifier is out-of-scope for CIBA and should be in Discovery.
>
> Please comment on the issue in bitbucket or here.
>
> Kind regards
> Axel
>
>
>
>
>
> DEUTSCHE TELEKOM AG
> T-Labs (Research & Innovation)
> Axel Nennker
> Winterfeldtstr. 21, 10781 Berlin
> +491702275312 (Tel.)
> E-Mail: axel.nennker at telekom.de <mailto:axel.nennker at telekom.de>
>
>
>
> _______________________________________________
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net <mailto:Openid-specs-mobile-profile at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile <http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20170612/0a8d8fee/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4383 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20170612/0a8d8fee/attachment-0001.p7s>
More information about the Openid-specs-mobile-profile
mailing list