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

["David B. Nelson" <dnelson@elbrysnetworks.com>]

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

I think RFC 5176 already says that.  But then it goes on to provide for
additional forms of session identifying attributes, for the cases when the
"SHOULD" doesn't apply.

> That way those attributes are likely to be available for session
> identification in the event that dynamic authorization is needed.

Indeed.  We *could* say that if your implementation doesn't follow the
"SHOULD" in RFC 5176 regarding the inclusion of session IDs, and the Dynamic
Authorization Client doesn't have the appropriate session ID attribute(s)
available, you're simply out of luck.

One of the use cases that motivate some of this behavior is the "privacy
NAI", i.e. anonymous (external) authentication, in which the RADIUS entities
don't have the actual user identity.  I think that makes sense for certain
forms of network access.  I can't imagine a valid use for anonymous
authentication for the purpose of NAS management, however.  :-)

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

As an "overlay" to the "SHOULD" in RFC 5176?

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

Right.



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