RE: digest-auth, nonce replay issue

["Nelson, David" <dnelson@enterasys.com>]

Wolfgang beck writes...

> During the IESG review Glen Zorn pointed out, that the draft 
> allows a nonce replay attack as the RADIUS server can't tell 
> how old a nonce is.
> 
> So I've added some sentence like 'the nonce MUST contain some
> kind of timestamp'.  Just before submitting -07, it dawned to 
> me that this is not sufficient.
> 
> In scenario 1, the RADIUS client communicates the nonce to 
> the RADIUS server.  As generator and consumer of the nonce are
> not the same system, we need to define a nonce format. 
> RfC 2617 proposes
> 
> time-stamp H(time-stamp ":" ETag ":" private-key)
> 
> This is fine, but many HTTP-style messages don't have an 
> ETag header. Even if there is one, the RADIUS server can't 
> check it as there is no RADIUS attribute for ETag.
> We might structure the nonce mentally in two parts:
> 
> 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 authenticity 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.
> 
> Is the granularity of minutes sufficient?

Time is ticking, and the IESG is waiting for a revised draft before
completing their review.  Would everyone on this WG list, who has an
interest in the Digest Authentication draft, please take a moment to
review this issue and respond to the list?  If we don't get any
responses, then maybe we can assume that no one needs this work?  :-)

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