RE: digest-auth, nonce replay issue

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

Beck01, Wolfgang <> supposedly scribbled:

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

Actually, the problem is that a valid response can be replayed, because the RADIUS server has no idea what the original nonce might have been, but I suppose it doesn't matter.

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

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

> 
> 
> Wolfgang
> 
> --
> T-Systems International GmbH
> Technologiezentrum
> Next Generation IP Services and Systems
> +49 6151 9372863
> Am Kavalleriesand 3
> 64295 Darmstadt

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