RP generated nonce for stateful mode.

Dick Hardt dick at sxip.com
Wed Nov 21 04:32:09 UTC 2007


You point out the issue. A hash of the session-id is NOT a nonce. A  
nonce is required to prevent replay attacks.

-- Dick

On 19-Nov-07, at 8:19 PM, NISHITANI Masaki wrote:

> Hi everyone.
>
> OpenID 2.0 uses nonce generated by OP to identify the
> transaction. This seems very reasonable for stateless mode
> authentication, because OP is the entity which is
> responsible for protecting the stateless mode transaction
> from replay-attacks. In this case, it is not so difficult
> for OP to control nonce not to be used twice.
>
> On the other hand, for stateful mode, OP generated nonce is
> also used and RP assures the nonce should be uses only once
> this time.
> In general, it costs more for someone other than the
> generator to ensure using nonce once, than the genetator
> itself does it. Also in this case, RP should remenber every
> nonces during certain time referring timestamp on each nonce.
>
> Using RP generated nonce could simplify this. For example,
> RP only caliculate a hash value for the end-users session-id
> and send this to OP in auth_req. Then OP signs to the
> RP-genetated-nonce and send it back in auth_res, now RP can
> verify the sign with the session-id very easily. RP and OP
> do not need to remember nonces.
>
> Of cource this is not a nonce in strict meaning, and can be
> used more than once. But that parameter is valid only in the
> end-user's session. So if someone want to use the value for
> replay-attack, it should hijacks the session beforehand.
>
> So I wonder if this kind of idea has been discussed before
> or not, and if it has.
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>




More information about the specs mailing list