RE: digest-auth, nonce replay issue

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

wolfgang.beck01@t-online.de <mailto:wolfgang.beck01@t-online.de> supposedly scribbled:

...

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

That's why you have to specify the required level of clock synchronization...

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

AFAIK, it wasn't.

> 
> 
> Wolfgang

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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