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

[Bernard Aboba <aboba@internaut.com>]

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

Right.  So I think we're talking about trying to dis-ambiguate a situation 
where there is a valid User-Name attribute, but perhaps multiple sessions 
associated with that.  It might be worth quoting some text from RFC 5176 
regarding the recommended NAS and session identification attributes, since 
it might not necessarily be obvious that an Access-Request for a 
management session should necessarily have a NAS-Port/NAS-Port-Id + 
Acct-Session-Id associated with it. 

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

Quoting from RFC 5176 would be sufficient. 

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