RE: digest-auth, nonce replay issue

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

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

> Glen wrote
>> 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. 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.
> 
> If I remove the IPSec-condition, I am sure somebody will complain
> about it. 

If they complain, let them tell how to verify whether or not the condition has been met; if they cannot, their complaint has no validity.

> In an earlier version, I used the phrase 'protected'
> instead of IPSec which would have included future mechanisms, like
> RADIUS attribute encryption.   
> On request of the WG, this was replaced with IPSec.

Of course: this being the RADIUS Extensions WG, the last thing we would want is actual extensibility...

> 
> The above section of the draft is already hard to read, so I will add
> something to the referenced Security Considerations, like: 
> 
> 'Some parameter combinations require the protection of the RADIUS
> packet against eavesdropping and tampering. Implementations SHOULD
> try to determine automatically whether RADIUS packets will be sent
> and received over IPSec. If this is not possible, the implementation
> checks a configuration parameter telling it whether RADIUS traffic
> will be protected with IPSec. It must be explicitly set by the
> operator. The default value of this parameter tells the
> implementation that the RADIUS packet will not be protected.'

Unfortunately, this still says very little about the actual state of IPSec at the time the packets are transmitted or received, which is the condition you are checking.  If you make this change, you should also note this in the Security Considerations section, & change the condition(s) from "The packets between RADIUS client and RADIUS server are protected with IPsec (see Section 9)." or similar to "IPSec is configured to protect traffic between the RADIUS client and RADIUS server (see Section 9)." or similar. 
      
> 
> 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/>