idnits 2.17.1 draft-ietf-radext-management-authorization-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 755. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 766. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 773. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 779. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 18, 2007) is 6004 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Nelson 3 Internet-Draft Elbrys Networks, Inc. 4 Intended status: Standards Track G. Weber 5 Expires: May 21, 2008 November 18, 2007 7 Remote Authentication Dial-In User Service (RADIUS) Authorization for 8 Network Access Server (NAS) Management 9 draft-ietf-radext-management-authorization-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 21, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes Remote Authentication Dial-In User Service 43 (RADIUS) attributes for the authorization and service provisioning of 44 local and remote management of embedded systems and other managed 45 entities, generally referred to as Network Access Servers (NASes). 46 Specific provisions are made for remote management via framed 47 management protocols, and for granular levels of access rights and 48 management privileges. 50 Table of Contents 52 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction and Rationale . . . . . . . . . . . . . . . . . . 3 54 3. Provisions for Framed Management . . . . . . . . . . . . . . . 3 55 4. Provisions for Granular Management Access Rights . . . . . . . 4 56 5. Provisions for Secure Management Access . . . . . . . . . . . 4 57 6. New Values for Existing RADIUS Attributes . . . . . . . . . . 4 58 6.1. Service-Type . . . . . . . . . . . . . . . . . . . . . . . 4 59 7. New RADIUS Attributes . . . . . . . . . . . . . . . . . . . . 5 60 7.1. Framed-Management-Protocol . . . . . . . . . . . . . . . . 6 61 7.2. Management-Transport-Protocol . . . . . . . . . . . . . . 7 62 7.3. Management-Policy-Id . . . . . . . . . . . . . . . . . . . 8 63 7.4. Management-Privilege-Level . . . . . . . . . . . . . . . . 10 64 8. Examples of attribute groupings . . . . . . . . . . . . . . . 11 65 9. Diameter Translation Considerations . . . . . . . . . . . . . 13 66 10. RADIUS Proxy Operation Considerations . . . . . . . . . . . . 13 67 11. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 14 68 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 69 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 71 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 15.1. Normative References . . . . . . . . . . . . . . . . . . . 16 73 15.2. Informative References . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 75 Intellectual Property and Copyright Statements . . . . . . . . . . 19 77 1. Terminology 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119 [RFC2119]. 83 This document uses terminology from RFC 2865 [RFC2865] and RFC 2866 84 [RFC2866]. 86 2. Introduction and Rationale 88 The remote management Service-Types defined in RFC 2865 [RFC2865] 89 include NAS-Prompt and Administrative. Both of these services 90 provide access to the interactive, text-based, Command Line Interface 91 (CLI) of the managed entity. Current deployments of network 92 equipment include in the managed entity non-CLI, framed-protocol 93 forms of management, such as web browser based management (HTML over 94 HTTP), SNMP and NETCONF. In addition, network devices often support 95 more privilege levels for management access than the two levels 96 supported by NAS-Prompt (non-privileged) and Administrative 97 (privileged). To address these issues, attributes for framed 98 management protocols, management protocol security levels, and 99 management access privilege levels are described. 101 3. Provisions for Framed Management 103 Framed Management means management of an entity by means of a non- 104 interactive, non-CLI-style method. The management information is 105 typically formatted in a binary or textual encoding, such as HTML, 106 XML or ASN.1/BER. While remote management by interactive CLI 107 sessions is carried over protocols, such as Telnet, Rlogin, and SSH, 108 these protocols are primarily for the delivery of terminal, or 109 pseudo-TTY services. Command Line Interface, Menu Interface, or 110 other text-based (e.g. ASCII or UTF-8) terminal emulation interfaces 111 are not considered to be Framed Management protocols, as used in this 112 document. Examples of Framed Management protocols include web-based 113 management (HTML over HTTP), NETCONF (XML over HTTP/BEEP/SOAP) and 114 SNMP (SMI over ASN.1/BER). 116 To support the authorization and provisioning of Framed Management 117 access to managed entities, this document introduces a new value for 118 the Service-Type attribute [RFC2865], and one new attribute. The new 119 value for the Service-Type attribute is Framed-Management. The 120 definition of this service is the provisioning of remote device 121 management via a Framed Management protocol, as described in this 122 section. The new attribute is Framed-Management-Protocol, the value 123 of which specifies a particular protocol for use in the remote 124 management session. 126 4. Provisions for Granular Management Access Rights 128 Two new attributes are introduced in this document in support of 129 granular management access rights or command privilege levels. 131 The Management-Policy-Id attribute is used to contain the name of a 132 management access rights policy of local scope. This attribute 133 functions similarly to Filter-ID. It is a string variable containing 134 a policy name of local scope. The provisioning of the rules invoked 135 by application of this management policy is by means outside the 136 scope of this document, such as by MIB objects. 138 The local application of the Management-Policy-Id within the managed 139 entity may take the form of (a) one of an enumeration of command 140 privilege levels, (b) a mapping into an SNMP Access Control Model, 141 such as the View Based Access Control Model (VACM) table [RFC3415], 142 or (c) some other set of management access policy rules that is 143 mutually understood by the managed entity and the remote management 144 application. Examples are given in Section 8. 146 The Management-Privilege-Level attribute is used to contain an 147 Integer-valued management privilege level indication. This attribute 148 serves to modify or augment the management permissions bestowed by 149 the NAS-Prompt Service-Type, and thus applies to CLI management 150 interfaces. 152 5. Provisions for Secure Management Access 154 To provide for the authorization and provisioning of secure 155 management methods, via a secure transport protocols, one new 156 attribute is introduced in this document, Management-Transport- 157 Protocol. The value of this attribute is an enumeration of secure 158 transport protocols that may be required for the provisioning of NAS- 159 Prompt, Administrative or Framed-Management service. 161 6. New Values for Existing RADIUS Attributes 163 6.1. Service-Type 165 This document defines one new value for an existing RADIUS attribute. 166 The Service-Type attribute is defined in Section 5.6 of RFC 2865 167 [RFC2865], as follows: 169 This Attribute indicates the type of service the user has requested, 170 or the type of service to be provided. It MAY be used in both 171 Access-Request and Access-Accept packets. 173 A NAS is not required to implement all of these service types, and 174 MUST treat unknown or unsupported Service-Types as though an Access- 175 Reject had been received instead. 177 A summary of the Service-Type Attribute format is shown below. 179 The fields are transmitted from left to right. 181 0 1 2 3 182 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Type | Length | Value 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Value (cont) | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Type 191 6 for Service-Type. 193 Length 195 6 Value 197 The Value field is four octets. 199 This document defines one new value for the Service-Type 200 attribute. 202 (TBA) Framed-Management 204 The semantics of the Framed-Management service are as follows: 206 Framed-Management A framed management protocol session should 207 be started on the NAS. 209 7. New RADIUS Attributes 211 This document defines four new RADIUS attributes related to remote 212 management authorization. 214 7.1. Framed-Management-Protocol 216 The Framed-Management-Protocol attribute indicates the application- 217 layer protocol to be used for framed management access. It MAY be 218 used in both Access-Request and Access-Accept packets. This 219 attribute is used in conjunction with a Service-Type of Framed- 220 Management. 222 A summary of the Framed-Management-Protocol attribute format is shown 223 below. The fields are transmitted from left to right. 225 0 1 2 3 226 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type | Length | Value 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Value (cont) | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Type 235 (TBA) for Framed-Management-Protocol. 237 Length 239 6 241 Value 243 The Value field is four octets. 245 1 SNMP 246 2 Web-based 247 3 NETCONF 248 4 FTP 249 5 TFTP 250 6 CP 252 The acronyms used in the above table expand as follows: 254 o SNMP: Simple Network Management Protocol. 256 o Web-based: Use of an embedded web server in the NAS for management 257 via a generic web browser client. The interface presented to the 258 administrator may be graphical, tabular or textual. The protocol 259 is HTML over HTTP. 261 o NETCONF: Management via the NETCONF protocol using XML over 262 supported transports (e.g. HTTP, BEEP, SOAP). 264 o FTP: File Transfer Protocol, used to transfer configuration files 265 to and from the NAS. 267 o TFTP: Trivial File Transfer Protocol, used to transfer 268 configuration files to and from the NAS. 270 o CP: CP (file copy) protocol, used to transfer configuration files 271 to and from the NAS. 273 7.2. Management-Transport-Protocol 275 The Management-Transport-Protocol attribute indicates the mandated 276 transport protocol, usually a secure transport, for use with framed 277 or non-framed management access sessions. It MAY be used in both 278 Access-Request and Access-Accept packets. This attribute MAY be used 279 in conjunction with other management access provisioning attributes. 281 When a secure form of non-framed management access is specified, for 282 example the remote terminal service of Secure Shell (SSH), for access 283 to the interactive CLI prompt of the NAS, it means that the terminal 284 emulation session is encapsulated in some form of protected 285 transport, or tunnel. It may also mean that an explicit secure mode 286 of operation is required, when the terminal emulation access protocol 287 contains an intrinsic secure mode of operation. 289 When a secure form of framed management access is specified, for 290 example SNMP over the Transport Security Model, using SSH, it means 291 that the application-layer management protocol is encapsulated in 292 some form of protected transport, or tunnel. It may also mean that 293 an explicit secure mode of operation is required, when the framed 294 management protocol contains an intrinsic secure mode of operation. 296 A value of "Default (1)" indicates that no specific transport 297 protocol is being provisioned, and that the NAS should expect the 298 default transport associated with application layer protocol to be 299 used, or more generally, should accept any supported transport 300 protocol. The same default semantics are conveyed by omitting this 301 attribute from an Access-Accept packet. 303 A summary of the Management-Transport-Protocol Attribute format is 304 shown below. The fields are transmitted from left to right. 306 0 1 2 3 307 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type | Length | Value 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Value (cont) | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Type 316 (TBA) for Management-Transport-Protocol. 318 Length 320 6 322 Value 324 The Value field is four octets. 326 1 Default 327 2 SSH 328 3 TLS 329 4 DTLS 330 5 BEEP 331 6 SOAP 333 The acronyms used in the above table expand as follows: 335 o Default: No specific transport is required. Accept any supported 336 transport. 338 o SSH: The Secure Shell protocol. This refers to the general secure 339 transport service of SSH, rather than to the secure remote 340 terminal service of SSH. 342 o TLS: Transport Layer Security. 344 o DTLS: Datagram Transport Layer Security. 346 o BEEP: Blocks Extensible Exchange Protocol. 348 o SOAP: Simple Object Access Protocol. 350 7.3. Management-Policy-Id 352 The Management-Policy-Id attribute indicates the name of the 353 management access policy for this user. Zero or more Management- 354 Policy-Id attributes MAY be sent in an Access-Accept packet. 355 Identifying a policy by name allows the policy to be used on 356 different NASes without regard to implementation details. 358 Multiple forms of management access rules may be expressed by the 359 underlying named policy, the definition of which is beyond the scope 360 of this document. The management access policy MAY be applied 361 contextually, based on the nature of the management access method. 362 For example, some named policies may only be valid for application to 363 NAS-Prompt services and some other policies may only be valid for 364 application to SMNPv3 services. 366 The management access policy named in this attribute, received in an 367 Access-Accept packet, MUST be applied to the session authorized by 368 the Access-Accept. If the NAS supports this attribute, but the 369 policy name is unknown, or the policy rules are incorrectly 370 formatted, the NAS MUST treat the packet as if it had been an Access- 371 Reject. 373 No precedence relationship is defined for multiple occurrences of the 374 Management-Policy-Id attribute. NAS behavior in such cases is not 375 predictable. Therefore, two or more occurrences of this attribute 376 SHOULD NOT be included in a single service provisioning message, such 377 as Access-Accept or CoA. 379 The content of the Management-Policy-Id attribute is expected to be 380 the name of a management access policy of local significance to the 381 NAS, within a flat namespace of significance to the NAS. Overloading 382 or subdividing this flat name with multi-part specifiers (e.g. 383 Access=remote, Level=7) is likely to lead to poor multi-vendor 384 interoperability and SHOULD NOT be utilized. If a simple flat policy 385 name is not sufficient to the anticipated use case, it is RECOMMEDNED 386 that a Vendor Specific Attribute be used instead, rather than 387 overloading the semantics of Management-Policy-Id. 389 A summary of the Management-Policy-Id Attribute format is shown 390 below. The fields are transmitted from left to right. 392 0 1 2 393 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 395 | Type | Length | Text ... 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 398 Type 400 (TBA) for Management-Policy-Id. 402 Length 404 >= 3 406 Text 408 The Text field is one or more octets, and its contents are 409 implementation dependent. It is intended to be human readable and 410 MUST NOT affect operation of the protocol. It is recommended that 411 the message contain UTF-8 encoded 10646 [RFC3629] characters. 413 7.4. Management-Privilege-Level 415 The Management-Privilege-Level attribute indicates the integer 416 Privilege level to be assigned for management access for the 417 authenticated user. Many NASes provide the notion of differentiated 418 management privilege levels denoted by an integer value. The 419 specific access rights conferred by each value are implementation 420 dependent. It MAY be used in both Access-Request and Access-Accept 421 packets. 423 The management access level indicated in this attribute, received in 424 an Access-Accept packet, MUST be applied to the session authorized by 425 the Access-Accept. If the NAS supports this attribute, but the 426 privilege level is unknown, the NAS MUST treat the packet as if it 427 had been an Access-Reject. 429 A summary of the Management-Privilege-Level attribute format is show 430 below. The fields are transmitted from left to right. 432 0 1 2 3 433 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Type | Length | Value 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 Value (cont) | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 Type 442 (TBA) for Management-Privilege-Level. 444 Length 446 6 448 Value 450 The Value field is an Integer, denoting a management 451 privilege level. 453 It is RECOMMENDED to limit this new attribute's use to sessions where 454 Service-Type is NAS-Prompt (not Administrative). Typically, NASes 455 treat NAS-Prompt as the minimal privilege CLI service and 456 Administrative as full privilege. Using the Management-Privilege- 457 Level attribute with a Service-Type attribute with a value of NAS- 458 Prompt will have the effect of increasing the minimum privilege 459 level. Conversely, it is NOT RECOMMENDED to use this attribute with 460 a Service-Type of Administrative, which may require decreasing the 461 maximum privilege level. 463 8. Examples of attribute groupings 465 1. CLI access, via local console or telnet, to the "super-user" 466 access level: 468 * Service-Type (6) = Administrative (6) 469 * Management-Transport-Protocol (xx) = Default (1) 471 2. CLI access, via the secure remote terminal service of SSH, to the 472 non-privileged user access level: 474 * Service-Type (6) = NAS-Prompt (7) 475 * Management-Transport-Protocol (xx) = SSH (2) 477 3. CLI access, via the secure remote terminal service of SSH, to a 478 custom management access level, defined by a policy: 480 * Service-Type (6) = NAS-Prompt (7) 481 * Transport-Protocol (xx) = SSH (2) 482 * Management-Policy-Id (xx) = "Network Administrator" 484 4. CLI access, via the secure remote terminal service of SSH, with a 485 management privilege level of 15: 487 * Service-Type (6) = NAS-Prompt (7) 488 * Management-Transport-Protocol (xx) = SSH (2) 489 * Management-Privilege-Level (xx) = 15 491 5. SNMPv3 access, using an Access Control Model specifier, such as a 492 custom VACM View, defined by a policy: 494 * Service-Type (6) = Framed-Management (xx) 495 * Framed-Management-Protocol (xx) = SNMP (1) 496 * Management-Policy-Id (xx) = "SNMP Network Administrator View" 498 Note that there is currently no standardized way of implementing 499 this management policy mapping within SNMPv3. Such mechanisms 500 are implementation specific. 502 6. SNMP secure Transport Model access, using the Secure Shell 503 Transport Model: 505 * Service-Type (6) = Framed-Management (xx) 506 * Framed-Management-Protocol (xx) = SNMP (1) 507 * Transport-Protocol (xx) = SSH (2) 509 7. Web (HTTP) access: 511 * Service-Type (6) = Framed-Management (xx) 512 * Framed-Management-Protocol (xx) = Web-based (2) 514 8. Secure web access, using a custom management access level, 515 defined by a policy: 517 * Service-Type (6) = Framed-Management (xx) 518 * Framed-Management-Protocol (xx) = Web-based (2) 519 * Management-Transport-Protocol (xx) = TLS (3) 520 * Management-Policy-Id (xx) = "Read-only web access" 522 9. Diameter Translation Considerations 524 When used in Diameter, the attributes defined in this specification 525 can be used as Diameter AVPs from the Code space 1-255 (RADIUS 526 attribute compatibility space). No additional Diameter Code values 527 are therefore allocated. The data types and flag rules for the 528 attributes are as follows: 530 +---------------------+ 531 | AVP Flag rules | 532 |----+-----+----+-----|----+ 533 | | |SHLD| MUST| | 534 Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| 535 ---------------------------------|----+-----+----+-----|----| 536 Service-Type (new value) | | | | | | 537 Enumerated | M | P | | V | Y | 538 Framed-Management-Protocol | | | | | | 539 Enumerated | M | P | | V | Y | 540 Management-Transport-Protocol | | | | | | 541 Enumerated | M | P | | V | Y | 542 Management-Policy-Id | | | | | | 543 UTF8String | M | P | | V | Y | 544 Management-Privilege-Level | | | | | | 545 Integer | M | P | | V | Y | 546 ---------------------------------|----+-----+----+-----|----| 548 The attributes in this specification have no special translation 549 requirements for Diameter to RADIUS or RADIUS to Diameter gateways; 550 they are copied as is, except for changes relating to headers, 551 alignment, and padding. See also [RFC3588] Section 4.1 and [RFC4005] 552 Section 9. 554 What this specification says about the applicability of the 555 attributes for RADIUS Access-Request packets applies in Diameter to 556 AA-Request [RFC4005]. 558 What is said about Access-Accept applies in Diameter to AA-Answer 559 messages that indicate success. 561 10. RADIUS Proxy Operation Considerations 563 The device management access authorization attributes presented in 564 this document present certain considerations when used in RADIUS 565 proxy environments. These considerations are not different from 566 those that exist in RFC 2865 [RFC2865] with respect to the Service- 567 Type attribute values of Administrative and NAS-Prompt. 569 Most RADIUS proxy environments are also multi-party environments. In 570 multi-party proxy environments it is important to distinguish which 571 entities have the authority to provision management access to the 572 edge devices, i.e. NASes, and which entities only have authority to 573 provision network access services of various sorts. 575 It may be important that operators of the NAS are able to ensure that 576 access to the CLI, or other management interfaces, of the NAS are 577 only provisioned to their own employees or contractors. One way for 578 the NAS to enforce this requirement is to use only local, non-proxy 579 RADIUS servers for management access requests. Proxy RADIUS servers 580 could be used for non-management access requests, based on local 581 policy. This "bifurcation" of RADIUS authentication and 582 authorization is a simple case of separate administrative realms. 583 The NAS may be designed so as to maintain separate lists of RADIUS 584 servers for management AAA use and for non-management AAA use. 586 An alternate method of enforcing this requirement would be for the 587 first-hop RADIUS proxy server, operated by the owner of the NAS, to 588 filter out any RADIUS attributes that provision management access 589 rights that originate from "up-stream" proxy servers not operated by 590 the NAS owner. Access-Accept messages that provision such locally 591 un-authorized management access MAY be treated as if they were an 592 Access-Reject by the first-hop proxy server. 594 These issues are not of concern when all the RADIUS servers, local 595 and proxy, used by the NAS are under the sole administrative control 596 of the NAS owner. 598 11. Table of Attributes 600 The following table provides a guide to which attributes may be found 601 in which kinds of packets, and in what quantity. 603 Access- 604 Request Accept Reject Challenge # Attribute 605 --------------------------------------------------------------------- 606 0-1 0-1 0 0 TBA Framed-Management-Protocol 607 0-1 0-1 0 0 TBA Management-Transport-Protocol 608 0 0-1 0 0 TBA Management-Policy-Id 609 0 0-1 0 0 TBA Management-Privilege-Level 611 Accounting- 612 Request Response # Attribute 613 --------------------------------------------------------------------- 614 0-1 0 TBA Framed-Management-Protocol 615 0-1 0 TBA Management-Transport-Protocol 616 0-1 0 TBA Management-Policy-Id 617 0-1 0 TBA Management-Privilege-Level 619 The following table defines the meaning of the above table entries. 621 0 This attribute MUST NOT be present in a packet. 622 0+ Zero or more instances of this attribute MAY be present in 623 a packet. 624 0-1 Zero or one instance of this attribute MAY be present in 625 a packet. 626 1 Exactly one instance of this attribute MUST be present in 627 a packet. 629 12. IANA Considerations 631 This document contains placeholders ("TBA") for assigned numbers 632 within the RADIUS Attributes registry, to be assigned by IANA at the 633 time this document should be published as an RFC. Assignment of 634 additional values for attributes defined in this document are to be 635 processed as described in [RFC3575], subject to the additional 636 requirement that a published specification is required. 638 13. Security Considerations 640 This specification describes the use of RADIUS and Diameter for 641 purposes of authentication, authorization and accounting for 642 management access to devices within networks. RADIUS threats and 643 security issues for this application are described in [RFC3579] and 644 [RFC3580]; security issues encountered in roaming are described in 645 [RFC2607]. For Diameter, the security issues relating to this 646 application are described in [RFC4005] and [RFC4072]. 648 This document specifies new attributes that can be included in 649 existing RADIUS packets, which may be protected as described in 650 [RFC3579] and [RFC3576]. In Diameter, the attributes are protected 651 as specified in [RFC3588]. See those documents for a more detailed 652 description. 654 The security mechanisms supported in RADIUS and Diameter are focused 655 on preventing an attacker from spoofing packets or modifying packets 656 in transit. They do not prevent an authorized RADIUS/Diameter server 657 or proxy from inserting attributes with malicious intent. 659 Any of the attributes described in this memo, with the exception of 660 Service-Type, may not be understood by the NAS which receives it. A 661 legacy NAS not compliant with this specification may silently discard 662 these attributes while permitting the user to access the management 663 interface(s) of the NAS. This can lead to users improperly receiving 664 unauthorized management access to the NAS, or access with greater 665 levels of access rights than were intended. RADIUS servers SHOULD 666 attempt to ascertain whether or not the NAS supports these attributes 667 before sending them in an Access-Accept. 669 14. Acknowledgments 671 Many thanks to all reviewers, including Barney Wolff, Mauricio 672 Sanchez, David Harrington, Juergen Schoenwaelder, Bernard Aboba. 674 15. References 676 15.1. Normative References 678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", BCP 14, RFC 2119, March 1997. 681 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 682 "Remote Authentication Dial In User Service (RADIUS)", 683 RFC 2865, June 2000. 685 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 686 10646", STD 63, RFC 3629, November 2003. 688 15.2. Informative References 690 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 691 Implementation in Roaming", RFC 2607, June 1999. 693 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 695 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 696 Access Control Model (VACM) for the Simple Network 697 Management Protocol (SNMP)", STD 62, RFC 3415, 698 December 2002. 700 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 701 Authentication Dial In User Service)", RFC 3575, 702 July 2003. 704 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 705 Aboba, "Dynamic Authorization Extensions to Remote 706 Authentication Dial In User Service (RADIUS)", RFC 3576, 707 July 2003. 709 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 710 Dial In User Service) Support For Extensible 711 Authentication Protocol (EAP)", RFC 3579, September 2003. 713 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 714 "IEEE 802.1X Remote Authentication Dial In User Service 715 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 717 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 718 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 720 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 721 "Diameter Network Access Server Application", RFC 4005, 722 August 2005. 724 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 725 Authentication Protocol (EAP) Application", RFC 4072, 726 August 2005. 728 Authors' Addresses 730 David B. Nelson 731 Elbrys Networks, Inc. 732 75 Rochester Avenue, Unit 3 733 Portsmouth, NH 03801 734 USA 736 Email: d.b.nelson@comcast.net 737 Greg Weber 739 Email: gdweber@gmail.com 741 Full Copyright Statement 743 Copyright (C) The IETF Trust (2007). 745 This document is subject to the rights, licenses and restrictions 746 contained in BCP 78, and except as set forth therein, the authors 747 retain all their rights. 749 This document and the information contained herein are provided on an 750 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 751 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 752 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 753 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 754 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 755 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 757 Intellectual Property 759 The IETF takes no position regarding the validity or scope of any 760 Intellectual Property Rights or other rights that might be claimed to 761 pertain to the implementation or use of the technology described in 762 this document or the extent to which any license under such rights 763 might or might not be available; nor does it represent that it has 764 made any independent effort to identify any such rights. Information 765 on the procedures with respect to rights in RFC documents can be 766 found in BCP 78 and BCP 79. 768 Copies of IPR disclosures made to the IETF Secretariat and any 769 assurances of licenses to be made available, or the result of an 770 attempt made to obtain a general license or permission for the use of 771 such proprietary rights by implementers or users of this 772 specification can be obtained from the IETF on-line IPR repository at 773 http://www.ietf.org/ipr. 775 The IETF invites any interested party to bring to its attention any 776 copyrights, patents or patent applications, or other proprietary 777 rights that may cover technology that may be required to implement 778 this standard. Please address the information to the IETF at 779 ietf-ipr@ietf.org. 781 Acknowledgment 783 Funding for the RFC Editor function is provided by the IETF 784 Administrative Support Activity (IASA).