IESG review DISCUSS on draft-ietf-radext-management-authorization-06.txt

["Dave Nelson" <d.b.nelson@comcast.net>]

[IESG Evaluation DISCUSS] by Pasi Eronen

> I have reviewed draft-ietf-radext-management-authorization-06. Overall,
> the document looks good, but I have the following concerns that I'd like
> to discuss before recommending approval of the document:
> 
> The document recommends using Management-Privilege-Level only for
> Service-Type 7 (not 6). However, when the NAS receives, for example,
> an SSH connection, does it know whether the user is asking for full
> privilege access, or less privileged management access?  If it does
> not know, what should it do?

The NAS is not expected to know what level of access the user is "asking
for", other than perhaps that an SSH sub-system is involved.  That's purely
a matter of implementation detail, BTW, and is not being standardized.

The RADIUS server is expected to provision the appropriate level of access
for the user, based on the user's authorization profile stored in the
server's database (or otherwise obtained by the server). The server may use
optional (recommended) hint attributes in the Access-Request message that
identify the NAS in question and the type of interface used, e.g. a virtual
terminal connection, in conjunction with the user's authorization profile,
in making its access rights decision.

After discussion on the RADEXT mailing list and at IETF-74, it does not
appear that any change to the draft is required.

> Another question: should the document recommend something about
> Management-Privilege-Level values? For example, should bigger numbers
> mean "more access" or "less access"? (The actual levels are of course
> implementation dependent, but if vendors use opposite conventions, it
> seems that would create unnecessary confusion.)

There is no one convention used by all vendors, and in fact many
implementations allow the mapping of the integer access level to specific
access rights to be configured on the NAS by the user.

After discussion on the RADEXT mailing list and at IETF-74, the
recommendation is to clarify this issue by adding the following text to
Section 5.4 of the draft:

     The mapping of integer values for this attribute to specific
     collections of management access rights or permissions on the NAS
     is vendor and implementation specific.  Such mapping is often a
     user configurable feature.  It's RECOMMENDED that greater numeric
     values imply greater privilege.  However, it would be a mistake
     to assume that this recommendation always holds.

> It seems that a NAS implementing e.g. NETCONF, FTP or web-based
> management would often include the IP address (and perhaps port
> number) where connection came from in the Access-Request message.
> Should the document give some guidance on NAS-Port-ID (or perhaps
> Calling-Station-ID) attributes?  (It seems having at least a mild
> recommendation about the attribute and formatting would be useful,
> instead of every vendor doing things differently.)

Discussion on this issue on the RADEXT mailing list and at IETF-74 yielded
the following observations.  These attributes are not required for use in
management access by RFC 2865 and RFC 2869, and the authors don't think we
want this draft to update those RFCs.  The variation in the format of the
NAS-Port and Calling-Station-Id attributes among different implementations
has been an issue for a long time.  It's probably an interesting topic for a
separate work item, but likely doesn't belong in this draft.  It does not
appear that any change to the draft is required.


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