RE: digest-auth, nonce replay issue

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

Beck01, Wolfgang <mailto:BeckW@t-systems.com> supposedly scribbled:

>> Searching about in the draft, I can't find any place where the words
>> "MUST" and "IPSec" appear in the same sentence
> You are right. I mixed it up with Digest-HA1.
> 
>> I do find several passages that assume that applications can know
>> whether or not the application traffic is protected by IPSec,
>> something that I was unaware was possible...
> The application can not detect if the password was posted on a
> mailing list either. 

However, your the draft doesn't say 

   o  If the Digest-Qop attribute's value is 'auth-int' and at least one
      of the following conditions is true, the RADIUS server SHOULD put
      a Digest-HA1 attribute into the Access-Accept packet:
      *  The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1-
         MD5-sess'.
      *  The password was not posted on a mailing list (see Section 9).
   In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be
   sent.

It does, however, say this:

   o  If the Digest-Qop attribute's value is 'auth-int' and at least one
      of the following conditions is true, the RADIUS server SHOULD put
      a Digest-HA1 attribute into the Access-Accept packet:
      *  The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1-
         MD5-sess'.
      *  The packets between RADIUS client and RADIUS server are
         protected with IPsec (see Section 9).
   In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be
   sent.

Since the second condition is, AFAIK, unverifiable, it would make sense to simply remove it as extraneous.  However, my guess is that it's there for a reason; therefore, I would advise making it depend upon a form of security that the RADIUS client/server can actually check.

> 
> For the argument's sake, an application could consult the local ipsec
> policy database and look if the RADIUS address quadruple is covered
> by an appropriate rule. I am aware that existing APIs are not
> sufficient here and VPN tunnels can't be discovered this way.   
> 
> A pragmatic approach would be to spell out a warning in the manual or
> in the syslog 'If you plan to use such and that option, make sure
> your RADIUS traffic is protected or you'll be doomed' 

The actual state of operation of IPSec is being used to determine the operation of Digest-Auth (either send an Attribute or don't), but that state cannot be used because it is undeterminable from the application layer.

> 
>>> 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... 
> I feel a bit uneasy about this. When some technician plays with the
> time zone, a whole SIP server won't be able to handle calls any
> longer.  

GMT/UCT.

> 
>> 
>> ...
>> 
>>> Hope this helps,
> It does.
> 
> 
> 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/>