[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Question on draft-ietf-radext-management-authorization-04.txt
8. Table of Attributes
Change-of-Authorization Messages
Request ACK NAK # Attribute
--------------------------------------------------------------------
0-1 0 0 TBA-2 Framed-Management-Protocol (Note 1)
0-1 0 0 TBA-3 Management-Transport-Protection (Note 1)
0-1 0 0 TBA-4 Management-Policy-Id (Note 2)
0-1 0 0 TBA-5 Management-Privilege-Level (Note 2)
Disconnect Messages
Request ACK NAK # Attribute
----------------------------------------------------------------------
0-1 0 0 TBA-2 Framed-Management-Protocol (Note 1)
0-1 0 0 TBA-3 Management-Transport-Protection (Note 1)
0 0 0 TBA-4 Management-Policy-Id
0 0 0 TBA-5 Management-Privilege-Level
(Note 1) Where NAS or session identification attributes are included
in Disconnect-Request or CoA-Request packets, they are used for
identification purposes only. These attributes MUST NOT be used for
purposes other than identification (e.g., within CoA-Request packets
to request authorization changes).
[BA] Using the Framed-Management-Protocol and
Management-Transport-Protection attributes for session identification
would seem to imply the need to change the Management-Policy-Id and
Management-Privilege-Level attributes based on values of those
attributes, affecting multiple sessions. The text does not talk about
when this might be used, so wanted to make sure we understand what the
potential uses are.
Some possibilities that come to mind:
1. Change the Management-Policy-Id of all sessions with
Framed-Management-Protocol equal to a particular value.
A potential example might involve configuration of a new Management policy
for web-based management; a CoA-Request might be used to cause this to be
activated for all web-based management sessions currently active on a
particular NAS.
2. Change the Mangement-Privilege-Level of all sessions with
Management-Transport-Protection equal to a particular value.
A potential example might involve discovery of a vulnerability in a
particular Management transport (e.g. the GNU TLS vulnerability discovered
recently). To avoid the potential for compromise, dynamic authorization
might be used to lower the privileges of all sessions using that
protection mechanism, at least until a patch becomes available.
Do people think that these examples make sense?
Typically, dynamic authorization has been used to affect particular
sessions, but the changes in [RFC5176] now make it possible to affect
several sessions at once, using identification attributes, so discussions
like this are likely to become more common.
Here is what RFC 5176 Section 3 says about NAS and session
identificaiton attributes:
In Disconnect-Request and CoA-Request packets, certain attributes are
used to uniquely identify the NAS as well as user session(s) on the
NAS. The combination of NAS and session identification attributes
included in a CoA-Request or Disconnect-Request packet MUST match at
least one session in order for a Request to be successful; otherwise
a Disconnect-NAK or CoA-NAK MUST be sent. If all NAS identification
attributes match, and more than one session matches all of the
session identification attributes, then a CoA-Request or Disconnect-
Request MUST apply to all matching sessions.
. . .
To address security concerns described in Section 6.1, either the
User-Name or Chargeable-User-Identity attribute SHOULD be present in
Disconnect-Request and CoA-Request packets.
. . .
A NAS implementing this specification SHOULD send an Acct-Session-Id
or Acct-Multi-Session-Id Attribute within an Access-Request. Where
an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not included
within an Access-Request, the Dynamic Authorization Client will not
know the Acct-Session-Id or Acct-Multi-Session-Id of the session it
is attempting to target, unless it also has access to the accounting
data for that session.
Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not
present in a CoA-Request or Disconnect-Request, it is possible that
the User-Name or Chargeable-User-Identity attributes will not be
sufficient to uniquely identify a single session (e.g., if the same
user has multiple sessions on the NAS, or if the privacy NAI is
used). In this case, if it is desired to identify a single session,
session identification MAY be performed by using one or more of the
Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called-
Station-Id, Calling-Station-Id, NAS-Port, and NAS-Port-Id attributes.
--
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/>