RE: Issue 79; digest-auth realm validation

[Avi Lior <avi@bridgewatersystems.com>]

Hi,

See comments inline.

> -----Original Message-----
> From: Salowey, Joe [mailto:jsalowey@cisco.com] 
> Sent: Monday, April 04, 2005 1:09 PM
> To: Beck01, Wolfgang; aboba@internaut.com
> Cc: radiusext@ops.ietf.org
> Subject: RE: Issue 79; digest-auth realm validation
> 
> 
>  
> 
> > -----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. "

So you intend that servers in the proxy chain to the check?  If yes that is
not always possible.  Some servers are truly pass through.

Instead of sending an Access Reject I think we should silently discard.
However, the penalty of doing so is that the Client will never know why and
its not receiving an Access-Accept or Access-Reject and if it is simply a
misconfigured client it will turn off that RADIUS server.  Also note that no
one is proposing to use put in a reason in the Access-Reject as to why we
are rejecting.

I think that the actions such as informing the operator is informative text
and not normative text and therefore we should use lowercase "SHOULD".

Note that the IMO the whole discussion should be included in the security
section.    


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

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