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

[Bernard Aboba <aboba@internaut.com>]

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

Typically, the way that this kind of problem is solved is via addition of 
session identification attributes, such as the Acct-Session-Id, NAS-Port 
or NAS-Port-Id.  Is a NAS-Port/NAS-Port-Id Attribute likely to be 
available in the case of a management session (local or remote)?  This is 
not clear to me. If an Acct-Session-Id exists, this is probably the 
cleanest way to solve the problem.  

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

Another way to solve the problem is to specify that one or more of the 
above session identification attributes SHOULD be present in a management 
Access-Request.  That way those attributes are likely to be available for 
session identification in the event that dynamic authorization is needed. 

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

I think it might be worthwhile to add a section on dynamic authorization, 
clarifying what session identification attributes SHOULD be included in an 
Access-Request.  Assuming we do this, then the remaining use of 
Framed-Management-Protocol and Management-Transport-Protection in a 
CoA-Request would be as a wildcard.  As you say, this kind of use will 
probably not be mainstream - which raises the question of whether putting 
it in is worth the interoperability issues it might end up raising. 

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