Re: digest-auth, nonce replay issue

[wolfgang.beck01@t-online.de]

Glen Zorn wrote:
> > nonce = concat(time-stamp, H(time-stamp ":" private-key), = second-part)
> >
> > time-stamp = minutes since Epoch in hexadecimal, padded to 8 digits
> >               second-part arbitrary data that might be interpreted
> > by the nonce generator to check the authencity of the nonce.
> >
> > One could argue that private-key is useless as Glen's attack requires
> > that the attacker has full access to the RADIUS client.
>
> Maybe not: I think that it is only necessary for the attacker to be 
> capable of eavesdropping on the conversation between the RADIUS client & 
> server & then masquerading as the client later, possibly by replaying 
> the Access-Request.
>
RADIUS server and client must use IPSec in the relevant mode anyway,
but as the nonce is sent in the clear between HTTP-style client and RADIUS
client, I think it should be protected.

> >
> > Is the granularity of minutes sufficient?
> 
> Depends upon the expected session length: are all (or a very high 
> percentage of) sessions expected to last more than a minute?  If so, 
> then one minute granularity is fine.  If you're going to use timestamps 
> you need to define the required level of clock synchronization between 
> the client and server...
> 
My intention was to use a 32 bit value that won't overflow in 2038 (the
German pension regulations are about to be changed, I might have still
to work then..).

As the Event-Timestamp attribute uses seconds, we can use seconds here
as well.

However, the RADIUS server has to trust the first timestamp it
receives from a RADIUS client. What if the RADIUS client's clock
is adjusted during operation?

In the IESG review, you mentioned a similar problem with CHAP. Do you
have some pointers how it was solved?


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/>