RE: Follow up on Authorize Only issue

["Avi Lior" <avi@bridgewatersystems.com>]

Well I am not exactly against using an Authorize Only in this way.

I do recognize that there is a severe security issue.

However, I still think designers need to be aware of the issues and
design appropriately.

We in the IETF need to make sure that designers are aware of the
security risk of a particular feature.  That is afterall what the
Security section is about.

 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Sunday, July 23, 2006 5:31 PM
> To: aland@nitros9.org
> Cc: isms@ietf.org; radiusext@ops.ietf.org
> Subject: Re: Follow up on Authorize Only issue
> 
> >A compromised NAS can leverage this requested feature to obtain that 
> >information more readily.  Right now, if the NAS hasn't had 
> a user log 
> >in through it, it can get those credentials only through a 
> brute force 
> >attack on the password.  The server *should* be able to catch that 
> >attack, mitigating the vulnerability.
> 
> Right.
> 
> > > If this is allowed, it should follow the principle of "least 
> > > privilege", only providing the attributes relevant to SSH.
> >
> >Which means that the Access-Request has to be recognizable 
> as for SSH 
> >in this use-case.  This means an attribute or value specifically for 
> >this purpose.  The RADIUS server can then key off of that special 
> >request, and return a limited response.
> 
> Right.  For example an additional Service-Type value of "SSH" 
> could be allocated One concern would be whether an attacker 
> could use this Service-Type with any NAS-Port-Type, in order 
> to retrieve attributes relevant to that NAS-Port-Type.  To 
> prevent this,  one possibility is to add NAS-Port-Type values 
> of "SSH" and "ISMS" (since different attributes might be 
> returned for a straight SSH or SSH-protected ISMS session) 
> and only allow Service-Type="SSH" to be used with those 
> NAS-Port-Type values; all other NAS-Port-Type values would 
> result in an Access-Reject.
> 
> >The use case should also enumerate the possible attributes 
> and values 
> >needed in the Access-Accept, and state explicitely that 
> responding with 
> >any other attributes or values may result in security 
> violations.  i.e. 
> >Other attributes and values SHOULD NOT be sent in the Access-Accept.
> 
> Makes sense.
> 
> 
> 
> --
> 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/>