RP generated nonce for stateful mode.

[Manger, James H]

The RP could put its own nonce in the openid.return_to URI. The signature from the OP covers this field.
I don’t think different return_to URIs for each request can have any negative consequences -- as long as an unchanging openid.realm is also included in the authentication requests.

-----Original Message-----
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf Of NISHITANI Masaki
Sent: Tuesday, 20 November 2007 3:19 PM
To: specs at openid.net
Subject: RP generated nonce for stateful mode.

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