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

From: Bernard Aboba <[email-masked]>
Date: Thu, 10 Jul 2008 23:38:09 -0700 (PDT)

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 11 Jul 2008 08:28:34 -0400

> when this might be used, so wanted to make sure we understand what the

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.

> activated for all web-based management sessions currently active on a

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.

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

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

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

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 11 Jul 2008 06:52:54 -0700 (PDT)

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

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. 

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

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 11 Jul 2008 12:18:33 -0400

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

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 11 Jul 2008 12:27:54 -0700 (PDT)

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

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 11 Jul 2008 15:48:16 -0400

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

I can remove the Framed-Management-Protocol and
Management-Transport-Protection Attributes from usage as "session
identifiers" for Dynamic Authorization and quote chapter and verse from RFC
5176 as to what SHOULD be used as "session identifiers".

I think that will cover the "80% problem" without introducing too many
opportunities for odd behaviors and wild-card usages.

The only reason that I could see for a NAS to not include the appropriate
session identifier attributes in an Access-Request message would be if the
NAS implementation didn't assign identifiers until it processed the
Access-Accept message, i.e. didn't want to assign IDs to sessions that may
never materialize, or the NAS implementation didn't support RADIUS
accounting, and thus had no notion of session identifiers.

Do we need to add some wiggle room to cover those corner cases?

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 11 Jul 2008 16:06:53 -0400

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

OK, I don't know what typical NAS implementations use for NAS-Port and/or
NAS-Port-Id for remote connections, e.g. when the NAS-Port-Type is Virtual.

I could imagine that they might use a number of things.  Remote IP address
and Remote TCP Port are one possibility.  The file descriptor value for use
with the open socket might be another.  By definition, the values are
transient, or if the value is not transient, the status of the particular
virtual port instance they describe certainly would be.  I suppose that what
would be important is that the NAS *has* some unique and meaningful values
for those attributes, valid for the duration of the remote management
session.

> If an Acct-Session-Id exists, this is probably the

Yes.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 11 Jul 2008 20:16:14 -0700 (PDT)

> for those attributes, valid for the duration of the remote management

Right.  The issue isn't so much how they fill in the values, but that they 
need to include *some* kind of port and session identification if dynamic 
authorization is to work well.  This might not be obvious to readers.