RP generated nonce for stateful mode.

[NISHITANI Masaki]

It may be preferable to call this user-sesson-handle or so 
because this only valid in the same session between a 
end-user and a RP.

So it looks capable to prevent replay attacks without a 
nonce. It is true that a bad person who steals every values 
in a auth_res, can easily duplicate the message and send it 
to the RP. But the RP should not accept this assersion for 
its user-sesson-handle will not match to the the caliculated 
  value with the session-id.

Or, if the bad person has the session-id as well, it means 
the session has beed hijacked already and thus any effort 
brings no effect.

My understanding for the reason why the OP is defined to 
issue the nonce is to simplify the protocol adopting same 
parameters for both modes, stateful and stateless.
Is this right?

Dick Hardt wrote:
> 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
>>
>>
>