RE: Issue 79; digest-auth realm validation

["Salowey, Joe" <jsalowey@cisco.com>]

> -----Original Message-----
> From: Beck01, Wolfgang [mailto:BeckW@t-systems.com] 
> Sent: Monday, April 04, 2005 1:52 AM
> To: aboba@internaut.com; Salowey, Joe
> Cc: radiusext@ops.ietf.org
> Subject: Re: Issue 79; digest-auth realm validation
> 
> Here's a complete text proposal:
> 
>    The RADIUS server MUST check if the user identified by the 
> User-Name
>    attribute
>    o  is authorized to access the protection space defined by the
>       Digest-URI and Digest-Realm attributes,
>    o  is authorized to use the URI included in the SIP-AOR 
> attribute, if
>       this attribute is present.
>    If any of those checks fails, the RADIUS server MUST send an
>    Access-Reject.
> 
>    Correlation between User-Name and SIP-AOR AVP values is 
> required just
>    to avoid that any user can register or misuse a SIP-AOR 
> allocated to
>    another user.
> 
>    A RADIUS server MUST check if the RADIUS client is authorized to
>    serve users of the realm mentioned in the Digest-Realm 
> attribute.  If
>    the RADIUS client is not authorized, the RADIUS server sends an
>    Access-Reject.  The RADIUS server considers this client as
>    compromised.  It notifies the operator and rejects all future
>    requests from this client, until some management action tells it to
>    do so again.
> 
> Please send me a note if you have objections/additions about 
> this text so we can close the issue.

[Joe] As Avi mentioned in a previous message this gets a bit complicated
in a case where you have proxies under different administrative control.
In this case the AAA server that perfroms the digest auth may not have
detailed information about the client to realm authorization.  In this
case one of the intermediate proxies could be resposible for the
authorization check.  It might also be worthwile to warn about the use
of the digest-HA1 attribute and MD5 (vs. MD5-SESS) algorithm in the
security considerations.  Also I suppose that the action to reject is up
to the operator. Here are some suggested revisions:

   "A RADIUS server in the RADIUS proxy chain MUST check if the RADIUS 
   client is authorized to
   serve users of the realm mentioned in the Digest-Realm attribute.  If
   the RADIUS client is not authorized, the RADIUS server sends an
   Access-Reject.  The RADIUS server should consider this client as
   compromised.  It SHOULD notify the operator and MAY take additional 
   action such as rejecting all future
   requests from this client, until some management action tells it to
   do so again. "

In the security considerations section:

  "When used with the MD5 algorithm the digest-HA1 attribute contains
   a hash value that can be used by an attacker in a dictionary
   attack against the user's password.  This mechanism should only be 
   used in environments where there is sufficient trust in intermediate 
   RADIUS proxies and RADIUS client requests can be validated against 
   their authorized realm.  "


> 
> Wolfgang
> 
> --
> T-Systems
> Next Generation IP Services and Systems
> +49 6151 937 2863
> Am Kavalleriesand 3
> 64295 Darmstadt
> Germany 
> 

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