RADEXT Issue 256 (NAS management Authorization)

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

> Abstract
> 
> The current text is a bit wordy.  How about this? 
> 
>   This document describes Remote Authentication Dial-In User 
>   Service (RADIUS) attributes for the authorization and service
>   provisioning of Network Access Servers (NASes).  Both local and
>   remote management are supported, with granular access rights
>   and management privileges.  Specific provisions are made for
>   remote management via framed management protocols, and for
>   specification of a protected transport protocol.

Sounds good to me.  Will fix on -03.

> Section 7.1
> 
> I don't think you need to repeat much of Section 5.6 of RFC 2865.
> Why not just reference it instead?  Here is some recommended text
> for this section:
> 
> 7.1.  Service-Type
>
>   The Service-Type attribute is defined in Section 5.6 of RFC 2865
>   [RFC2865].   This document defines a new value of the Service-Type
>   Attribute:
>
>      (TBA)     Framed-Management
>
>      The semantics of the Framed-Management service are as follows:
>
>      Framed-Management   A framed management protocol session should
>                          be started on the NAS.

OK.  Will revise on -03.

> Section 8.1
> 
>   The Framed-Management-Protocol attribute indicates the application-
>   layer management protocol to be used for framed management access.
>   It MAY be used in both Access-Request and Access-Accept packets.
> 
> Please add a sentence explaining the semantics in this usage.  For
> example, in the Access-Request I assume that this Attribute describes
> the protocol that the client is using for remote administration. 

Yes.
 
> What does it mean in an Access-Accept?

The same thing that any other service provisioning attribute means -- start
the described service for the user's connection.  Typically these things are
decided by the RADIUS Server based on the user's account profile information
and any relevant hint attributes.

> For example, what does the NAS do if the value in the Access-
> Accept is different from the protocol that is being used?  Does
> it disconnect?

Yes.  It would also disconnect if the provisioned service is not supported
in the NAS.

How about the following for clarifying text?

It is RECOMMENDED that the NAS include an appropriately valued
Framed-Management-Protocol attribute in Access-Request packet, indicating
the type of access being requested, when the user requests a form of remote
management via a framed management application protocol.  It is further
RECOMMENDED that the NAS include a Service-Type attribute with the value
Framed-Management (TBA) in the same Access-Request packet.  The RADIUS
Server MAY use these hint attributes in making its authorization decision.

The RADIUS Server MAY include a Framed-Management-Protocol attribute in an
Access-Accept packet that also includes a Service-Type attribute with a
value of Framed-Management, when the RADIUS Server chooses to enforce an
management access policy for the authenticated user, that dictates one form
of management access in preference to others.

When a NAS receives a Framed-Management-Protocol attribute in an
Access-Accept packet, it MUST deliver that specified form of management
access or disconnect the session.  If the NAS does not support the
provisioned management application-layer protocol, or the management access
protocol requested by the user does not match that of the
Framed-Management-Protocol attribute in the Access-Accept packet, the NAS
must treat the response packet as if it had been an Access-Reject.

> Section 8.2
> What packets can this attribute be included in?  Access-Request & 
> Access-Accept?

Yes.  Also Accounting-Request for session logging purposes.

> What are the semantics in each case?  For example, in an 
> Access-Request is this the level of protection that is being used?

Yes.  This will be communicated to the RADIUS Client from the respective
management application, to the extent that application is aware of the
protection level of its underlying transport.

> What if the value in an Access-Accept is different (e.g. higher)
> than that in use?  For example, if confidentiality & integrity is 
> being requested, but the session is protected with TLS and an 
> integrity-only ciphersuite?  Is the session dropped?

Yes.  Do we need clarifying text, such as I proposed for the
Framed-Management-Protocol attribute (see above)?

Such clarifying text might read as follows:

It is RECOMMENDED that the NAS include an appropriately valued
Management-Transport-Protection attribute in Access-Request packet,
indicating the level of transport protection for the management access being
requested, when that information is available to the RADIUS Client.  The
RADIUS Server MAY use this hint attribute in making its authorization
decision.

The RADIUS Server MAY include a Management-Transport-Protection attribute in
an Access-Accept packet that also includes a Service-Type attribute with a
value of Framed-Management, when the RADIUS Server chooses to enforce an
management access security policy for the authenticated user, that dictates
a minimum level of transport security.

When a NAS receives a Management-Transport-Protection attribute in an
Access-Accept packet, it MUST deliver the management access over a transport
with equal or better protection characteristics or disconnect the session.
If the NAS does not support protected management transport protocols, or the
level of protection available does not match that of the
Management-Transport-Protection attribute in the Access-Accept packet, the
NAS must treat the response packet as if it had been an Access-Reject.
 
>   o  Confidentiality-Protection: The management session requires
>      protection in a secure or protected transport, that is supported
>      by the management access protocol and implementation.  The secure
>      transport MUST provide Confidentiality Protection.
>
> Does this option really make sense?  When would you want Confidentiality
> but not integrity? Isn't this dangerous?

This was discussed at IETF-71 and the proposal was to remove the
Confidentiality (only) option.  I propose to do that in the -03 version.

> Section 9
> 
> The examples use the Transport-Protocol Attribute, which is not
> defined in this document any more.

Editorial cruft.  Will fix in -03.

>  Also, please include the value of NAS-Port-Type in the examples.

OK.

> Section 11
> 
> I'd recommend moving this to a sub-section under Security 
> Considerations.

Hmmm.  Much of this discussion has impact on security, on the other hand, I
think that Proxy Considerations is a separate topic that justifies treatment
in a separate section, for emphasis.  I don't have a strong opinion on this,
but my initial reaction is to suggest that we leave it in a separate
section.

> Section 13
> 
> This section needs to be rewritten to list the new attribute for which 
> numbers being requested, as well as the new value for Service-Type.

So, you're suggesting that I not expect IANA to search through the document
for all the (TBA) placeholders, but rather enumerate all the requests here?
OK, I can do that in version -03.

All other comments in Issue 256, not otherwise discussed here are accepted
and will appear in the -03 version.


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