[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Follow up on Authorize Only issue
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
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: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of Bernard Aboba
> Sent: Sunday, July 23, 2006 5:31 PM
> To: email@example.com
> Cc: firstname.lastname@example.org; email@example.com
> 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.
> > > 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
> firstname.lastname@example.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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.