RE: Issue 79; digest-auth realm validation

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

> -----Original Message-----
> From: Avi Lior [mailto:avi@bridgewatersystems.com] 
> Sent: Tuesday, March 29, 2005 11:34 AM
> To: Salowey, Joe; 'radiusext@ops.ietf.org'
> Cc: 'Beck01, Wolfgang'
> Subject: RE: Issue 79; digest-auth realm validation
> 
> Joe,
> 
> So I think I understand what the risk is -- based on the 
> previous emails that you sent.
> 
> But this still bothers me:
> 
> We could have text in the security section that says something to the
> effect: there is a security risk in that the NAS (or proxies 
> for that matter may obtaining digest hashes.
> 

[Joe] That would be good, but it should also discuss the issue of
authorization.

> It's a totally different thing to say that the RADIUS server 
> should authorize the NAS.  We don't have that concept in 
> RADIUS.  In RADIUS all clients are trusted via the shared secret.
> 

[Joe] When RADIUS is used in the typical network access case where all
RADIUS clients are essentially equivalent and the RADIUS servers
authorization is implicit and less important.  When RADIUS is used in
environments where the RADIUS clients provide different services and
start releasing longer term secret data it becomes a problem.  

> How do you propose that the client be authorized? And even if 
> you authorize the client it maybe a proxy, that is we don't 
> know what is the ultimate client in RADIUS.
> 

[Joe] If there is no proxy then the RADIUS server must maintain the
information associating a RADIUS Client to a set of realms.  In the case
of the proxies it would be the job of one of the proxies in the chain to
validate the authorization and reject the request if it is not
authorized. 


> 
> 
> 
> 
> > -----Original Message-----
> > From: Salowey, Joe [mailto:jsalowey@cisco.com]
> > Sent: Tuesday, March 29, 2005 1:11 PM
> > To: Beck01, Wolfgang
> > Cc: radiusext@ops.ietf.org
> > Subject: RE: Issue 79; digest-auth realm validation
> > 
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: Beck01, Wolfgang [mailto:BeckW@t-systems.com]
> > > Sent: Tuesday, March 29, 2005 7:11 AM
> > > To: Salowey, Joe
> > > Cc: radiusext@ops.ietf.org
> > > Subject: Issue 79; digest-auth realm validation
> > > 
> > > Joe,
> > > 
> > > here is a 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."
> > > 
> > > Does this resolve the issue?
> > > 
> > [Joe] There is also a need to authorize the application 
> server (radius
> > client) to prevent a RADIUS client from obtaining digest hashes (HA1
> > attribute) for another realm and from advertising a realm 
> that is not 
> > authorized to service.
> > 
> > "The RADIUS server MUST check if the RADIUS client making 
> > 	the request 
> > 	o  is authorized to act as part of the protection space 
> > 	   defined by the Digest-URI and Digest-Realm attributes
> >       If this check fails, the RADIUS server MUST send an
> > 	Access-Reject."
> >  
> > I'm not sure if it makes any sense to check the SIP-AOR 
> attribute.  If 
> > the SIP-AOR attribute is not part of the Digest calculation done by 
> > the server then I do not think it makes sense to check it.
> > 
> > 
> > 
> > > Wolfgang
> > > 
> > > --
> > > T-Systems International GmbH
> > > Technologiezentrum
> > > Next Generation IP Services and Systems
> > > +49 6151 9372863
> > > Am Kavalleriesand 3
> > > 64295 Darmstadt
> > > 
> > > 
> > > 
> > > --
> > > 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/>
> > 
> 
> --
> 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/>