Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management
RFC 5607
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14 |
07 | (System) | Notify list changed from radext-chairs@ietf.org, draft-ietf-radext-management-authorization@ietf.org to (None) |
2012-08-22 |
07 | (System) | post-migration administrative database adjustment to the No Objection position for Pasi Eronen |
2012-08-22 |
07 | (System) | post-migration administrative database adjustment to the No Objection position for Jari Arkko |
2012-08-22 |
07 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2009-07-30 |
07 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
2009-07-30 |
07 | Cindy Morgan | [Note]: 'RFC 5607' added by Cindy Morgan |
2009-07-27 |
07 | (System) | RFC published |
2009-06-15 |
07 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2009-06-15 |
07 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2009-06-15 |
07 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2009-06-12 |
07 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2009-06-12 |
07 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2009-06-11 |
07 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2009-06-10 |
07 | (System) | IANA Action state changed to In Progress |
2009-06-09 |
07 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2009-06-09 |
07 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2009-06-09 |
07 | Cindy Morgan | IESG has approved the document |
2009-06-09 |
07 | Cindy Morgan | Closed "Approve" ballot |
2009-06-09 |
07 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
2009-06-09 |
07 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
2009-06-01 |
07 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko |
2009-06-01 |
07 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen |
2009-05-31 |
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-05-31 |
07 | (System) | New version available: draft-ietf-radext-management-authorization-07.txt |
2009-04-16 |
07 | Dan Romascanu | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Dan Romascanu |
2009-01-30 |
07 | Russ Housley | [Ballot comment] |
2009-01-30 |
07 | (System) | Removed from agenda for telechat - 2009-01-29 |
2009-01-29 |
07 | Cindy Morgan | State Changes to IESG Evaluation::AD Followup from Waiting for AD Go-Ahead by Cindy Morgan |
2009-01-29 |
07 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2009-01-29 |
07 | Tim Polk | [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 … [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? |
2009-01-29 |
07 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2009-01-29 |
07 | Jari Arkko | [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 … [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. |
2009-01-29 |
07 | Jari Arkko | [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 … [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? |
2009-01-29 |
07 | Jari Arkko | [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 … [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. |
2009-01-29 |
07 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2009-01-29 |
07 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2009-01-29 |
07 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2009-01-28 |
07 | Pasi Eronen | [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 … [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.) |
2009-01-28 |
07 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
2009-01-28 |
07 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2009-01-28 |
07 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2009-01-28 |
07 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
2009-01-28 |
07 | Russ Housley | [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 … [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"? |
2009-01-28 |
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2009-01-28 |
07 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2009-01-27 |
07 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2009-01-27 |
07 | Lars Eggert | [Ballot comment] > | | |SHLD| … [Ballot comment] > | | |SHLD| MUST| | > Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| Don't abbreviate RC2119 terms: s/SHLD/SHOULD/. |
2009-01-27 |
07 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2009-01-22 |
07 | Dan Romascanu | Placed on agenda for telechat - 2009-01-29 by Dan Romascanu |
2009-01-22 |
07 | Dan Romascanu | [Ballot Position Update] New position, Yes, has been recorded for Dan Romascanu |
2009-01-22 |
07 | Dan Romascanu | Ballot has been issued by Dan Romascanu |
2009-01-22 |
07 | Dan Romascanu | Created "Approve" ballot |
2008-11-12 |
07 | Amanda Baber | 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 … 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. |
2008-11-11 |
07 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2008-11-11 |
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Steve Hanna |
2008-11-11 |
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Steve Hanna |
2008-10-28 |
07 | Cindy Morgan | Last call sent |
2008-10-28 |
07 | Cindy Morgan | State Changes to In Last Call from Last Call Requested by Cindy Morgan |
2008-10-28 |
07 | Dan Romascanu | State Changes to Last Call Requested from Publication Requested::AD Followup by Dan Romascanu |
2008-10-28 |
07 | Dan Romascanu | Last Call was requested by Dan Romascanu |
2008-10-28 |
07 | (System) | Ballot writeup text was added |
2008-10-28 |
07 | (System) | Last call text was added |
2008-10-28 |
07 | (System) | Ballot approval text was added |
2008-10-10 |
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-10-10 |
06 | (System) | New version available: draft-ietf-radext-management-authorization-06.txt |
2008-10-02 |
07 | Dan Romascanu | State Changes to Publication Requested::Revised ID Needed from Publication Requested by Dan Romascanu |
2008-07-14 |
07 | Cindy Morgan | 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 … 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. |
2008-07-14 |
07 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2008-07-14 |
05 | (System) | New version available: draft-ietf-radext-management-authorization-05.txt |
2008-07-11 |
04 | (System) | New version available: draft-ietf-radext-management-authorization-04.txt |
2008-06-13 |
03 | (System) | New version available: draft-ietf-radext-management-authorization-03.txt |
2008-02-25 |
02 | (System) | New version available: draft-ietf-radext-management-authorization-02.txt |
2007-11-19 |
01 | (System) | New version available: draft-ietf-radext-management-authorization-01.txt |
2007-08-23 |
00 | (System) | New version available: draft-ietf-radext-management-authorization-00.txt |