RE: Issue 79; digest-auth realm validation

[Avi Lior <avi@bridgewatersystems.com>]

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.

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.

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.





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