idnits 2.17.1 draft-ietf-radext-management-authorization-02.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 836. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 847. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 854. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 860. 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 (February 24, 2008) is 5899 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: August 27, 2008 February 24, 2008 7 Remote Authentication Dial-In User Service (RADIUS) Authorization for 8 Network Access Server (NAS) Management 9 draft-ietf-radext-management-authorization-02.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 August 27, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 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, for granular levels of access rights and 48 management privileges, and for specification of a protected transport 49 protocol. 51 Table of Contents 53 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction and Rationale . . . . . . . . . . . . . . . . . . 3 55 3. Provisions for Framed Management . . . . . . . . . . . . . . . 3 56 4. Provisions for Granular Management Access Rights . . . . . . . 4 57 5. Provisions for Secure Management Access . . . . . . . . . . . 4 58 6. Current Practice for CLI Management Access . . . . . . . . . . 4 59 7. New Values for Existing RADIUS Attributes . . . . . . . . . . 5 60 7.1. Service-Type . . . . . . . . . . . . . . . . . . . . . . . 5 61 8. New RADIUS Attributes . . . . . . . . . . . . . . . . . . . . 6 62 8.1. Framed-Management-Protocol . . . . . . . . . . . . . . . . 6 63 8.2. Management-Transport-Protection . . . . . . . . . . . . . 8 64 8.3. Management-Policy-Id . . . . . . . . . . . . . . . . . . . 10 65 8.4. Management-Privilege-Level . . . . . . . . . . . . . . . . 11 66 9. Examples of attribute groupings . . . . . . . . . . . . . . . 12 67 10. Diameter Translation Considerations . . . . . . . . . . . . . 14 68 11. RADIUS Proxy Operation Considerations . . . . . . . . . . . . 15 69 12. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 16 70 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 71 14. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 73 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 16.1. Normative References . . . . . . . . . . . . . . . . . . . 18 75 16.2. Informative References . . . . . . . . . . . . . . . . . . 18 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 77 Intellectual Property and Copyright Statements . . . . . . . . . . 20 79 1. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC2119]. 85 This document uses terminology from RFC 2865 [RFC2865] and RFC 2866 86 [RFC2866]. 88 2. Introduction and Rationale 90 The remote management Service-Types defined in RFC 2865 [RFC2865] 91 include NAS-Prompt and Administrative. Both of these services 92 provide access to the interactive, text-based, Command Line Interface 93 (CLI) of the managed entity. Current deployments of network 94 equipment include in the managed entity non-CLI, framed-protocol 95 forms of management, such as web browser based management, SNMP, and 96 NETCONF. In addition, network devices often support more privilege 97 levels for management access than the two levels supported by NAS- 98 Prompt (non-privileged) and Administrative (privileged). To address 99 these issues, attributes for framed management protocols, management 100 protocol security levels, and management access privilege levels are 101 described. 103 3. Provisions for Framed Management 105 Framed Management means management of an entity by means of a non- 106 interactive, non-CLI-style method. The management information is 107 typically formatted in a binary or textual encoding, such as HTML, 108 XML or ASN.1/BER. While remote management by interactive CLI 109 sessions is carried over protocols, such as Telnet, Rlogin, and SSH, 110 these protocols are primarily for the delivery of terminal, or 111 pseudo-TTY services. Note that, in this context, "SSH" means the 112 remote terminal service of SSH, not the more general protected 113 transport service of SSH. Command Line Interface, Menu Interface, or 114 other text-based (e.g. ASCII or UTF-8) terminal emulation interfaces 115 are not considered to be Framed Management protocols, as used in this 116 document. Examples of Framed Management protocols include web-based 117 management (HTML over HTTP or HTTPS), NETCONF (XML over HTTP/BEEP/ 118 SOAP) and SNMP (SMI over ASN.1/BER). 120 To support the authorization and provisioning of Framed Management 121 access to managed entities, this document introduces a new value for 122 the Service-Type attribute [RFC2865], and one new attribute. The new 123 value for the Service-Type attribute is Framed-Management. The 124 definition of this service is the provisioning of remote device 125 management via a Framed Management protocol, as described in this 126 section. The new attribute is Framed-Management-Protocol, the value 127 of which specifies a particular protocol for use in the remote 128 management session. 130 4. Provisions for Granular Management Access Rights 132 Two new attributes are introduced in this document in support of 133 granular management access rights or command privilege levels. 135 The Management-Policy-Id attribute is used to contain the name of a 136 management access rights policy of local scope. This attribute 137 functions similarly to Filter-ID. It is a string variable containing 138 a policy name of local scope. The provisioning of the rules invoked 139 by application of this management policy is by means outside the 140 scope of this document, such as by MIB objects. 142 The local application of the Management-Policy-Id within the managed 143 entity may take the form of (a) one of an enumeration of command 144 privilege levels, (b) a mapping into an SNMP Access Control Model, 145 such as the View Based Access Control Model (VACM) table [RFC3415], 146 or (c) some other set of management access policy rules that is 147 mutually understood by the managed entity and the remote management 148 application. Examples are given in Section 9. 150 The Management-Privilege-Level attribute is used to contain an 151 Integer-valued management privilege level indication. This attribute 152 serves to modify or augment the management permissions bestowed by 153 the NAS-Prompt Service-Type, and thus applies to CLI management 154 interfaces. 156 5. Provisions for Secure Management Access 158 To provide for the provisioning of secure management methods, via 159 various secure transport protocols, one new attribute is introduced 160 in this document, Management-Transport-Protection. The value of this 161 attribute indicates the level of secure transport protocol protection 162 that is required for the provisioning of NAS-Prompt, Administrative 163 or Framed-Management service. 165 6. Current Practice for CLI Management Access 167 To aid in understanding of this document, it is helpful to review 168 current RADIUS implementation practice with regard to the 169 provisioning of management access to the Command Line Interface (CLI) 170 of the NAS. The RADIUS Service-Type values of NAS-Prompt and 171 Administrative originally applied to access via a physical console 172 port of the NAS, most often a serial port. Remote access to the CLI 173 of the NAS over remote terminal protocols such as Telnet, Rlogin and 174 SSH, has been available in many NAS implementations for many years. 175 In order to distinguish local, physical console, access from remote 176 access, the NAS-Port-Type attribute is generally included in Access- 177 Request and Access-Accept messages, along with the Service-Type, to 178 indicate the form of access. A NAS-Port-Type of Async (0) is used to 179 signify a local serial port connection, while a value of Virtual (5) 180 is used to signify a remote connection, via a remote terminal 181 protocol. This usage provides no selectivity among the various 182 available remote terminal protocols (e.g. Telnet, Rlogin, SSH, 183 etc.). 185 It is expected that the additional features of this document with 186 respect to remote access to the CLI of a NAS will be used in 187 conjunction with the existing practice regarding the NAS-Port-Type 188 attribute described in this section. 190 7. New Values for Existing RADIUS Attributes 192 7.1. Service-Type 194 This document defines one new value for an existing RADIUS attribute. 195 The Service-Type attribute is defined in Section 5.6 of RFC 2865 196 [RFC2865], as follows: 198 This Attribute indicates the type of service the user has requested, 199 or the type of service to be provided. It MAY be used in both 200 Access-Request and Access-Accept packets. 202 A NAS is not required to implement all of these service types, and 203 MUST treat unknown or unsupported Service-Types as though an Access- 204 Reject had been received instead. 206 A summary of the Service-Type Attribute format is shown below. 208 The fields are transmitted from left to right. 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Type | Length | Value 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Value (cont) | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Type 220 6 for Service-Type. 222 Length 224 6 Value 226 The Value field is four octets. 228 This document defines one new value for the Service-Type 229 attribute. 231 (TBA) Framed-Management 233 The semantics of the Framed-Management service are as follows: 235 Framed-Management A framed management protocol session should 236 be started on the NAS. 238 8. New RADIUS Attributes 240 This document defines four new RADIUS attributes related to remote 241 management authorization. 243 8.1. Framed-Management-Protocol 245 The Framed-Management-Protocol attribute indicates the application- 246 layer management protocol to be used for framed management access. 247 It MAY be used in both Access-Request and Access-Accept packets. 248 This attribute is used in conjunction with a Service-Type of Framed- 249 Management. 251 A summary of the Framed-Management-Protocol attribute format is shown 252 below. The fields are transmitted from left to right. 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Type | Length | Value 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Value (cont) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Type 264 (TBA) for Framed-Management-Protocol. 266 Length 268 6 270 Value 272 The Value field is four octets. 274 1 SNMP 275 2 Web-based 276 3 NETCONF 277 4 FTP 278 5 TFTP 279 6 CP 281 The acronyms used in the above table expand as follows: 283 o SNMP: Simple Network Management Protocol. 285 o Web-based: Use of an embedded web server in the NAS for management 286 via a generic web browser client. The interface presented to the 287 administrator may be graphical, tabular or textual. The protocol 288 is HTML over HTTP. The protocol may optionally be HTML over 289 HTTPS, i.e. using HTTP over TLS. 291 o NETCONF: Management via the NETCONF protocol using XML over 292 supported transports (e.g. HTTP, BEEP, SOAP). As secure 293 transport profiles are defined for NETCONF, the list of transport 294 options may expand. 296 o FTP: File Transfer Protocol, used to transfer configuration files 297 to and from the NAS. 299 o TFTP: Trivial File Transfer Protocol, used to transfer 300 configuration files to and from the NAS. 302 o CP: CP (file copy) protocol, used to transfer configuration files 303 to and from the NAS. 305 8.2. Management-Transport-Protection 307 The Management-Transport-Protection attribute specifies whether a 308 secure transport protocol (e.g. SSH, TLS, DTLS, etc.) is required 309 for use with the associated framed or non-framed management access 310 session. The value of this attribute specifies the minimum level of 311 protection that is required from the protected transport. The 312 protected transport MAY provide a greater level of protection than is 313 called for by the value of Management-Transport-Protection. 315 When a secure form of non-framed management access is specified, it 316 means that the remote terminal session is encapsulated in some form 317 of protected transport, or tunnel. It may also mean that an explicit 318 secure mode of operation is required, when the framed management 319 protocol contains an intrinsic secure mode of operation. The 320 Management-Transport-Protocol attribute does not apply to CLI access 321 via a local serial port, or other non-remote connection. 323 When a secure form of framed management access is specified, it means 324 that the application-layer management protocol is encapsulated in 325 some form of protected transport, or tunnel. It may also mean that 326 an explicit secure mode of operation is required, when the framed 327 management protocol contains an intrinsic secure mode of operation. 329 A value of "No Protection (1)" indicates that a secure transport 330 protocol is not required, and that the NAS SHOULD accept a connection 331 over any transport associated with the application layer management 332 protocol. Note that the definitions of management application to 333 transport bindings are defined in the relevant documents that specify 334 those management application protocols. The same "No Protection" 335 semantics are conveyed by omitting this attribute from an Access- 336 Accept packet. 338 Note that specific protected transport protocols, cipher suites, key 339 agreement methods, or authentication methods are not specified by 340 this attribute. Such provisioning is beyond the scope of this 341 document. 343 A summary of the Management-Transport-Protection Attribute format is 344 shown below. The fields are transmitted from left to right. 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type | Length | Value 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Value (cont) | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Type 356 (TBA) for Management-Transport-Protection. 358 Length 360 6 362 Value 364 The Value field is four octets. 366 1 No-Protection 367 2 Integrity-Protection 368 3 Confidentiality-Protection 369 4 Integrity-Confidentiality-Protection 371 The acronyms used in the above table expand as follows: 373 o No-Protection: No transport protection is required. Accept 374 connections via any supported transport. 376 o Integrity-Protection: The management session requires protection 377 in a secure or protected transport, that is supported by the 378 management access protocol and implementation. The secure 379 transport MUST provide Integrity Protection. 381 o Confidentiality-Protection: The management session requires 382 protection in a secure or protected transport, that is supported 383 by the management access protocol and implementation. The secure 384 transport MUST provide Confidentiality Protection. 386 o Integrity-Confidentiality-Protection: The management session 387 requires protection in a secure or protected transport, that is 388 supported by the management access protocol and implementation. 389 The secure transport MUST provide both Integrity Protection and 390 Confidentiality Protection. 392 8.3. Management-Policy-Id 394 The Management-Policy-Id attribute indicates the name of the 395 management access policy for this user. Zero or more Management- 396 Policy-Id attributes MAY be sent in an Access-Accept packet. 397 Identifying a policy by name allows the policy to be used on 398 different NASes without regard to implementation details. 400 Multiple forms of management access rules may be expressed by the 401 underlying named policy, the definition of which is beyond the scope 402 of this document. The management access policy MAY be applied 403 contextually, based on the nature of the management access method. 404 For example, some named policies may only be valid for application to 405 NAS-Prompt services and some other policies may only be valid for 406 application to SMNPv3 services. 408 The management access policy named in this attribute, received in an 409 Access-Accept packet, MUST be applied to the session authorized by 410 the Access-Accept. If the NAS supports this attribute, but the 411 policy name is unknown, or the policy rules are incorrectly 412 formatted, the NAS MUST treat the packet as if it had been an Access- 413 Reject. 415 No precedence relationship is defined for multiple occurrences of the 416 Management-Policy-Id attribute. NAS behavior in such cases is not 417 predictable. Therefore, two or more occurrences of this attribute 418 SHOULD NOT be included in a single service provisioning message, such 419 as Access-Accept or CoA. 421 The content of the Management-Policy-Id attribute is expected to be 422 the name of a management access policy of local significance to the 423 NAS, within a flat namespace of significance to the NAS. In this 424 regard, the behavior is similar to that for the Filter-Id attribute. 425 The policy names and rules are committed to the local configuration 426 store of the NAS, and are provisioned by means beyond the scope of 427 this document, such as via SNMP, NETCONF or CLI. 429 Overloading or subdividing this flat name with multi-part specifiers 430 (e.g. Access=remote, Level=7) is likely to lead to poor multi-vendor 431 interoperability and SHOULD NOT be utilized. If a simple flat policy 432 name is not sufficient to the anticipated use case, it is RECOMMEDNED 433 that a Vendor Specific Attribute be used instead, rather than 434 overloading the semantics of Management-Policy-Id. 436 A summary of the Management-Policy-Id Attribute format is shown 437 below. The fields are transmitted from left to right. 439 0 1 2 440 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 442 | Type | Length | Text ... 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 445 Type 447 (TBA) for Management-Policy-Id. 449 Length 451 >= 3 453 Text 455 The Text field is one or more octets, and its contents are 456 implementation dependent. It is intended to be human readable and 457 MUST NOT affect operation of the protocol. It is recommended that 458 the message contain UTF-8 encoded 10646 [RFC3629] characters. 460 8.4. Management-Privilege-Level 462 The Management-Privilege-Level attribute indicates the integer 463 Privilege level to be assigned for management access for the 464 authenticated user. Many NASes provide the notion of differentiated 465 management privilege levels denoted by an integer value. The 466 specific access rights conferred by each value are implementation 467 dependent. It MAY be used in both Access-Request and Access-Accept 468 packets. 470 The management access level indicated in this attribute, received in 471 an Access-Accept packet, MUST be applied to the session authorized by 472 the Access-Accept. If the NAS supports this attribute, but the 473 privilege level is unknown, the NAS MUST treat the packet as if it 474 had been an Access-Reject. 476 A summary of the Management-Privilege-Level attribute format is show 477 below. The fields are transmitted from left to right. 479 0 1 2 3 480 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Type | Length | Value 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 Value (cont) | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Type 489 (TBA) for Management-Privilege-Level. 491 Length 493 6 495 Value 497 The Value field is an Integer, denoting a management 498 privilege level. 500 It is RECOMMENDED to limit use of Management-Privilege-Level to 501 sessions where Service-Type is NAS-Prompt (not Administrative). 502 Typically, NASes treat NAS-Prompt as the minimal privilege CLI 503 service and Administrative as full privilege. Using the Management- 504 Privilege-Level attribute with a Service-Type attribute with a value 505 of NAS-Prompt will have the effect of increasing the minimum 506 privilege level. Conversely, it is NOT RECOMMENDED to use this 507 attribute with a Service-Type of Administrative, which may require 508 decreasing the maximum privilege level. 510 It is NOT RECOMMENDED to use Management-Privilege-Level in 511 combination with Management-Policy-Id or for management access 512 methods other than interactive CLI. The behavior resulting from such 513 an overlay of management access control provisioning is not defined 514 by this document, and in the absence of further specification is 515 likely to lead to unexpected behaviors, especially in multi-vendor 516 environments. 518 9. Examples of attribute groupings 520 1. Unprotected CLI access, via local console or remote terminal 521 access, to the "super-user" access level: 523 * Service-Type (6) = Administrative (6) 524 * Management-Transport-Protection (xx) = No-Protection (1) 526 2. CLI access, via a fully-protected secure remote terminal service 527 to the non-privileged user access level: 529 * Service-Type (6) = NAS-Prompt (7) 530 * Management-Transport-Protection (xx) = Integrity- 531 Confidentiality-Protection (4) 533 3. CLI access, via a confidentiality protected secure remote 534 terminal service of SSH, to a custom management access level, 535 defined by a policy: 537 * Service-Type (6) = NAS-Prompt (7) 538 * Transport-Protocol (xx) = SSH (2) 539 * Management-Transport-Protection (xx) = Confidentiality- 540 Protection (3) 541 * Management-Policy-Id (xx) = "Network Administrator" 543 4. CLI access, via a fully-protected secure remote terminal service 544 of SSH, with a management privilege level of 15: 546 * Service-Type (6) = NAS-Prompt (7) 547 * Management-Transport-Protection (xx) = SSH (2) 548 * Management-Transport-Protection (xx) = Integrity- 549 Confidentiality-Protection (4) 550 * Management-Privilege-Level (xx) = 15 552 5. SNMPv3 access, using an Access Control Model specifier, such as a 553 custom VACM View, defined by a policy: 555 * Service-Type (6) = Framed-Management (xx) 556 * Framed-Management-Protocol (xx) = SNMP (1) 557 * Management-Policy-Id (xx) = "SNMP Network Administrator View" 559 Note that there is currently no standardized way of implementing 560 this management policy mapping within SNMPv3. Such mechanisms 561 are implementation specific. 563 6. SNMP secure Transport Model access, using the Secure Shell 564 Transport Model: 566 * Service-Type (6) = Framed-Management (xx) 567 * Framed-Management-Protocol (xx) = SNMP (1) 568 * Transport-Protocol (xx) = SSH (2) 569 * Management-Transport-Protection (xx) = Integrity- 570 Confidentiality-Protection (4) 572 7. Web (HTTP) access: 574 * Service-Type (6) = Framed-Management (xx) 575 * Framed-Management-Protocol (xx) = Web-based (2) 577 8. Secure web access, using a custom management access level, 578 defined by a policy: 580 * Service-Type (6) = Framed-Management (xx) 581 * Framed-Management-Protocol (xx) = Web-based (2) 582 * Management-Transport-Protection (xx) = Confidentiality- 583 Protection (3) 584 * Management-Policy-Id (xx) = "Read-only web access" 586 10. Diameter Translation Considerations 588 When used in Diameter, the attributes defined in this specification 589 can be used as Diameter AVPs from the Code space 1-255 (RADIUS 590 attribute compatibility space). No additional Diameter Code values 591 are therefore allocated. The data types and flag rules for the 592 attributes are as follows: 594 +---------------------+ 595 | AVP Flag rules | 596 |----+-----+----+-----|----+ 597 | | |SHLD| MUST| | 598 Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| 599 ---------------------------------|----+-----+----+-----|----| 600 Service-Type (new value) | | | | | | 601 Enumerated | M | P | | V | Y | 602 Framed-Management-Protocol | | | | | | 603 Enumerated | M | P | | V | Y | 604 Management-Transport-Protection | | | | | | 605 Enumerated | M | P | | V | Y | 606 Management-Policy-Id | | | | | | 607 UTF8String | M | P | | V | Y | 608 Management-Privilege-Level | | | | | | 609 Integer | M | P | | V | Y | 610 ---------------------------------|----+-----+----+-----|----| 612 The attributes in this specification have no special translation 613 requirements for Diameter to RADIUS or RADIUS to Diameter gateways; 614 they are copied as is, except for changes relating to headers, 615 alignment, and padding. See also [RFC3588] Section 4.1 and [RFC4005] 616 Section 9. 618 What this specification says about the applicability of the 619 attributes for RADIUS Access-Request packets applies in Diameter to 620 AA-Request [RFC4005]. 622 What is said about Access-Accept applies in Diameter to AA-Answer 623 messages that indicate success. 625 11. RADIUS Proxy Operation Considerations 627 The device management access authorization attributes presented in 628 this document present certain considerations when used in RADIUS 629 proxy environments. These considerations are not different from 630 those that exist in RFC 2865 [RFC2865] with respect to the Service- 631 Type attribute values of Administrative and NAS-Prompt. 633 Most RADIUS proxy environments are also multi-party environments. In 634 multi-party proxy environments it is important to distinguish which 635 entities have the authority to provision management access to the 636 edge devices, i.e. NASes, and which entities only have authority to 637 provision network access services of various sorts. 639 It may be important that operators of the NAS are able to ensure that 640 access to the CLI, or other management interfaces, of the NAS are 641 only provisioned to their own employees or contractors. One way for 642 the NAS to enforce this requirement is to use only local, non-proxy 643 RADIUS servers for management access requests. Proxy RADIUS servers 644 could be used for non-management access requests, based on local 645 policy. This "bifurcation" of RADIUS authentication and 646 authorization is a simple case of separate administrative realms. 647 The NAS may be designed so as to maintain separate lists of RADIUS 648 servers for management AAA use and for non-management AAA use. 650 An alternate method of enforcing this requirement would be for the 651 first-hop RADIUS proxy server, operated by the owner of the NAS, to 652 filter out any RADIUS attributes that provision management access 653 rights that originate from "up-stream" proxy servers not operated by 654 the NAS owner. Access-Accept messages that provision such locally 655 un-authorized management access MAY be treated as if they were an 656 Access-Reject by the first-hop proxy server. 658 These issues are not of concern when all the RADIUS servers, local 659 and proxy, used by the NAS are under the sole administrative control 660 of the NAS owner. 662 12. Table of Attributes 664 The following table provides a guide to which attributes may be found 665 in which kinds of packets, and in what quantity. 667 Access- 668 Request Accept Reject Challenge # Attribute 669 --------------------------------------------------------------------- 670 0-1 0-1 0 0 TBA Framed-Management-Protocol 671 0-1 0-1 0 0 TBA Management-Transport-Protection 672 0 0-1 0 0 TBA Management-Policy-Id 673 0 0-1 0 0 TBA Management-Privilege-Level 675 Accounting- 676 Request Response # Attribute 677 --------------------------------------------------------------------- 678 0-1 0 TBA Framed-Management-Protocol 679 0-1 0 TBA Management-Transport-Protection 680 0-1 0 TBA Management-Policy-Id 681 0-1 0 TBA Management-Privilege-Level 683 The following table defines the meaning of the above table entries. 685 0 This attribute MUST NOT be present in a packet. 686 0+ Zero or more instances of this attribute MAY be present in 687 a packet. 688 0-1 Zero or one instance of this attribute MAY be present in 689 a packet. 690 1 Exactly one instance of this attribute MUST be present in 691 a packet. 693 13. IANA Considerations 695 Note to RFC Editor: Remove this paragraph upon publication as an RFC. 696 This document contains placeholders ("TBA") for assigned numbers 697 within the RADIUS Attributes registry, to be assigned by IANA at the 698 time this document should be published as an RFC. 700 Assignment of additional enumerated values for RADIUS attributes 701 defined in this document are to be processed as described in 702 [RFC3575], subject to the additional minimum requirement that a 703 published specification is always required. 705 14. Security Considerations 707 This specification describes the use of RADIUS and Diameter for 708 purposes of authentication, authorization and accounting for 709 management access to devices within networks. RADIUS threats and 710 security issues for this application are described in [RFC3579] and 711 [RFC3580]; security issues encountered in roaming are described in 712 [RFC2607]. For Diameter, the security issues relating to this 713 application are described in [RFC4005] and [RFC4072]. 715 This document specifies new attributes that can be included in 716 existing RADIUS packets, which may be protected as described in 717 [RFC3579] and [RFC3576]. In Diameter, the attributes are protected 718 as specified in [RFC3588]. See those documents for a more detailed 719 description. 721 The security mechanisms supported in RADIUS and Diameter are focused 722 on preventing an attacker from spoofing packets or modifying packets 723 in transit. They do not prevent an authorized RADIUS/Diameter server 724 or proxy from inserting attributes with malicious intent. 726 Any of the attributes described in this memo, with the exception of 727 Service-Type, may not be understood by the NAS which receives it. A 728 legacy NAS not compliant with this specification may silently discard 729 these attributes while permitting the user to access the management 730 interface(s) of the NAS. This can lead to users improperly receiving 731 unauthorized management access to the NAS, or access with greater 732 levels of access rights than were intended. RADIUS servers SHOULD 733 attempt to ascertain whether or not the NAS supports these attributes 734 before sending them in an Access-Accept. 736 It is possible that certain NAS implementations may not be able to 737 determine the protection properties of the underlying transport 738 protocol as specified by the Management-Transport-Protection 739 attribute. This may be a limitation of the standard application 740 programming interface of the underlying transport implementation or 741 of the integration of the transport into the NAS implementation. In 742 either event, NASes conforming to this specification, which cannot 743 determine the protection state of the remote management connection 744 SHOULD treat an Access-Accept message containing a Management- 745 Transport-Protocol attribute containing a value other than No- 746 Protection (1) as if it were an Access-Reject message, unless 747 specifically overridden by local policy configuration. 749 15. Acknowledgments 751 Many thanks to all reviewers, including Barney Wolff, Mauricio 752 Sanchez, David Harrington, Juergen Schoenwaelder, Bernard Aboba. 754 16. References 756 16.1. Normative References 758 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 759 Requirement Levels", BCP 14, RFC 2119, March 1997. 761 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 762 "Remote Authentication Dial In User Service (RADIUS)", 763 RFC 2865, June 2000. 765 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 766 10646", STD 63, RFC 3629, November 2003. 768 16.2. Informative References 770 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 771 Implementation in Roaming", RFC 2607, June 1999. 773 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 775 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 776 Access Control Model (VACM) for the Simple Network 777 Management Protocol (SNMP)", STD 62, RFC 3415, 778 December 2002. 780 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 781 Authentication Dial In User Service)", RFC 3575, 782 July 2003. 784 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 785 Aboba, "Dynamic Authorization Extensions to Remote 786 Authentication Dial In User Service (RADIUS)", RFC 3576, 787 July 2003. 789 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 790 Dial In User Service) Support For Extensible 791 Authentication Protocol (EAP)", RFC 3579, September 2003. 793 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 794 "IEEE 802.1X Remote Authentication Dial In User Service 795 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 797 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 798 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 800 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 801 "Diameter Network Access Server Application", RFC 4005, 802 August 2005. 804 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 805 Authentication Protocol (EAP) Application", RFC 4072, 806 August 2005. 808 Authors' Addresses 810 David B. Nelson 811 Elbrys Networks, Inc. 812 75 Rochester Avenue, Unit 3 813 Portsmouth, NH 03801 814 USA 816 Email: d.b.nelson@comcast.net 818 Greg Weber 820 Email: gdweber@gmail.com 822 Full Copyright Statement 824 Copyright (C) The IETF Trust (2008). 826 This document is subject to the rights, licenses and restrictions 827 contained in BCP 78, and except as set forth therein, the authors 828 retain all their rights. 830 This document and the information contained herein are provided on an 831 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 832 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 833 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 834 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 835 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 836 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 838 Intellectual Property 840 The IETF takes no position regarding the validity or scope of any 841 Intellectual Property Rights or other rights that might be claimed to 842 pertain to the implementation or use of the technology described in 843 this document or the extent to which any license under such rights 844 might or might not be available; nor does it represent that it has 845 made any independent effort to identify any such rights. Information 846 on the procedures with respect to rights in RFC documents can be 847 found in BCP 78 and BCP 79. 849 Copies of IPR disclosures made to the IETF Secretariat and any 850 assurances of licenses to be made available, or the result of an 851 attempt made to obtain a general license or permission for the use of 852 such proprietary rights by implementers or users of this 853 specification can be obtained from the IETF on-line IPR repository at 854 http://www.ietf.org/ipr. 856 The IETF invites any interested party to bring to its attention any 857 copyrights, patents or patent applications, or other proprietary 858 rights that may cover technology that may be required to implement 859 this standard. Please address the information to the IETF at 860 ietf-ipr@ietf.org. 862 Acknowledgment 864 Funding for the RFC Editor function is provided by the IETF 865 Administrative Support Activity (IASA).