On 26-Jun-06, at 12:20 PM, Eric Rescorla wrote:
Dick Hardt <[EMAIL PROTECTED]> writes:
On 23-Jun-06, at 9:17 PM, Eric Rescorla wrote:
In DIX, the RP includes a nonce in the request, which must then
also
be in the nonce which would prevent replay attacks assuming the
RP is
managing nonce state would it not?
Only if each authentication token is only single-use. Otherwise,
an attacker can replay it during the validity period. Even then,
cut-and-paste attacks are still possible if you block the
initial request.
My understanding of the definition of a nonce is that it is single-
use.
Would you humour me with an explanation of a cut-and-paste attack per
above?
So, let's take the diagram from my recent mail message:
User RP IdP
---- -- ---
Sell me beer ->
<- Prove you're 21
IdP, help me! ->
<---------- Auth exchange ------------->
<- Credential
Credential ->
<- OK
The IdP gives the User some credential that he gives the
RP. That's fine for the first request, but what happens when
the user wants to make a second request? You clearly don't
want to go back to the IdP every time. The classic solution
is for the server to give you some cookie: those cookies
can obviously be cut-and-pasted from one message to another.
Even if you make them single-time (evolve them every time)
there's a window between the cookie delivery (in the HTTP
response) and the next HTTP request.
Another option is to bypass the cookie thing and just make
the Credential reusable, but this has the same problem...
Thanks Eric. Very useful to understand.
This seems to be a more general issue of securely managing state over
HTTP would it not?
-- Dick
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
