[Openid-specs-ab] Issue #1049: backchannel logout requests should include a reference to the OP (openid/connect)

Tom Jones thomasclinganjones at gmail.com
Sat Sep 22 17:24:26 UTC 2018


Tls requires good dos protection, full stop. If used it will protect all of
the services behind it.

If the microserver is resource constrained there is no reason to believe
anything it says, so security cannot be an issue.

thx ..Tom (mobile)

On Sep 22, 2018 9:33 AM, "Phil Hunt" <phil.hunt at oracle.com> wrote:

Mutual tls (non tokenized) seems like a good solution provided the logout
event node can use the OP’s issuer cert as client cert to establish the TLS
connection. But this might not be easy for some microservice architectures
as this means wider shared access to issuer private keys are needed which
weakens overall security.

Regarding encrypted events...
I don’t see the value in encrypting logout events. The logout event only
contains identifiers that are transitory and are now end of life notices.
The primary risk is an attacker serving fake logouts as part of a DoS
attack. Signed logouts plus TLS transport should be enough here.

We must also consider the general load on resource servers if they have to
do a lot of crypto to reject false events. This is a DoS risk. Is Mutual
TLS a good way to mitigate this or does it just shift the load to tls
terminators?

Phil

On Sep 22, 2018, at 8:53 AM, Tom Jones <thomasclinganjones at gmail.com> wrote:

Wouldn't it make more sense for all back channel connex to be over tls with
mutual auth?

thx ..Tom (mobile)

On Fri, Sep 21, 2018, 8:38 AM Phil Hunt via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Interesting. My assumption is iss, aud etc are req’d claims from JWT.
>
> However maybe a reminder is important?
>
> Phil
>
> > On Sep 21, 2018, at 4:52 AM, Hans Zandbelt via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
> >
> > New issue 1049: backchannel logout requests should include a reference
> to the OP
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_openid_connect_issues_1049_backchannel-2Dlogout-2Drequests-2Dshould-2Dinclude&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=lm9I-tIhoNwvye6UOWEMPW8NY3NHLUhJ9SotrZMkfjo&s=3LFWnJR17VF0dS5xSTSpiGzBJQ6AFN3Pu3Oa8M3ONMQ&e=
> >
> > Hans Zandbelt:
> >
> > Whilst taking a stab at implementing backchannel logout according to:
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0.html&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=lm9I-tIhoNwvye6UOWEMPW8NY3NHLUhJ9SotrZMkfjo&s=L6lYaopVVDpj0Pk2gtvli2CrojHXip4pHWm-fsGlHyQ&e=
> >
> > I found that for an RP that connects to multiple OPs it would be
> impossible to deduct the OP from the `logout_token` if it is encrypted with
> a symmetric key. Since following the OpenID Connect `id_token` guidelines
> (as suggested) it would have to decrypt with the `client_secret` which is
> (hopefully) a per-provider setting. Trying all OPs/`client_secret`'s
> consecutively would be very inefficient and probably not what anyone would
> want to do.
> >
> > I suggest to add an `iss` parameter to the backchannel logout request in
> addition to the `logout_token` parameter.
> >
> > This will also make it easier for implementors to share the code path
> with `id_token` validation since they'd no longer have to "peek" into the
> `id_token` before calling the validation routine that may be issuer
> specific. The issuer would typically be known before validating the
> id_token since it is recorded in the (browser bound) state.
> >
> >
> > _______________________________________________
> > Openid-specs-ab mailing list
> > Openid-specs-ab at lists.openid.net
> >
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=lm9I-tIhoNwvye6UOWEMPW8NY3NHLUhJ9SotrZMkfjo&s=QFeT_kOuXhKRo7gZWzW_kdBxaAC_PCO1A2u3BadpGqo&e=
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=FD3sdo7UYTo8Q7XbmdDTGUOKlLvVI2B8koxVa-b6G2E&s=VKqLOiCGCgwXjtCAoUsFj75tPp-nU-KYNp4i40HlMSM&e=>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180922/784336c1/attachment-0001.html>


More information about the Openid-specs-ab mailing list