[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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/>