idnits 2.17.1 draft-ietf-isms-radius-usage-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 31, 2009) is 5441 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) -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-isms-tmsm' -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-isms-transport-security-model' == Outdated reference: A later version (-07) exists of draft-ietf-radext-management-authorization-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Narayan 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track D. Nelson 5 Expires: December 2, 2009 Elbrys Networks, Inc. 6 May 31, 2009 8 Remote Authentication Dial-In User Service (RADIUS) Usage for Simple 9 Network Management Protocol (SNMP) Transport Models 10 draft-ietf-isms-radius-usage-07.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on December 2, 2009. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This memo describes the use of a Remote Authentication Dial-In User 59 Service (RADIUS) authentication and authorization service with Simple 60 Network Management Protocol (SNMP) secure Transport Models to 61 authenticate users and authorize creation of secure transport 62 sessions. While the recommendations of this memo are generally 63 applicable to a broad class of SNMP Transport Models, the examples 64 focus on the Secure Shell Transport Model. 66 Requirements Language 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [RFC2119]. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.2. System Block Diagram . . . . . . . . . . . . . . . . . . . 4 77 1.3. RADIUS Operational Model . . . . . . . . . . . . . . . . . 5 78 1.4. RADIUS Usage With Secure Transports . . . . . . . . . . . 6 79 1.5. Domain of Applicability . . . . . . . . . . . . . . . . . 7 80 1.6. SNMP Transport Models . . . . . . . . . . . . . . . . . . 8 81 2. RADIUS Usage for SNMP Transport Models . . . . . . . . . . . . 8 82 2.1. RADIUS Authentication for Transport Protocols . . . . . . 9 83 2.2. RADIUS Authorization for Transport Protocols . . . . . . . 10 84 2.3. SNMP Service Authorization . . . . . . . . . . . . . . . . 10 85 3. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 12 86 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 88 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 91 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 94 1. Introduction 96 1.1. General 98 This memo describes the use of a Remote Authentication Dial-In User 99 Service (RADIUS) authentication and authorization service by Simple 100 Network Management Protocol (SNMP) secure Transport Models to 101 authenticate users and authorize creation of secure transport 102 sessions. While the recommendations of this memo are generally 103 applicable to a broad class of SNMP Transport Models, the examples 104 focus on the Secure Shell Transport Model. 106 In the context of this document, a Network Access Server (NAS) is a 107 network device or host that contains an SNMP engine implementation, 108 utilizing SNMP Transport Models. It is customary in SNMP documents 109 to indicate which subsystem performs specific processing tasks. In 110 this document we leave such decisions to the implementer, as is 111 customary for RADIUS documents, and simply specify NAS behavior. 112 Such processing would quite likely be implemented in the secure 113 transport module. 115 1.2. System Block Diagram 117 A block diagram of the major system components referenced in this 118 document may be useful to understanding the text that follows. 120 +--------+ 121 +......................... |RADIUS |....+ 122 . |Server | . 123 Shared +--------+ . 124 User | . 125 Credentials RADIUS | Shared 126 . | RADIUS 127 . | Secret 128 . | . 129 +-------------+ +-----------------+ 130 | Network | | RADIUS Client / | 131 | Management | SNMP | SNMP Engine / | 132 | Application |------------------| Network Device | 133 +-------------+ SSH +-----------------+ 135 Block Diagram 137 This diagram illustrates that a network management application 138 communicates with a network device, the managed entity, using SNMP 139 over SSH. The network devices uses RADIUS to communicte with a 140 RADIUS Server to authenticate the network management application (or 141 the user whose credentials that application provides) and to obtain 142 authorization information related to access via SNMP for purpose of 143 device management. Other secure transport protocols might be used 144 instead of SSH. 146 1.3. RADIUS Operational Model 148 The RADIUS protocol [RFC2865] provides authentication and 149 authorization services for network access devices, usually referred 150 to as a Network Access Server (NAS). The RADIUS protocol operates, 151 at the most simple level, as a request-response mechanism. RADIUS 152 Clients, within the NAS, initiate a transaction by sending a RADIUS 153 Access-Request message to a RADIUS Server, with which the client 154 shares credentials. The RADIUS Server will respond with either an 155 Access-Accept message or an Access-Reject message. 157 RADIUS supports authentication methods compatible with plaintext 158 username and password mechanisms, MD5 Challenge/Response mechanisms, 159 Extensible Authentication Protocol (EAP) mechanisms, and HTTP Digest 160 mechanisms. Upon presentation of identity and credentials the user 161 is either accepted or rejected. RADIUS servers indicate a successful 162 authentication by returning an Access-Accept message. An Access- 163 Reject message indicates unsuccessful authentication. 165 Access-Accept messages are populated with one or more service 166 provisioning attributes, that control the type and extent of service 167 provided to the user at the NAS. The authorization portion may be 168 thought of as service provisioning. Based on the configuration of 169 the user's account on the RADIUS Server, upon authentication the NAS 170 is provided with instructions as to what type of service to provide 171 to the user. When that service provisioning does not match the 172 capabilities of the NAS, or of the particular interface to the NAS 173 over which the user is requesting access, RFC 2865 [RFC2865] requires 174 that the NAS MUST reject the access request. RFC 2865 describes 175 service provisioning attributes for management access to a NAS, as 176 well as various terminal emulation and packet forwarding services on 177 the NAS. This memo describes specific RADIUS service provisioning 178 attributes that are useful for use with secure transports and SNMP 179 Transport Models. 181 RADIUS servers are often deployed on an enterprise-wide or 182 organization-wide basis, covering a variety of disparate use cases. 183 In such deployments, all NASes and all users are serviced by a common 184 pool of RADIUS servers. In many deployments, the RADIUS Server will 185 handle requests from many different types of NASes with different 186 capabilities, and different types of interfaces, services and 187 protocol support. 189 In order for a RADIUS server to make the correct authorization 190 decision in all cases, the server will often need to know something 191 about the type of NAS at which the user is requesting access, the 192 type of service that the user is requesting, and the role of the user 193 in the organization. For example, many users may be authorized to 194 receive network access via a Remote Access Server (RAS), Virtual 195 Private Network (VPN) server, or LAN access switch. Typically only a 196 small sub-set of all users are authorized to access the 197 administrative interfaces of network infrastructure devices, e.g. the 198 Command Line Interface (CLI) or SNMP engine of switches and routers. 200 In order for the RADIUS server to have information regarding the type 201 of access being requested, it is common for the NAS (i.e. the RADIUS 202 client) to include "hint" attributes in the RADIUS Access-Request 203 message, describing the NAS and the type of service being requested. 204 This document recommends appropriate "hint" attributes for the SNMP 205 service type. 207 1.4. RADIUS Usage With Secure Transports 209 Some secure transport protocols that can be used with SNMP Transport 210 Models have defined authentication protocols supporting several 211 authentication methods. For example, the Secure Shell (SSH) 212 Authentication protocol [RFC4252] supports multiple methods (Public 213 Key, Password, Host-Based) to authenticate SSH clients. 215 SSH Server integration with RADIUS traditionally uses the username 216 and password mechanism. 218 Secure transport protocols do not, however, specify how the transport 219 interfaces to authentication clients, leaving such as implementation 220 specific. For e.g., the "password" method of SSH authentication 221 primarily describes how passwords are acquired from the SSH client 222 and transported to the SSH server, the interpretation of the password 223 and validation against password databases is left to SSH server 224 implementations. SSH server implementations often use the Pluggable 225 Authentication Modules (PAM) 226 [http://www.opengroup.org/rfc/rfc86.0.html] interface provided by 227 operating systems such as Linux and Solaris to integrate with 228 password based network authentication mechanisms such as RADIUS, 229 TACACS+, Kerberos, etc. 231 Secure transports do not typically specify how to utilize 232 authorization information obtained from an AAA service, such as 233 RADIUS. More often, user authentication is sufficient to cause the 234 secure transport server to begin delivering service to the user. 236 Access control in these situations is supplied by the application to 237 which the secure transport server session is attached. For example, 238 if the application is a Linux shell, the user's access rights are 239 controlled by that user account's group membership and the file 240 system access protections. This behavior does not closely follow the 241 traditional service provisioning model of AAA systems, such as 242 RADIUS. 244 1.5. Domain of Applicability 246 Most of the RADIUS Attributes referenced in this document have broad 247 applicability for provisioning remote management access to NAS 248 devices using SNMP. However, the selection of secure transport 249 protocols has special considerations. This document does not specify 250 details of the integration of secure transport protocols with a 251 RADIUS client in the NAS implementation. However, there are 252 functional requirements for correct application of framed management 253 protocols and secure transport protocols that will limit the 254 selection of such protocols that can be considered for use with 255 RADIUS. Since the RADIUS user credentials are obtained by the RADIUS 256 client from the secure transport protocol server, or in some cases 257 directly from the SNMP engine, the secure transport protocol, and its 258 implementation in the NAS, MUST support forms of credentials that are 259 compatible with the authentication methods supported by RADIUS. 261 RADIUS currently supports the following user authentication methods, 262 although others may be added in the future: 264 o Password (RFC 2865) 265 o CHAP (RFC 2865) 266 o ARAP (RFC 2869) 267 o EAP (RFC 2869, RFC 3579) 268 o HTTP Digest (RFC 5090) 270 The secure transport protocols selected for use with RADIUS and SNMP 271 obviously need to support user authentication methods that are 272 compatible with those that exist in RADIUS. The RADIUS 273 authentication methods most likely usable with these protocols are 274 Password, CHAP and possibly HTTP Digest, with Password being the 275 distinct common denominator. There are many secure transports that 276 support other, more robust, authentication mechanisms, such as public 277 key. RADIUS has no support for public key authentication, except 278 within the context of an EAP Method. The applicability statement for 279 EAP indicates that it is not intended for use as an application-layer 280 authentication mechanism, so its use with the mechanisms described in 281 this document is NOT RECOMMENDED. In some cases, Password may be the 282 only compatible RADIUS authentication method available. 284 1.6. SNMP Transport Models 286 The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines a 287 mechanism for providing transport layer security for SNMP, allowing 288 protocols such as SSH and TLS to be used to secure SNMP 289 communication. The Transport Subsystem allows the modular definition 290 of Transport Models for multiple secure transport protocols. 291 Transport Models rely upon the underlying secure transport for user 292 authentication services. The Transport Model (TM) then maps the 293 authenticated identity to a model-independent principal, which it 294 stores in the tmStateReference. When the selected security model is 295 the Transport Security Model (TSM), the expected behavior is for the 296 securityName to be set by the TSM from the authenticated principal 297 information stored in the tmStateReference by the TM. 299 The Secure Shell protocol provides a secure transport channel with 300 support for channel authentication via local accounts and integration 301 with various external authentication and authorization services such 302 as RADIUS, Kerberos, etc. The Secure Shell Transport Model 303 [I-D.ietf-isms-secshell] defines the use of the Secure Shell protocol 304 as the basis for a Transport Model. 306 2. RADIUS Usage for SNMP Transport Models 308 There are two use cases for RADIUS support of management access via 309 SNMP. These are (a) service authorization and (b) access control 310 authorization. RADIUS almost always involves user authentication as 311 prerequisite to authorization, and there is a user authentication 312 phase for each of these two use cases. The first use case is 313 discussed in detail in this memo, while the second use case is a 314 topic of current research, and beyond the scope of this document. 315 This document describes the way in which RADIUS attributes and 316 messages are applied to the specific application area of SNMP 317 Transport Models. User authentication and service authorization via 318 RADIUS are undertaken by the secure transport module, that underlies 319 the SNMP Transport Model. 321 User authentication for SNMP Transport Models has the same syntax and 322 semantics as user authentication for any other network service. In 323 the context of SNMP the "user" is thought of as a "principal" and may 324 represent a host, an application or a human. 326 Service authorization allows a RADIUS server to authorize an 327 authenticated principal to use SNMP, optionally over a secure 328 transport, typically using an SNMP Transport Model. This memo 329 describes mechanisms by which such information can be requested from 330 a RADIUS server and enforced within the NAS. An SNMP architecture, 332 [RFC3411], does not make a distinction between user authentication 333 and service authorization. In the case of existing, deployed 334 security models, such as the User-based Security Model (USM), this 335 distinction is not significant. For SNMP Transport Models, this 336 distinction is relevant and important. 338 It is relevant because of the way in which SSH implementations have 339 traditionally integrated with RADIUS Clients. Those SSH 340 implementations traditionally seek to obtain user authentication 341 (e.g. validation of a username and password) from an outside 342 authentication service, often via a Pluggable Authentication Module 343 (PAM) style interface. The service authorization in traditional SSH 344 server implementations comes via the restrictions that the operating 345 system (OS) shell (and file system, etc.) place on the user by means 346 of access controls tied to the username or the username's membership 347 in various user groups. These OS-style access controls are distinct 348 from the service provisioning features of RADIUS. If we wish to use 349 existing SSH server implementations, or slightly adapt them, for use 350 with SNMP Transport Models, and we wish to support RADIUS-provisioned 351 service authorization, we need to be aware that the RADIUS service 352 authorization information will need to be obtained by the relevant 353 SNMP models from the SSH module. 355 One reason that RADIUS-provisioned service authorization is important 356 is that in many deployments the RADIUS server's back-end 357 authentication database contains credentials for many classes of 358 users, only a small portion of which may be authorized to access the 359 management interfaces of managed entities (NASes) via SNMP. This is 360 in contrast to the way USM for SNMP works, in which all principals 361 entered to the local configuration data-store are authorized for 362 access to the managed entity. In the absence of RADIUS-provisioned 363 service authorization, network management access may be granted to 364 unauthorized, but properly authenticated, users. With SNMPv3, an 365 appropriately configured Access Control Model would serve to 366 alleviate the risk of unauthorized access. 368 2.1. RADIUS Authentication for Transport Protocols 370 This document will rely on implementation specific integration of the 371 transport protocols with RADIUS clients for user authentication. 373 It is REQUIRED that the integration of RADIUS clients with transport 374 protocols utilize appropriate "hint" attributes in RADIUS Access- 375 Request messages, to signal to the RADIUS server the type of service 376 being requested over the transport session. Specific attributes for 377 use with SNMP Transport Models are recommended in this document. 379 RADIUS servers, compliant to this specification, MAY use RADIUS hint 380 attributes, as described herein, to inform the decision whether to 381 accept or reject the authentication request. 383 2.2. RADIUS Authorization for Transport Protocols 385 In compliance with RFC 2865, NASes MUST enforce implicitly mandatory 386 attributes, such as Service-Type, within an Access-Accept message. 387 NASes MUST treat Access-Accept Messages that attempt to provision 388 unsupported services as if they were an Access-Reject. NASes SHOULD 389 treat unknown attributes as if they were provisioning unsupported 390 services. See [RFC5080] for additional details. 392 A NAS that is compliant to this specification, MUST treat any RADIUS 393 Access-Accept message that provisions a level of transport protection 394 (e.g. SSH) that cannot be provided, and/or application service (e.g. 395 SNMP) that cannot be provided over that transport, as if an Access- 396 Reject message had been received instead. The RADIUS Service-Type 397 Attribute is the primary indicator of the service being provisioned, 398 although other attributes may also convey service provisioning 399 information. 401 For traditional SSH usage, RADIUS servers typically provision 402 management access service, as SSH is often used to access the command 403 line shell of a host system, e.g. the NAS. RFC 2865 defines two 404 types of management access service attributes, one for privileged 405 access to the Command Line Interface (CLI) of the NAS and one for 406 non-privileged CLI access. These traditional management access 407 services are not used with SNMP. 408 [I-D.ietf-radext-management-authorization] describes further RADIUS 409 service provisioning attributes for management access to the NAS, 410 including SNMP access. 412 2.3. SNMP Service Authorization 414 The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines the 415 notion of a session, although the specifics of how sessions are 416 managed is left to Transport Models. The Transport Subsystem defines 417 some basic requirements for transport protocols around creation and 418 deletion of sessions. This memo specifies additional requirements 419 for transport protocols during session creation, and for session 420 termination. 422 RADIUS servers compliant to this specification MUST use RADIUS 423 service provisioning attributes, as described herein, to specify SNMP 424 access over a secure transport. Such RADIUS servers MAY use RADIUS 425 hint attributes included in the Access-Request message, as described 426 herein, in determining what, if any, service to provision. 428 NASes compliant to this specification MUST use RADIUS service 429 provisioning attributes, as described in this section, when they are 430 present in a RADIUS Access-Accept message, to determine whether the 431 session can be created and MUST enforce the service provisioning 432 decisions of the RADIUS server. 434 The following RADIUS attributes MUST be used, as hint attributes 435 included in the Access-Request message to signal use of SNMP over a 436 secure transport (i.e. authPriv) to the RADIUS server: 438 1. Service-Type with a value of Framed-Management. 439 2. Framed-Management-Protocol with a value of SNMP. 440 3. Management-Transport-Protection with a value of Integrity- 441 Confidentiality-Protection. 443 The following RADIUS attributes MUST be used in an Access-Accept 444 message to provision SNMP over a secure transport which provides both 445 integrity and confidentiality (i.e. authPriv): 447 1. Service-Type with a value of Framed-Management. 448 2. Framed-Management-Protocol with a value of SNMP. 449 3. Management-Transport-Protection with a value of Integrity- 450 Confidentiality-Protection. 452 The following RADIUS attributes MUST be optionally used, to authorize 453 use of SNMP without protection (i.e. authNoPriv): 455 1. Service-Type with a value of Framed-Management. 456 2. Framed-Management-Protocol with a value of SNMP. 457 3. Management-Transport-Protection with a value of No-Protection. 459 There are no combinations of RADIUS attributes that denote the 460 equivalent of SNMP noAuthNoPriv access, as RADIUS always involves the 461 authentication of a user (i.e. a principal) as a prerequisite for 462 authorization. RADIUS can be used to provide an "Authorize-Only" 463 service, but only when the request contains a "cookie" from a 464 previous successful authentication with the same RADIUS server (i.e. 465 the RADIUS State Attribute). 467 The following RADIUS attributes are used to limit the extent of a 468 secure transport session carrying SNMP traffic, in conjunction with 469 an SNMP Transport Model: 471 1. Session-Timeout 472 2. Inactivity-Timeout. 474 Refer to [RFC2865] for a detailed description of these attributes. 475 The Session-Timeout Attribute indicates the maximum number of seconds 476 that a session may exist before it is unconditionally disconnected. 477 The Inactivity-Timeout Attribute indicates the maximum number of 478 seconds that a transport session may exist without any protocol 479 activity (messages sent or received) before the session is 480 disconnected. These timeouts are enforced by the NAS. 482 3. Table of Attributes 484 Table 1 provides a guide to which attributes may be found in which 485 kinds of packets, and in what quantity. 487 Access- 488 Request Accept Reject Challenge # Attribute 489 --------------------------------------------------------------------- 490 0-1 0 0 0 1 User-Name [RFC2865] 491 0-1 0 0 0 2 User-Password [RFC2865] 492 0-1 * 0 0 0 4 NAS-IP-Address [RFC2865] 493 0-1 * 0 0 0 95 NAS-IPv6-Address {RFC3162] 494 0-1 * 0 0 0 32 NAS-Identifier [RFC2865] 495 0-1 0-1 0 0 6 Service-Type [RFC2865] 496 0-1 0-1 0 0-1 24 State [RFC2865] 497 0 0-1 0 0 27 Session-Timeout [RFC2865] 498 0 0-1 0 0 28 Idle-Timeout [RFC2865] 499 0-1 0-1 0-1 0-1 80 Message-Authenticator [RFC3579] 500 0-1 0-1 0 0 TBA-2 Framed-Management-Protocol 501 [I-D.ietf-radext-management-authorization] 502 0-1 0-1 0 0 TBA-3 Management-Transport-Protection 503 [I-D.ietf-radext-management-authorization] 505 Table 1 507 Table 2 defines the meaning of the entries in Table 1. 509 0 This attribute MUST NOT be present in a packet. 510 0+ Zero or more instances of this attribute MAY be present in 511 a packet. 512 0-1 Zero or one instance of this attribute MAY be present in 513 a packet. 514 1 Exactly one instance of this attribute MUST be present in 515 a packet. 516 * Only one of these attribute options SHOULD be included. 518 Table 2 520 SSH integration with RADIUS traditionally uses usernames and 521 passwords (with the User-Password Attribute), but other secure 522 transports could use other authentication mechanisms, and would 523 include RADIUS authentication attributes appropriate for that 524 mechanism instead of User-Password. 526 This document does not describe the usage of RADIUS Accounting, nor 527 Dynamic RADIUS Re-Authorization. Such RADIUS usages are not 528 currently envisioned for SNMP, and are beyond the scope of this 529 document. 531 4. IANA Considerations 533 This document makes no requests of IANA for new allocations, however 534 there are placeholder values ("TBA-n") in Section 3, that refer to 535 IANA assignments to be made in 536 [I-D.ietf-radext-management-authorization], which should be replaced 537 with actual values in this document, based on the corresponding IANA 538 assignments for [I-D.ietf-radext-management-authorization]. 540 5. Security Considerations 542 This specification describes the use of RADIUS for purposes of 543 authentication and authorization. Threats and security issues for 544 this application are described in [RFC3579] and [RFC3580]; security 545 issues encountered in roaming are described in [RFC2607]. 547 Additional security considerations for use of SNMP with secure 548 Transport Models [I-D.ietf-isms-tmsm] and the Transport Security 549 Model [I-D.ietf-isms-transport-security-model] are found in the 550 Security Considerations sections of the respective documents. 552 If the SNMPv1 or SNMPv2c Security Model is used, then securityName 553 comes from the community name, as per RFC3584. If the User-based 554 Security Model is selected, then securityName is determined using 555 USM. This may not be what is expected when using an SNMP secure 556 Transport Model with an external authentication service, such as 557 RADIUS. 559 Simultaneously using a secure transport with RADIUS authentication 560 and authorization, and the SNMPv1 or SNMPv2c or USM security models 561 is NOT RECOMMENDED. See the coexistence section of 562 [I-D.ietf-isms-tmsm]. 564 There are good reasons to provision USM access to supplement with 565 AAA-based access, however. When the network is under duress, or the 566 AAA-service is unreachable, for any reason, it is important to have 567 access credentials stored in the local configuration data-store of 568 the managed entity. USM credentials are a likely way to fulfill this 569 requirement. This is analogous to configuring a local "root" 570 password in the "/etc/passwd" file of a UNIX workstation, to be used 571 as a backup means of login, for times when the Network Information 572 Service (NIS) authentication service is unreachable. 574 The Message-Authenticator (80) attribute [RFC3579] SHOULD be used 575 with RADIUS messages that are described in this memo. This is useful 576 because the Message-Authenticator Attribute is the best available 577 mechanism in RADIUS as it stands today to provide tamper-evident 578 integrity protection of the service provisioning attributes in an 579 Access-Accept packet. It is slightly less important for Access- 580 Request packets, although it may be desirable to protect any "hint" 581 attributes contained in those messages. This protection mitigates 582 the fact that RADIUS messages are not encrypted and that attributes 583 could be added, deleted or modified by an adversary in a position to 584 intercept the packet. 586 6. Acknowledgements 588 The authors would like to acknowledge the contributions of David 589 Harrington and Juergen Schoenwaelder for numerous helpful discussions 590 in this space, and Wes Hardaker for his thoughtful review comments. 592 7. References 594 7.1. Normative References 596 [I-D.ietf-isms-tmsm] 597 Harrington, D. and J. Schoenwaelder, "Transport Subsystem 598 for the Simple Network Management Protocol (SNMP)", 599 draft-ietf-isms-tmsm-18 (work in progress), May 2009. 601 [I-D.ietf-isms-transport-security-model] 602 Harrington, D. and W. Hardaker, "Transport Security Model 603 for SNMP", draft-ietf-isms-transport-security-model-14 604 (work in progress), May 2009. 606 [I-D.ietf-radext-management-authorization] 607 Nelson, D. and G. Weber, "Remote Authentication Dial-In 608 User Service (RADIUS) Authorization for Network Access 609 Server (NAS) Management", 610 draft-ietf-radext-management-authorization-06 (work in 611 progress), October 2008. 613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, March 1997. 616 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 617 "Remote Authentication Dial In User Service (RADIUS)", 618 RFC 2865, June 2000. 620 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 621 Dial In User Service (RADIUS) Implementation Issues and 622 Suggested Fixes", RFC 5080, December 2007. 624 7.2. Informative References 626 [I-D.ietf-isms-secshell] 627 Harrington, D., Salowey, J., and W. Hardaker, "Secure 628 Shell Transport Model for SNMP", 629 draft-ietf-isms-secshell-18 (work in progress), May 2009. 631 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 632 Implementation in Roaming", RFC 2607, June 1999. 634 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 635 Architecture for Describing Simple Network Management 636 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 637 December 2002. 639 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 640 Dial In User Service) Support For Extensible 641 Authentication Protocol (EAP)", RFC 3579, September 2003. 643 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 644 "IEEE 802.1X Remote Authentication Dial In User Service 645 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 647 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 648 Authentication Protocol", RFC 4252, January 2006. 650 Authors' Addresses 652 Kaushik Narayan 653 Cisco Systems, Inc. 654 10 West Tasman Drive 655 San Jose, CA 95134 656 USA 658 Phone: +1.408.526.8168 659 Email: kaushik_narayan@yahoo.com 660 David Nelson 661 Elbrys Networks, Inc. 662 75 Rochester Ave, Unit #3, 663 Portsmouth, NH 03801 664 USA 666 Phone: +1.603.570.2636 667 Email: d.b.nelson@comcast.net