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

[<Pasi.Eronen@nokia.com>]

Dave Nelson wrote:

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

The situation for Access-Accept (the important part) is clear, and 
I guess for the hints in Access-Request, we can leave it
implementation-specific... (like many other parts in RADIUS :-)

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

Looks good!

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

Could you provide pointers to the RADEXT mailing list discussions?  
I couldn't find anything in the archive, and the IETF74 minutes don't
mention anything either.

To the degree the source IP/port is just for human consumption
(e.g. troubleshooting or forensics), it's probably OK to leave the
contents implementation-specific. 

But if they're used for something else, to me it seems that this draft
would be the right place to make some recommendations (not necessarily
requirements that would update 2865/2869) for the management 
protocols listed here. (Not for any other use of RADIUS, of course.)

Best regards,
Pasi

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