[Openid-specs-ab] Nonce value suggestion for the Implicit Flow
Brian Campbell
bcampbell at pingidentity.com
Wed Nov 13 19:38:48 UTC 2013
"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 listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
> --
> [image: George Fletcher] <http://connect.me/gffletch>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131113/cbda1d39/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XeC
Type: image/png
Size: 80878 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131113/cbda1d39/attachment.png>
More information about the Openid-specs-ab
mailing list