[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 79; digest-auth realm validation
> -----Original Message-----
> From: Avi Lior [mailto:avi@bridgewatersystems.com]
> Sent: Wednesday, March 30, 2005 6:57 AM
> To: Salowey, Joe; Avi Lior; radiusext@ops.ietf.org
> Cc: Beck01, Wolfgang
> Subject: RE: Issue 79; digest-auth realm validation
>
> Hi Joe,
>
> I just have a comment on this bit:
>
> > [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.
>
> Well, this is not part of what RADIUS does. Its not part of
> the protocol.
> The only thing in the protocol is the shared secret. RADIUS
> can only validate that its talking with a client that is
> shares a secret with. So there is nothing we can do in the
> protocol. And furthermore RADIUS and Diameter for that
> matter are hop by hop protocols.
>
[Joe] RADIUS protocol doesn't typically allow for long term sensitive
information to be passed from the RADIUS server to the RADIUS client.
Perhaps RADIUS should not be used in this way if it cannot support this
kind of authorization.
> Having said this any prudent deployment of RADIUS already
> does or should do what you say.
>
> IMO the only thing that we can say is: state the problem and
> what a RADIUS deployment should do.
>
[Joe] OK, I think it would be acceptable to leave the description to the
security considerations section.
>
> > -----Original Message-----
> > From: Salowey, Joe [mailto:jsalowey@cisco.com]
> > Sent: Tuesday, March 29, 2005 11:41 PM
> > To: Avi Lior; radiusext@ops.ietf.org
> > Cc: Beck01, Wolfgang
> > Subject: RE: Issue 79; digest-auth realm validation
> >
> >
> >
> >
> > > -----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/>