[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: digest-auth, nonce replay issue
firstname.lastname@example.org <mailto:email@example.com> 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.
Hope this helps,
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 firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.