<div dir="ltr"><div>I didn't mean to suggest that they had to be mutually exclusive. I was more reflecting on the feeling/belief that the Connect only advice isn't sufficient and won't be viable for many. <br><br>It might be overreaching and unrealistic for Connect to try and solve it for OAuth with hybrid and anonymous or transient subjects in the ID token. <br><br>An article or blog post from/about Connect about how it can be utilized now as a mitigation is probably useful. But I don't think it should be a formal spec and don't think new behavior should be defined. <br><br></div><div>My view is still that the attack is enabled by an commission in OAuth of the AS identifying itself in the authorization response. I think the fix should be at that layer too. Progress in the OAuth WG isn't exactly promising though... <br></div><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 14, 2016 at 10:12 PM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Given that Basic is MTI, it is not surprising that hybrid has lower support in testing.<div><br></div><div>Some IdP like MS actually started only supporting hybrid and added code to pass the tests.</div><div><br></div><div>For IdP only supporting code now hybrid is more work.</div><div><br></div><div>For clients hybrid is more work as they need to check c_hash and validate the signature on the id_token that many clients skip doing on the id_token in the direct connection.</div><div><br></div><div>I thing for clients and servers that support hybrid, recommending using that now if they are connecting to multiple AS is probably the responsible thing to do.</div><div><br></div><div>For clients and servers not currently supporting hybrid we need to decide if we want to send them in that direction or have another extension to secure code.</div><div><br></div><div>Token binding the id_token is a great way to stop cut and paste, and stop leakage of AT. A token binding version of PKCE would stop a number of the mixup attacks. That is worth developing but is not a overnight solution. </div><div><br></div><div>Other things that will mitigate these attacks for OAuth add more moving parts so have plusses and minuses. As the Connect WG it is probably best to be mindful of our scope and not prejudice the work the OAuth WG is going to do. </div><div><br></div><div>John B.</div><div><div class="h5"><div><br><div><blockquote type="cite"><div>On Apr 14, 2016, at 11:50 PM, William Denniss <<a href="mailto:wdenniss@google.com" target="_blank">wdenniss@google.com</a>> wrote:</div><br><div><div dir="ltr">Connect can mitigate these attacks today (via the Hybrid flow) with no spec changes at all. Those who have deployed Connect with Hybrid can start hardening their deployments today. This suggestion is simply to profile that. It doesn't preclude other approaches. I'm not sure why it has to be mutually exclusive.<div><div><br></div><div>"code id_token" with form_post is actually not that much different to "code" for Connect RPs – in both cases you get the ID token on the code exchange and potentially refresh, it just adds an extra id_token to the authorization grant.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 14, 2016 at 3:12 PM, Brian Campbell <span dir="ltr"><<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The Connect level mitigation guidance sounded good over lunch in BA but, with some time thinking about it, I must say I'm sympathetic to what Torsten is saying here. Code alone is very popular for both Connect and OAuth. And looking at the certification results <a href="http://openid.net/certification/" target="_blank">http://openid.net/certification/</a> shows that the amount of support for 'Hybrid' is less than 'Basic'.<br><br><br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 14, 2016 at 12:47 PM, Torsten Lodderstedt <span dir="ltr"><<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Hi William,<span><br>
<br>
<div>Am 14.04.2016 um 18:22 schrieb William
Denniss:<br>
</div>
<blockquote type="cite">
<div dir="ltr">extensions to OP:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF"> - issue ID token in the front
channel </div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF"> - add c_hash to id token<br>
</div>
</blockquote>
<div><br>
</div>
<div>
<div>I would rephrase these two extensions as "supporting
the hybrid flow", c_hash is a REQUIRED claim for the
hybrid flow, the conformance test ID for this is: <font face="monospace, monospace">OP-IDToken-c_hash</font></div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</span><tt>That's certainly right. I wanted to list all the necessary
changes an OP Basic needs to implement in order to support this
profile.</tt><font face="monospace, monospace"><br>
<br>
</font>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">...
<span><div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF"> Apperently, this solution would
not work for plain OAuth. Moreover, I personally think
this significantly adds complexity (and cost) to both
ends, OP as well as RPs, in comparison to other
potential mitigations. Experience shows that complexity
is the enemy of correct/reliable implementations, which
is esp. dangerous when it comes to security for mass
market/internet services.<br>
</div>
</blockquote>
<div><br>
</div>
<div>We have a solution in Connect. We should document that
solution.</div>
</span></div>
</div>
</div>
</blockquote>
<br>
We have a solution for hybrid OPs, not basic OPs. And as I said, it
does not work for OAuth. So even if a basic OP is extended to become
an hybrid OP, there is no solution for the OAuth use cases, which
run on the same endpoint.<span><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>The Connect solution requires no changes to Connect.
The proposal here is simply documenting what people should
do if they want to mitigate these potential attacks.</div>
</div>
</div>
</div>
</blockquote>
<br></span>
The proposal might not require changes to Connect, but it requires
significant changes to basic OPs and RPs. That's what I wanted to
point out. There might be a significant difference between what is
documented in a spec and deployed reality. Do we have insights, how
many _deployed_ OPs and RPs in the wild nowadays use hybrid flows
(code id_token specifically)?<span><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>I don't believe the Connect WG should be constrained to
solve problems without using the features of Connect.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF"> So from my perspective, there are
two questions:<br>
1) Can we find a solution for OIDC and OAuth (for code)?<br>
</div>
</blockquote>
<div><br>
</div>
<div>That solution may well be: use Connect. At least, if
you wanted to solve it today without any spec changes or
extensions, that would be my advice.</div>
</div>
</div>
</div>
</blockquote>
<br></span>
Hmmm, I don't intend to issue id tokens to OAuth clients and I don't
want to make of client any bit harder than absolutely necessary.
That has been the reason for the success of OAuth 2.0 and OpenId
Connect.<span><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF"> 2) Can we make it a simpler one?<br>
</div>
</blockquote>
<div><br>
</div>
<div>I'm listening.</div>
</div>
</div>
</div>
</blockquote>
<br></span>
As you said, checking nonce (even on the backchannel) is sufficient
to detect/prevent cut and paste. An alternative solution would be to
link the state to the code and provide the state value for
validation to the token endpoint.<br>
<br>
With respect to mix up, there are several potential solutions:<br>
- clients/RPs use different redirect uris for different ASs/OPs (as
originally proposed by the researchers, who discovered the attack)<br>
- provide the client/RP with issuer and client_id as response query
parameters
(<a href="https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00#section-3.1" target="_blank">https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00#section-3.1</a>)<br>
- provide the client/RP with the token endpoint the particular code
is good for
(<a href="https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5" target="_blank">https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5</a>)<br>
<br>
best regards,<br>
Torsten.<div><div><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF"> <br>
best regards,<br>
Torsten.
<div>
<div><br>
<br>
<div>Am 13.04.2016 um 06:22 schrieb Mike Jones:<br>
</div>
<blockquote type="cite">
<div><p><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(0,32,96)">It
is always mandatory for the server to
include the nonce in the ID Token if
provided in the request and it is likewise
always mandatory for the RP to validate the
nonce, if present in the ID Token. For all
response_type values other than “code”,
including a nonce in the request is also
mandatory.</span></p><div><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(0,32,96)"> </span><br></div><p><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(0,32,96)">
-- Mike</span></p><p><a name="m_1861879638107976615_m_-5164938951905673361_m_-4900259997662664963_m_215345308969227833_m_-1544105078182548349__MailEndCompose"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(0,32,96)"> </span></a></p>
<span></span>
<div>
<div style="border-style:solid none none;border-right-width:initial;border-bottom-width:initial;border-left-width:initial;border-right-color:initial;border-bottom-color:initial;border-left-color:initial;border-top-color:rgb(225,225,225);border-top-width:1pt;padding:3pt 0in 0in"><p><b><span style="font-size:11pt;font-family:calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:calibri,sans-serif"> Openid-specs-ab [<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank"></a><a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">mailto:openid-specs-ab-bounces@lists.openid.net</a>]
<b>On Behalf Of </b>John Bradley<br>
<b>Sent:</b> Tuesday, April 12, 2016
5:31 PM<br>
<b>To:</b> William Denniss <a href="mailto:wdenniss@google.com" target="_blank"></a><a href="mailto:wdenniss@google.com" target="_blank"><wdenniss@google.com></a><br>
<b>Cc:</b> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-ab]
Defining a Hardened (Mix-up and
Cut-and-Paste Proof) OpenID Connect
Profile</span></p>
</div>
</div><div> <br></div><p>If they send it and don’t detect if it has
changed from the request then that is a
definite error.</p>
<div><div> <br></div>
</div>
<div><p>If they don’t send it, it should be a
warning as there are some cases with a
simple preconfigured client that not
checking may be OK.</p>
</div>
<div><div> <br></div>
</div>
<div><p>I personally argued at the time to always
check it, so I am not going to push back
very hard on making it mandatory to check
other than it is a change to the spec.</p>
</div>
<div><div> <br></div>
</div>
<div><p>John B.</p>
</div>
<div><div> <br></div>
<div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div><p>On Apr 12, 2016, at 5:34 PM, William
Denniss <<a href="mailto:wdenniss@google.com" target="_blank">wdenniss@google.com</a>>
wrote:</p>
</div><div> <br></div>
<div><p><br>
<br>
</p>
<div><p><span style="font-size:9pt;font-family:helvetica,sans-serif">On
Tue, Apr 12, 2016 at 2:28 PM, John
Bradley<span> </span><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank"></a><a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>><span> </span>wrote:</span></p>
<blockquote style="border-style:none none none solid;border-top-width:initial;border-right-width:initial;border-bottom-width:initial;border-top-color:initial;border-right-color:initial;border-bottom-color:initial;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div><p><span style="font-size:9pt;font-family:helvetica,sans-serif">The
AS is all-ready required to
include nonce in the id_token
if it is present in the
request. That is a MUST in
the spec.</span></p>
<div><p><span style="font-size:9pt;font-family:helvetica,sans-serif">That
should be a test all-ready.</span></p>
</div>
</div>
</blockquote>
<div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
</div>
<div><p><span style="font-size:9pt;font-family:helvetica,sans-serif">There
is: </span><i><span style="font-size:9.5pt;font-family:helvetica,sans-serif">ID
Token has nonce when requested
for code flow [Basic]
(OP-nonce-code)</span></i><i><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span></i><span style="font-size:9pt;font-family:helvetica,sans-serif"></span></p>
</div>
<div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
</div>
<div><p><span style="font-size:9pt;font-family:helvetica,sans-serif">So
for this, it's more that we need
to add an RP test to ensure that
RPs are actually sending and
verifying nonce.</span></p>
</div>
<div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
</div>
<blockquote style="border-style:none none none solid;border-top-width:initial;border-right-width:initial;border-bottom-width:initial;border-top-color:initial;border-right-color:initial;border-bottom-color:initial;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div><p><span style="font-size:9pt;font-family:helvetica,sans-serif">Basically
fragment encoding is not a
good idea any more other
than for JS in the browser
or for native apps using
view controllers or system
browsers.</span></p>
</div>
<div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
</div>
<div><p><span style="font-size:9pt;font-family:helvetica,sans-serif">Servers
really should support the
form post response mode.</span></p>
</div>
<div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
</div>
<div><p><span style="font-size:9pt;font-family:helvetica,sans-serif">A
client that wants to be
secure can send nonce and
use “code id_token” if they
want offline or “token
id_token” if they don’t want
offline.</span></p>
</div>
<div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
</div>
<div><p><span style="font-size:9pt;font-family:helvetica,sans-serif">That
is secure. </span></p>
</div>
<div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
</div>
<div><p><span style="font-size:9pt;font-family:helvetica,sans-serif">There
are other mitigations we
talked about in OAuth with
returning the client_id and
iss as parameters rather
than returning a id_token.</span></p>
</div>
<div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
</div>
<div><p><span style="font-size:9pt;font-family:helvetica,sans-serif">The
client really only needs to
check those two values in
the front channel, but I
would not want to change the
spec to say that.</span></p>
</div>
</div>
</blockquote>
<div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
</div>
<div><p><span style="font-size:9pt;font-family:helvetica,sans-serif">+1
to all the above</span></p>
</div>
<div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
</div>
<blockquote style="border-style:none none none solid;border-top-width:initial;border-right-width:initial;border-bottom-width:initial;border-top-color:initial;border-right-color:initial;border-bottom-color:initial;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
</div>
<div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
</div>
<div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
</div>
<div><p><span style="font-size:9pt;font-family:helvetica,sans-serif">John
B.</span></p>
</div>
<div>
<div>
<div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
<div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div><p><span style="font-size:9pt;font-family:helvetica,sans-serif">On
Apr 12, 2016, at
4:58 PM, William
Denniss <<a href="mailto:wdenniss@google.com" target="_blank"></a><a href="mailto:wdenniss@google.com" target="_blank">wdenniss@google.com</a>> wrote:</span></p>
</div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
<div>
<div>
<div>
<div><p><span style="font-size:9pt;font-family:helvetica,sans-serif"><br>
On Tue, Apr
12, 2016 at
12:50 PM, Hans
Zandbelt <<a href="mailto:hzandbelt@pingidentity.com" target="_blank"></a><a href="mailto:hzandbelt@pingidentity.com" target="_blank">hzandbelt@pingidentity.com</a>> wrote:</span></p>
<blockquote style="border-style:none none none solid;border-top-width:initial;border-right-width:initial;border-bottom-width:initial;border-top-color:initial;border-right-color:initial;border-bottom-color:initial;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><p><span style="font-size:9pt;font-family:helvetica,sans-serif">from
an
implementers/deployment
standpoint I
would argue
that if the
id_token is
delivered in
the front
channel, I may
just as well
get the access
token from
there too
rather than
having to deal
with the
overhead of
calling the
token
endpoint, esp.
since at_hash
is there to
protect
integrity<br>
<br>
so I'd favor
response_mode=form_post,
response_type="id_token
token" over
hybrid<br>
<br>
I realize that
this doesn't
leverage the
possibility of
using a client
secret to get
the access
token but it
doesn't really
seem to matter
security-wise
at this point
as the
id_token was
delivered
without
leveraging it
as well<br>
<br>
anything wrong
with that line
of reasoning?</span></p>
</blockquote>
<div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
</div>
<div><p><span style="font-size:9pt;font-family:helvetica,sans-serif">1)
Server won't
have offline
access with
"id_token
token". 2) The
primary case
we are dealing
with today is
the code flow,
and we are
really just
suggesting
clients add
security
checks onto
their existing
flows by
leveraging
id_token.</span></p>
</div>
<div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
</div>
<div><p><span style="font-size:9pt;font-family:helvetica,sans-serif">It's
true that you
could do many
of the same
checks with
"id_token
token" to
verify that
the access
token was
issued by the
correct party
and avoid
cut-and-paste
and mix-up, if
you only
needed a
once-off
access token.</span></p>
</div>
<div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
</div>
<div><p><span style="font-size:9pt;font-family:helvetica,sans-serif">You
raise an
interesting
point
regarding
client
confidentiality.</span></p>
</div>
<div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
</div>
<blockquote style="border-style:none none none solid;border-top-width:initial;border-right-width:initial;border-bottom-width:initial;border-top-color:initial;border-right-color:initial;border-bottom-color:initial;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><p><span style="font-size:9pt;font-family:helvetica,sans-serif">On
4/12/16 9:23
PM, William
Denniss wrote:</span></p>
<blockquote style="border-style:none none none solid;border-top-width:initial;border-right-width:initial;border-bottom-width:initial;border-top-color:initial;border-right-color:initial;border-bottom-color:initial;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><p style="margin-bottom:12pt"><span style="font-size:9pt;font-family:helvetica,sans-serif">Good point.<br>
<br>
Regarding the
OP tests, the
following are
relevant to
mitigate the<br>
cut-and-paste
and mix-up
attacks:<br>
<br>
1. ID Token
has nonce when
requested for
code flow
[Basic]
(OP-nonce-code)<br>
2. Request
with
response_mode=form_post
[Extra]
(OP-Response-form_post)<br>
<br>
1) is
important for
preventing
cut-and-paste
(the id token
needs to<br>
contain the
'nonce')<br>
2) is
important for
preventing
mix-up as it
means the
redirect
endpoint<br>
gets the
id_token on
the response
at the server,
as opposed to
in the<br>
URI fragment.<br>
<br>
Unfortunately,
form_post is
optional for
OPs, and
sending the
nonce on<br>
the code flow
is optional
for RPs
(though
fortunately to
it is<br>
compulsory for
OPs to support
thanks to
OP-nonce-code).<br>
<br>
We could add
an hardened OP
test for:<br>
– Forcing
nonce to be
present on the
code flow<br>
<br>
We should
definitely
have RP tests
for:<br>
– sending and
validating
nonce on the
code flow<br>
– validating
the c_hash,
iss, aud on
the hybrid
flow<br>
<br>
How we would
profile these
tests I'm not
sure; would
they go in the<br>
Basic testing
profile, or in
a new Hardened
one? We could
move<br>
OP-Response-form_post
to the Basic
profile if we
wanted to be<br>
opinionated,
or define a
new profile.<br>
<br>
The good news
is that
supporting the
features
required to
mitigate<br>
mix-up &
cut-and-paste
is not all
that hard to
do in Connect.<br>
<br>
<br>
On Tue, Apr
12, 2016 at
10:46 AM, Nick
Roy <<a href="mailto:nroy@internet2.edu" target="_blank"></a><a href="mailto:nroy@internet2.edu" target="_blank">nroy@internet2.edu</a><br>
<mailto:<a href="mailto:nroy@internet2.edu" target="_blank"></a><a href="mailto:nroy@internet2.edu" target="_blank">nroy@internet2.edu</a>>>
wrote:<br>
<br>
<span> </span>Would
it be possible
to check for
the secure
behavior in
Roland's<br>
<span> </span>test
suite and
either not
certify
non-mitigating
implementations,
or<br>
<span> </span>offer
a risk
mitigation
add-on cert
for those that
do the right
thing?<br>
<br>
<span> </span>Nick<br>
<br>
<span> </span>From:
Openid-specs-ab
<<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank"></a><a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a><br>
<span> </span><mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank"></a><a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>>>
on behalf of<br>
<span> </span>William
Denniss <<a href="mailto:wdenniss@google.com" target="_blank"></a><a href="mailto:wdenniss@google.com" target="_blank">wdenniss@google.com</a> <mailto:<a href="mailto:wdenniss@google.com" target="_blank"></a><a href="mailto:wdenniss@google.com" target="_blank">wdenniss@google.com</a>>><br>
<span> </span>Date:
Tuesday, April
12, 2016 at
11:01 AM<br>
<span> </span>To:
"<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank"></a><a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
<span> </span><mailto:<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank"></a><a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>>"<br>
<span> </span><<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank"></a><a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a><br>
<span> </span><mailto:<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank"></a><a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>>><br>
<span> </span>Subject:
[Openid-specs-ab]
Defining a
Hardened
(Mix-up and<br>
<span> </span>Cut-and-Paste
Proof) OpenID
Connect
Profile<br>
<br>
<span> </span>One
item that came
out of the
discussions on
the sidelines
of IETF95<br>
<span> </span>with
folk from this
WG
(specifically
Nat, Mike,
John, Brian
and<br>
<span> </span>myself)
was the need
for the
Connect
community to
respond to the<br>
<span> </span>recently
<<a href="http://arxiv.org/abs/1508.04324v2/" target="_blank"></a><a href="http://arxiv.org/abs/1508.04324v2/" target="_blank">http://arxiv.org/abs/1508.04324v2/</a>>
documented<br>
<span> </span><<a href="http://arxiv.org/abs/1601.01229v2/" target="_blank"></a><a href="http://arxiv.org/abs/1601.01229v2/" target="_blank">http://arxiv.org/abs/1601.01229v2/</a>>
security
threats.<br>
<br>
Connect is
actually in a
much stronger
place for
mitigating
these<br>
attacks
(as noted in
the papers
themselves)
than pure
OAuth, with<br>
the
id_token
offering a
cryptographic
binding of the
code to the<br>
issuer,
audience and
session
identifier
(nonce).<br>
<br>
However,
certain steps
need to be
followed, for
example using<br>
'nonce'
with the code
flow (which is
optional to
implement for<br>
clients)
to protect
against
cut-and-paste,
and using the
form-post<br>
response
type with the
hybrid flow to
verify that
the code was<br>
issued by
the expected
IdP, to ensure
the code is
exchanged at
the<br>
correct
token endpoint
(mitigating
mix-up).<br>
<br>
We
discussed last
week creating
a profile of
Connect that
recommends<br>
those
practices to
mitigate these
classes of
attack as a
response to<br>
the
security
researchers'
findings. I
wanted to
share that<br>
suggestion
with the list,
and continue
the
conversation.<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Openid-specs-ab
mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"></a><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank"></a><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span></p>
</blockquote><p><span style="font-size:9pt;font-family:helvetica,sans-serif;color:rgb(136,136,136)"><br>
-- <br>
Hans Zandbelt
|
Sr. Technical
Architect<br>
<a href="mailto:hzandbelt@pingidentity.com" target="_blank"></a><a href="mailto:hzandbelt@pingidentity.com" target="_blank">hzandbelt@pingidentity.com</a> |
Ping Identity</span><span style="font-size:9pt;font-family:helvetica,sans-serif"></span></p>
</blockquote>
</div><div><span style="font-size:9pt;font-family:helvetica,sans-serif"> </span><br></div>
</div>
</div><p><span style="font-size:9pt;font-family:helvetica,sans-serif">_______________________________________________<br>
Openid-specs-ab
mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"></a><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank"></a><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span></p>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div><div> <br></div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br></div></blockquote></div><br></div></div></div></div></blockquote></div><br></div>