[Ballot discuss]
[Note that I am not requesting any changes at this time!  I am interested in discussing this
issue (with authors, chairs, and other ADs) to determine if it merits action...]

The Management-Privilege-Level Attribute supports differentiated privilege levels denoted by integer values.  The specification notes that "specific access rights conferred by each value are
implementation dependent".

Almost inevitably, implementations begin by assigning values in ascending or descending order
but find a need to assert a new privilege level in the middle at a later date.  That works fine with
this specification, but product vendors sometimes make an assumption that this will be ordered.

I wonder if a brief addition to the security considerations noting that vendors should not assume
ordering for these values would be worthwhile?

[Ballot comment]
I find it unfortunate that the document does not define
an attribute to distinguish SSH and other forms of
command line protocols from each other. Or has such an
attribute already been defined somewhere else?

The document is silent on exactly how authentication
from, say, SCP or is actually represented in RADIUS.
Perhaps that is obvious? (But aren't there non-trivial
details, depending on what kind of challenge or password
mechanism is in use?) Or is authorize-only used?

I support Pasi's Discuss.

[Ballot comment]
I find it unfortunate that the document does not define
an attribute to distinguish SSH and other forms of
command line protocols from each other. Or has such an
attribute already been defined somewhere else?

[Ballot discuss]
This spec is overall in very good shape. However, I had the following
problems:

Section 5.3 says on Management-Policy-Id attribute:

  The Text field is one or more octets, and its contents are
  implementation dependent.  It is intended to be human readable and
  MUST NOT affect operation of the protocol.  It is RECOMMENDED that
  the message contain UTF-8 encoded 10646 [RFC3629] characters.

The statement about not affecting the operation of the protocol is
at least misleading and confusing and likely also factually wrong.
Like the document states earlier:

  If the NAS supports this attribute, but the
  policy name is unknown ... the NAS MUST treat
  the Access-Accept packet as if it had been an Access-Reject.

So the contents of the field can actually have an effect even
at the RADIUS level. I would suggest saying something else, e.g.,

  It is intended to be human readable and the contents MUST NOT be
  parsed by the receiver; the contents can only be used to look up
  locally defined policies.

[Ballot discuss]
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?

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

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

[Ballot comment]
In the Gen-ART Review by Vijay Gurbani on 11-Nov-2008, he asked a
  question:

  S5.3: Below the figure, the Length is shown as ">= 3".  However,
  the Text field expects "one or more octets..."  Should not the
  Length then be ">= 1"?

[Ballot comment]
>                                    |    |    |SHLD| MUST|    |
>    Attribute Name        Value Type |MUST| MAY | NOT|  NOT|Encr|

  Don't abbreviate RC2119 terms: s/SHLD/SHOULD/.

IANA Last Call comments:

Action #1:
Upon approval of this document, the IANA will make the following
assignments in the "Radius Types" registry located at
http://www.iana.org/assignments/radius-types

Value Description Reference
----- + ----------- + ---------

TBD (likely 124) + Framed-Management-Protocol +
[RFC-radext-management-authorization-06]
TBD (125) + Management-Transport-Protection +
[RFC-radext-management-authorization-06]
TBD (126) + Management-Policy-Id + [RFC-radext-management-authorization-06]
TBD (127) + Management-Privildege-Level + [RFC-radext-management-authorization-06]

Action #2:
Upon approval of this document, the IANA will make the following
assignments in the "Values for RADIUS Attribute 6, Service-Type"
sub-registry at
http://www.iana.org/assignments/radius-types

Value Description Reference
----- + ----------- + ---------
TBD (18) + Framed-Management + [RFC-radext-management-authorization-06]

Action #3:
Upon approval of this document, the IANA will create the
sub-registry "Values for RADIUS Attribute TBD (125),
Framed-Management-Protocol" at
http://www.iana.org/assignments/radius-types

Initial contents of this sub-registry will be:
Value Description Reference
----- + ----------- + ---------
1 + SNMP + [RFC-radext-management-authorization-06]
2 + Web-based + [RFC-radext-management-authorization-06]
3 + NETCONF + [RFC-radext-management-authorization-06]
4 + FTP + [RFC-radext-management-authorization-06]
5 + TFTP + [RFC-radext-management-authorization-06]
6 + SFTP + [RFC-radext-management-authorization-06]
7 + RCP + [RFC-radext-management-authorization-06]
8 + SCP + [RFC-radext-management-authorization-06]

Action #4:
Upon approval of this document, the IANA will create the
sub-registry "Values for RADIUS Attribute TBD (126),
Management-Transport-Protection" at
http://www.iana.org/assignments/radius-types

Initial contents of this sub-registry will be:
Value Description Reference
----- + ----------- + ---------
1 + No-Protection + [RFC-radext-management-authorization-06]
2 + Integrity-Protection + [RFC-radext-management-authorization-06]
3 + Integrity-Confidentiality-Protection + [RFC-radext-management-authorization-06]

We understand the above to be the only IANA Actions for this document.

Title: RADIUS Authorization for NAS Management
I-D:
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-05.txt

Status: Proposed Standard

Response to template:

1) Have the chairs personally reviewed this version of the ID and do
they believe this ID is sufficiently baked to forward to the IESG
for publication?

Yes.

2) Has the document had adequate review from both key WG members and
key non-WG members? Do you have any concerns about the depth or
breadth of the reviews that have been performed?

Yes. The ID has had 2 working group last calls.

3) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No concerns. The document has been reviewed both by the ISMS WG
as well as by RADEXT WG.

4) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For example,
perhaps you are uncomfortable with certain parts of the document,
or whether there really is a need for it, etc., but at the same
time these issues have been discussed in the WG and the WG has
indicated it wishes to advance the document anyway.

No.

5) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with
it?

There is solid consensus behind this document. 7 people other
than the author have commented on various aspects of the
document. The issues raised, available for inspection at
http://www.drizzle.com/~aboba/RADEXT/, were resolved in the -04
version of the document.

6) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.

No.

7) Have the chairs verified that the document adheres to _all_ of the
ID nits? (see http://www.ietf.org/ID-nits.html).

Yes. An output of the run on this revision of the ID by the online nits
checker:

idnits 2.08.10

tmp/draft-ietf-radext-management-authorization-05.txt:

Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to http://www.ietf.org/ID-Checklist.html:
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
No issues found here.
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)

No issues found here.
No nits found.
--------------------------------------------------------------------------------

8) Does the document a) split references into normative/informative,
and b) are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear state?
(Note: the RFC editor will not publish an RFC with normative
references to IDs, it will delay publication until all such IDs are
also ready for publication as RFCs.)

The document splits references into normative and informative ones.
There are no normative references to IDs.

9) For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following
sections:

- Technical Summary

This document specifies RADIUS attributes for authorization and
service provisioning of Network Access Server (NAS) management.
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.

- Working Group Summary

There have been 2 WGLCs on the document. Much of the discussion on
the document has centered around the model for provisioning of
protected transports, as well as the different remote administration
mechanisms (secure and insecure) to be supported. There has also
been discussion of the relationship between Framed Management
(introduced in this draft) and the pseudo-TTY management model
supported in RFC 2865.