[Openid-specs-ab] Nonce value suggestion for the Implicit Flow
Nat Sakimura
nat at sakimura.org
Thu Nov 14 15:03:34 UTC 2013
So, the current text covers "user agenet swap".
Your text seem to cover something else - seems like a pure replay.
Is that the case?
2013/11/14 Richer, Justin P. <jricher at mitre.org>
> I like the text that's there, but let's add this to cover the other (in
> my view, more common) case:
>
> "Another option, often useful for clients that are web servers or native
> applications, is to store the value of the nonce in a protected store local
> to the client, away from the user agent. This value can be retrieved from
> the store when the end user returns to the client via the redirect_uri and
> used when validating the id_token."
>
> -- Justin
>
> On Nov 13, 2013, at 10:16 PM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
>
> If you want to propose specific text changes, we can look at them.
> Otherwise, I think we’re good.
>
> -- Mike
>
> *From:* John Bradley [mailto:ve7jtb at ve7jtb.com]
> *Sent:* Wednesday, November 13, 2013 12:40 PM
> *To:* Brian Campbell
> *Cc:* George Fletcher; Mike Jones; openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Nonce value suggestion for the Implicit
> Flow
>
> That looks good.
>
> One question is if we want to also say the nonce value may be stored as
> part of the session state on the client (webserver).
>
> Adding too many options may just confuse people though.
>
> John B.
>
>
> On Nov 13, 2013, at 11:38 AM, Brian Campbell <bcampbell at pingidentity.com>
> wrote:
>
>
> "a random value as an HttpOnly a session cookie" -> remove the "a"
> after HttpOnly?
>
>
> On Wed, Nov 13, 2013 at 11:35 AM, George Fletcher <gffletch at aol.com>
> wrote:
>
> I'll let John quibble over the specifics :) ... but it looks good to me.
> Thanks, George
> On 11/13/13 1:30 PM, Mike Jones wrote:
>
> Please review the new text at
> http://openid.bitbucket.org/openid-connect-core-1_0.html#NonceNotes,
> which is where the implementation suggestions for the nonce parameter have
> been moved.
>
> -- Mike
>
> *From:* openid-specs-ab-bounces at lists.openid.net [
> mailto:openid-specs-ab-bounces at lists.openid.net<openid-specs-ab-bounces at lists.openid.net>
> ] *On Behalf Of *Brian Campbell
> *Sent:* Wednesday, October 30, 2013 9:00 AM
> *To:* John Bradley
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Nonce value suggestion for the Implicit
> Flow
>
> The nonce is a different approach to protecting against things like
> replay prevention but doesn't have the same scaling implications as
> tracking token ids. Which is nice.
>
>
> On Wed, Oct 30, 2013 at 4:13 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> The nonce is opaque to the AS, it is sent by the client and validated by
> the client. It binds the signed id_token to something in the user's
> browser session. This is critical to prevent attacks on the implicit
> flow, where the redirect_uri is not sent to the token endpoint for
> validation. It is not required for the "code" flow. In the hybrid flows
> it needs to be used to validate the id_token presented in the front
> channel as well, as the client may be using the id_token before exchanging
> code at the token endpoint, and discovering an attack.
>
> I think it also prevents some attacks against code interception that
> checking the redirect_uri wouldn't so in a high loa deployment I would
> check both nonce and the redirect_uri.
>
> Are you asking about "jti" in the assertion used to authenticate the
> client to the token endpoint?
>
> On Oct 30, 2013, at 1:44 AM, Anthony Nadalin <tonynad at microsoft.com>
> wrote:
>
>
> I’m not seeing how you are dealing with duplicate nonces as this can be
> a scaling issue when dealing with millions of requests, the nonces need
> better advice
>
> *From:* openid-specs-ab-bounces at lists.openid.net [
> mailto:openid-specs-ab-bounces at lists.openid.net<openid-specs-ab-bounces at lists.openid.net>
> ] *On Behalf Of *John Bradley
> *Sent:* Tuesday, October 29, 2013 7:33 PM
> *To:* Mike Jones
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Nonce value suggestion for the Implicit
> Flow
>
> You want to store the random value and send the hash. Saving the hash
> is not secure unless it is signed.
>
> The idea is to force an attacker to compute a plaintext for the hash
> (hard to impossible depending on length) in order to be able to present the
> response from the AS.
>
>
> For case 1: The Client can generate a random value with sufficient
> entropy and store that value in local storage. This value is then hashed
> to produce a nonce value. The hashed value could optionally be truncated
> to a sufficient number of bits (such as 128) before use.
>
> On Oct 29, 2013, at 9:40 PM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
>
>
>
> Here’s an attempt at simplifying George’s text.
> For case 1: The Client can generate a random value with sufficient
> entropy and store a cryptographic hash (such as SHA-256) of that value in
> local storage. The hashed value could optionally be truncated to a
> sufficient number of bits (such as 128) before use. The stored value is
> used as the nonce value.
> For case 2: The Client can generate a random value with sufficient
> entropy and store that value as an HttpOnly session cookie. A
> cryptographic hash (such as SHA-256) of the cookie value (or a truncation
> of the hash value to a sufficient number of bits) is used as the nonce
> value.
>
> Am I correct that the cryptographic hash function is used to spread the
> entropy present in the random value generated throughout the nonce value in
> both cases?
>
> Comments?
>
> -- Mike
>
> *From:* Richer, Justin P. [mailto:jricher at mitre.org <jricher at mitre.org>
> ]
> *Sent:* Saturday, October 26, 2013 11:33 AM
> *To:* George Fletcher
> *Cc:* John Bradley; Mike Jones; openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Nonce value suggestion for the Implicit
> Flow
>
>
> I don't know where the best place is to provide this guidance. If we
> have a "validating the ID Token" sub-section in the new ID Token section,
> then maybe it would best fit there.
>
>
> +1 to this idea with a cross link from the nonce definition.
>
> -- Justin
>
>
> On Oct 25, 2013, at 6:17 AM, George Fletcher <gffletch at aol.com> wrote:
>
>
>
> If we are going to give guidance, then we really need to give guidance for
> two different use cases...
>
> 1. The "client" will validate the response locally in the browser
> 2. The "client" will validate the response at it's server (even though
> it's using the implicit flow)
>
> For use case 1: One method to achieve this is for the client to generate a
> random string with sufficient entropy and store a SHA-1 hash of the string
> in local storage. Then use the SHA-1 hash of the random string as the value
> of the nonce parameter. To validate the nonce on receipt of the ID Token,
> extract the nonce from the ID Token and compare it to the stored SHA-1 hash
> in local storage.
>
> For use case 2: One method to achieve this is for the backend server to
> use a SHA-1 hash of the "clients" protected session cookie as the value of
> the nonce parameter when constructing the AuthorizationRequest. Note that
> the Session cookie SHOULD be protected (restricted to SSL and not readable
> by JavaScript) for this method. To validate the ID Token at the server, the
> server calculates a SHA-1 hash of the Session cookie value and compares
> that to the nonce value in the ID Token.
>
> I don't know where the best place is to provide this guidance. If we have
> a "validating the ID Token" sub-section in the new ID Token section, then
> maybe it would best fit there.
>
> Thanks,
> George
> On 10/24/13 7:16 PM, John Bradley wrote:
>
> We want the implicit flow to validate nonce, it would be better to have
> some reasonable advice for using HTML local storage rather than session
> cookies.
>
> On 2013-10-24, at 3:44 PM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
>
>
> We could drop it from the Implicit Flow, as it’s already present in the
> Code Flow. Does that work for people?
>
> -- Mike
>
> *From:* Richer, Justin P. [mailto:jricher@ <jricher@>mitre.org]
> *Sent:* Thursday, October 24, 2013 12:56 PM
> *To:* Mike Jones
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Nonce value suggestion for the Implicit
> Flow
>
> I'm actually in favor of dropping this example, or else providing it in
> a list of alternatives. The important thing is that the client can validate
> the exact value of the nonce parameter on its way back through, the
> mechanics of how that happens are client specific (but we can provide
> simple guidance).
>
> -- Justin
>
> On Oct 24, 2013, at 11:44 AM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
>
>
>
> For the Implicit Flow, the “nonce” description contains this text at
> http://openid.bitbucket.org/openid-connect-core-1_0.html#ImplicitAuthorizationRequest
> :
> Sufficient entropy MUST be present in the nonce values used to prevent
> attackers from guessing values. One method to achieve this is to store a
> random value as a signed session cookie, and pass the value in thenonce parameter.
> In that case, the nonce in the returned ID Token can be compared to the
> signed session cookie to detect ID Token replay by third parties.
>
> George wrote this about the suggestion in his review:
> “I'm not sure this suggestion makes sense for the implicit flow. The
> client would need to write a cookie value on the domain of the redirect_uri
> and the attempt to read it on the return of the implicit flow. Wondering if
> a local storage example would make more sense.”
>
> Do people agree with him? If so, does someone want to supply specific
> alternative text to use?
>
> -- Mike
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
> _______________________________________________
>
>
>
>
>
> Openid-specs-ab mailing list
>
> Openid-specs-ab at lists.openid.net
>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
> --
> <XeC.png> <http://connect.me/gffletch>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
>
> Openid-specs-ab mailing list
>
> Openid-specs-ab at lists.openid.net
>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
> --
> <XeC.png> <http://connect.me/gffletch>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131115/bfa1d992/attachment.html>
More information about the Openid-specs-ab
mailing list