RE: Question on draft-ietf-radext-management-authorization-04.txt

["David B. Nelson" <d.b.nelson@comcast.net>]

> [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.

I did send the proposed table of attributes text in an e-mail to the list,
soliciting WG feedback, *before* I submitted -04.  However...   We're
getting that feedback now.

> 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.

I suppose.

The whole issue of using RADIUS attributes, other than the User-Name or one
of the session ID attributes, to identify one or more sessions seems pretty
murky to me.  I can see some scenarios where adding some "provisioning"
attributes into a request as further specification makes sense, however.
For example suppose there are three sessions with a User-Name of "dave", one
with a Service-Type of "NAS-Prompt", and two with a Service-Type of
"Framed-Management".  Of the latter two, one has a
Framed-Management-Protocol of "Web-based" and the other has a
Framed-Management-Protocol of "SNMP".  If you want to affect the web
session, you need to "address" the session either by an available session ID
attribute, which is preferable in my opinion, or by the value of
Framed-Management-Protocol, if the session ID information is not available.

> 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?

I think they make sense.  Whether they are within the bounds of "the 80%
problem" is another matter.

> 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.

Yes.  I've already indicated, above, that I think this extra flexibility can
be "murky" in its potential applications.

> 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.

It is in the sprit of this last paragraph that I proposed that some of the
management provisioning attributes, specifically Framed-Management-Protocol
and Management-Transport-Protection *could* be used to further identify one
session from another.  Unfortunately, that usage also allows any of these
"provisioning" attributes to be use alone (or in combination with others) to
form all sorts of interesting (maybe not useful) wild-card matches.

We can eliminate Framed-Management-Protocol and
Management-Transport-Protection from such usage in this document.  We can't
go back and clarify the "murkiness" that exists in RFC 5176 about using this
sort of wild-card matching when selecting one or more sessions for action.



--
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/>