RE: Questions about RfC3310 and RADIUS HTTP-Digest

[<Pasi.Eronen@nokia.com>]

Hi,

One advantage of RADIUS-server-generated nonces is that the
RADIUS client (SIP server/NAS/whatever) can't replay old
exchanges to the AAA server.

That might be useful for normal Digest authentication too,
especially in roaming situations (i.e., RADIUS client and 
server don't belong to the same operator). But it does
add a roundtrip, which might be bad..

Best regards,
Pasi

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Beck01, Wolfgang
> Sent: Friday, April 16, 2004 10:32 AM
> To: jari.arkko@piuha.net; radiusext@ops.ietf.org
> Subject: Questions about RfC3310 and RADIUS HTTP-Digest
> 
> 
> Jari,
> 
> while preparing the -02 version of the sterman draft, I 
> discovered that it would take an additional message exchange 
> to handle AKA. In the previous versions of the draft, nonces 
> where only generated by the RADIUS client. Assuming that 
> authentication vectors are user-specific, this would
> not work with AKA. So I included an optional message 
> exchange. However, after re-reading my changes, the 
> word "optional" turned up quite frequently.
> A bad thing in a standard.
> 
> - Do we need RADIUS server generated nonces in other 
> scenarios than AKA?
> - Would it be better to put RADIUS AKA Digest into a separate
>   (informational) document?
> 
> Wolfgang

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>