idnits 2.17.1 draft-ietf-isms-radius-usage-04.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 625. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 643. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 649. 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 (October 12, 2008) is 5674 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) == Outdated reference: A later version (-18) exists of draft-ietf-isms-secshell-12 == Outdated reference: A later version (-18) exists of draft-ietf-isms-tmsm-13 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-isms-tmsm' == Outdated reference: A later version (-14) exists of draft-ietf-isms-transport-security-model-09 -- 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 (~~), 6 warnings (==), 9 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: April 15, 2009 Elbrys Networks, Inc. 6 October 12, 2008 8 Remote Authentication Dial-In User Service (RADIUS) Usage for Simple 9 Network Management Protocol (SNMP) Transport Models 10 draft-ietf-isms-radius-usage-04.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 15, 2009. 37 Abstract 39 This memo describes the use of a Remote Authentication Dial-In User 40 Service (RADIUS) authentication and authorization service by Simple 41 Network Management Protocol (SNMP) secure Transport Models to 42 authenticate users and authorize creation of secure transport 43 sessions. While the recommendations of this memo are generally 44 applicable to a broad class of SNMP Transport Models, the examples 45 focus on the Secure Shell Transport Model. 47 Requirements Language 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in [RFC2119]. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. RADIUS Operational Model . . . . . . . . . . . . . . . . . 3 58 1.3. RADIUS Usage With Secure Transports . . . . . . . . . . . 4 59 1.4. SNMP Transport Models . . . . . . . . . . . . . . . . . . 5 60 2. RADIUS Usage for SNMP Transport Models . . . . . . . . . . . . 6 61 2.1. RADIUS Authentication for Transport Protocols . . . . . . 7 62 2.2. RADIUS Authorization for Transport Protocols . . . . . . . 7 63 2.3. SNMP Service Authorization . . . . . . . . . . . . . . . . 8 64 2.4. SNMP Access Control Authorization . . . . . . . . . . . . 10 65 3. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 10 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 73 Intellectual Property and Copyright Statements . . . . . . . . . . 15 75 1. Introduction 77 1.1. General 79 This memo describes the use of a Remote Authentication Dial-In User 80 Service (RADIUS) authentication and authorization service by Simple 81 Network Management Protocol (SNMP) secure Transport Models to 82 authenticate users and authorize creation of secure transport 83 sessions. While the recommendations of this memo are generally 84 applicable to a broad class of SNMP Transport Models, the examples 85 focus on the Secure Shell Transport Model. 87 In the context of this document, a Network Access Server (NAS) is a 88 network device or host that contains an SNMP engine implementation, 89 utilizing SNMP Transport Models. It is customary in SNMP documents 90 to indicate which subsystem performs specific processing tasks. In 91 this document we leave such decisions to the implementer, as is 92 customary for RADIUS documents, and simply specify NAS behavior. 93 Such processing would quite likely be implemented in the secure 94 transport module or, less likely, in one or more modules of the SNMP 95 engine. 97 1.2. RADIUS Operational Model 99 The RADIUS protocol [RFC2865] provides authentication and 100 authorization services for network access devices, usually referred 101 to as a Network Access Server (NAS). The RADIUS protocol operates, 102 at the most simple level, as a request-response mechanism. RADIUS 103 Clients, within the NAS, initiate a transaction by sending a RADIUS 104 Access-Request message to a RADIUS Server, with which the client 105 shares credentials. The RADIUS Server will respond with either an 106 Access-Accept message or an Access-Reject message. 108 RADIUS supports authentication methods compatible with plaintext 109 username and password mechanisms, MD5 Challenge/Response mechanisms, 110 Extensible Authentication Protocol (EAP) mechanisms, and HTTP Digest 111 mechanisms. Upon presentation of identity and credentials the user 112 is either accepted or rejected. RADIUS servers indicate a successful 113 authentication by returning an Access-Accept message. An Access- 114 Reject message indicates unsuccessful authentication. 116 Access-Accept messages are populated with one or more service 117 provisioning attributes, that control the type and extent of service 118 provided to the user at the NAS. The authorization portion may be 119 thought of as service provisioning. Based on the configuration of 120 the user's account on the RADIUS Server, upon authentication the NAS 121 is provided with instructions as to what type of service to provide 122 to the user. When that service provisioning does not match the 123 capabilities of the NAS, or of the particular interface to the NAS 124 over which the user is requesting access, RFC 2865 [RFC2865] requires 125 that the NAS MUST reject the access request. RFC 2865 describes 126 service provisioning attributes for management access to a NAS, as 127 well as various terminal emulation and packet forwarding services on 128 the NAS. This memo describes specific RADIUS service provisioning 129 attributes that are useful for use with secure transports and SNMP 130 Transport Models. 132 RADIUS servers are often deployed on an enterprise-wide or 133 organization-wide basis, covering a variety of disparate use cases. 134 In such deployments, all NASes and all users are serviced by a common 135 pool of RADIUS servers. In many deployments, the RADIUS Server will 136 handle requests from many different types of NASes with different 137 capabilities, and different types of interfaces, services and 138 protocol support. 140 In order for a RADIUS server to make the correct authorization 141 decision in all cases, the server will often need to know something 142 about the type of NAS at which the user is requesting access, the 143 type of service that the user is requesting, and the role of the user 144 in the organization. For example, many users may be authorized to 145 receive network access via a Remote Access Server (RAS), Virtual 146 Private Network (VPN) server, or LAN access switch. Typically only a 147 small sub-set of all users are authorized to access the 148 administrative interfaces of network infrastructure devices, e.g. the 149 Command Line Interface (CLI) or SNMP engine of switches and routers. 151 In order for the RADIUS server to have information regarding the type 152 of access being requested, it is common for the NAS (i.e. the RADIUS 153 client) to include "hint" attributes in the RADIUS Access-Request 154 message, describing the NAS and the type of service being requested. 155 This document recommends appropriate "hint" attributes for the SNMP 156 service type. 158 1.3. RADIUS Usage With Secure Transports 160 Some secure transport protocols that can be used with SNMP Transport 161 Models have defined authentication protocols supporting several 162 authentication methods. For example, the Secure Shell (SSH) 163 Authentication protocol [RFC4252] supports multiple methods (Public 164 Key, Password, Host-Based) to authenticate SSH clients. 166 SSH Server integration with RADIUS traditionally uses the username 167 and password mechanism. 169 Secure transport protocols do not, however, specify how the transport 170 interfaces to authentication clients, leaving such as implementation 171 specific. For e.g., the "password" method of SSH authentication 172 primarily describes how passwords are acquired from the SSH client 173 and transported to the SSH server, the interpretation of the password 174 and validation against password databases is left to SSH server 175 implementations. SSH server implementations often use the Pluggable 176 Authentication Modules (PAM) 177 [http://www.opengroup.org/rfc/rfc86.0.html] interface provided by 178 operating systems such as Linux and Solaris to integrate with 179 password based network authentication mechanisms such as RADIUS, 180 TACACS+, Kerberos, etc. 182 Secure transports do not typically specify how to utilize 183 authorization information obtained from an AAA service, such as 184 RADIUS. More often, user authentication is sufficient to cause the 185 secure transport server to begin delivering service to the user. 186 Access control in these situations is supplied by the application to 187 which the secure transport server session is attached. For example, 188 if the application is a Linux shell, the user's access rights are 189 controlled by that user account's group membership and the file 190 system access protections. This behavior does not closely follow the 191 traditional service provisioning model of AAA systems, such as 192 RADIUS. 194 1.4. SNMP Transport Models 196 The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines a 197 mechanism for providing transport layer security for SNMP, allowing 198 protocols such as SSH and TLS to be used to secure SNMP 199 communication. The Transport Subsystem allows the modular definition 200 of Transport Models for multiple secure transport protocols. 201 Transport Models rely upon the underlying secure transport for user 202 authentication services. The Transport Model (TM) then maps the 203 authenticated identity to a model-independent principal, which it 204 stores in the tmStateReference. When the selected security model is 205 the Transport Security Model (TSM), the expected behavior is for the 206 securityName to be set by the TSM from the authenticated principal 207 information stored in the tmStateReference by the TM. 209 The Secure Shell protocol provides a secure transport channel with 210 support for channel authentication via local accounts and integration 211 with various external authentication and authorization services such 212 as RADIUS, Kerberos, etc. The Secure Shell Transport Model 213 [I-D.ietf-isms-secshell] defines the use of the Secure Shell protocol 214 as the basis for a Transport Model. 216 2. RADIUS Usage for SNMP Transport Models 218 There are three ways in which RADIUS may be used by SNMP Transport 219 Models. These include (a) user authentication, (b) service 220 authorization and (c) access control authorization. The first two 221 items are discussed in detail in this memo, while the third item is a 222 topic of current research, and beyond the scope of this document. 223 This document describes the way in which RADIUS attributes and 224 messages are applied to the specific application area of SNMP 225 Transport Models. 227 User authentication for SNMP Transport Models has the same syntax and 228 semantics as user authentication for any other network service. In 229 the context of SNMP the "user" is thought of as a "principal" and may 230 represent a host, an application or a human. 232 Service authorization allows a RADIUS server to authorize an 233 authenticated principal to use SNMP over a specific secure Transport 234 Model. This memo describes mechanisms by which such information can 235 be requested from a RADIUS server and enforced within the NAS. The 236 SNMP architecture, as described in RFC 3411 [RFC3411], does not make 237 a distinction between user authentication and service authorization. 238 In the case of existing, deployed security models, such as the User- 239 based Security Model (USM), this distinction is not significant. For 240 the SNMP Transport Models and the SNMP Transport Security Model 241 (TSM), this distinction is relevant and important. 243 It is relevant because of the way in which SSH implementations have 244 traditionally integrated with RADIUS Clients. Those SSH 245 implementations traditionally seek to obtain user authentication 246 (e.g. validation of a username and password) from an outside 247 authentication service, often via a Pluggable Authentication Module 248 (PAM) style interface. The service authorization in traditional SSH 249 server implementations comes via the restrictions that the operating 250 system (OS) shell (and file system, etc.) place on the user by means 251 of access controls tied to the username or the username's membership 252 in various user groups. These OS-style access controls are distinct 253 from the service provisioning features of RADIUS. If we wish to use 254 existing SSH server implementations, or slightly adapt them, for use 255 with SNMP Transport Models, and we wish to support RADIUS-provisioned 256 service authorization, we need to be aware that the RADIUS service 257 authorization information will need to be obtained by the relevant 258 SNMP modules from the SSH module. 260 One reason that RADIUS-provisioned service authorization is important 261 is that in many deployments the RADIUS server's back-end 262 authentication database contains credentials for many classes of 263 users, only a small portion of which may be authorized to access the 264 management interfaces of managed entities (NASes) via SNMP. This is 265 in contrast to the way USM for SNMP works, in which all principals 266 entered to the local configuration data-store are authorized for 267 access to the managed entity. In the absence of RADIUS-provisioned 268 service authorization, network management access may be granted to 269 unauthorized, but properly authenticated, users. With SNMPv3, an 270 appropriately configured Access Control Model would serve to 271 alleviate the risk of unauthorized access. 273 Data object access control authorization in SNMP is handled by the 274 Access Control Subsystem (ACS), instantiated as various Access 275 Control Models. The SNMP architecture, as described in RFC 3411 276 [RFC3411], explicitly mandates the separation of authentication and 277 authorization operations in order to retain modularity of the SNMP 278 system. The Abstract Service Interface (ASI) of the ACS uses method- 279 independent parameters, including securityName, to determine access 280 control rights. A detailed description of how an Access Control 281 Model (ACM) might utilize the services of a RADIUS client to obtain 282 access control policy information is a topic of current research, and 283 beyond the scope of this document. 285 2.1. RADIUS Authentication for Transport Protocols 287 This document will rely on implementation specific integration of the 288 transport protocols with RADIUS clients for user authentication. 290 It is RECOMMENDED that the integration of RADIUS clients with 291 transport protocols utilize appropriate "hint" attributes in RADIUS 292 Access-Request messages, to signal to the RADIUS server the type of 293 service being requested over the transport session. Specific 294 attributes for use with SNMP Transport Models are recommended in this 295 document. 297 RADIUS servers, compliant to this specification, MAY use RADIUS hint 298 attributes, as described herein, to inform the decision whether to 299 accept or reject the authentication request. 301 2.2. RADIUS Authorization for Transport Protocols 303 In compliance with RFC 2865, NASes MUST enforce implicitly mandatory 304 attributes, such as Service-Type, within an Access-Accept message. 305 NASes MUST treat Access-Accept Messages that attempt to provision 306 unsupported services as if they were an Access-Reject. NASes SHOULD 307 treat unknown attributes as if they were provisioning unsupported 308 services. See [RFC5080] for additional details. 310 A NAS that is compliant to this specification, MUST treat any RADIUS 311 Access-Accept message that provisions a transport protocol (e.g. 313 SSH) that cannot be provided, and/or application service (e.g. SNMP) 314 that cannot be provided over that transport, as if an Access-Reject 315 message had been received instead. The RADIUS Service-Type attribute 316 is the primary indicator of the service being provisioned, although 317 other attributes may also convey service provisioning information. 318 Specific attributes for use with SNMP Transport Models are 319 recommended in this document. 321 For traditional SSH usage, RADIUS servers typically provision 322 management access service, as SSH is often used to access the command 323 line shell of a host system, e.g. the NAS. RFC 2865 defines two 324 types of management access service attributes, one for privileged 325 access to the Command Line Interface (CLI) of the NAS and one for 326 non-privileged CLI access. These traditional management access 327 services are not used with SNMP. 328 [I-D.ietf-radext-management-authorization] describes further RADIUS 329 service provisioning attributes for management access to the NAS, 330 including SNMP access. 332 2.3. SNMP Service Authorization 334 The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines the 335 notion of a session, although the specifics of how sessions are 336 managed is left to Transport Models. The Transport Subsystem defines 337 some basic requirements for transport protocols around creation and 338 deletion of sessions. This memo specifies additional requirements 339 for transport protocols during session creation, and for session 340 termination. 342 RADIUS servers compliant to this specification SHOULD use RADIUS 343 service provisioning attributes, as described herein, to specify SNMP 344 access over a secure transport protocol. Such RADIUS servers MAY use 345 RADIUS hint attributes included in the Access-Request message, as 346 described herein, in determining what, if any, service to provision. 348 NASes compliant to this specification MUST use RADIUS service 349 provisioning attributes, as described in this section, when they are 350 present in a RADIUS Access-Accept message, to determine whether the 351 session can be created and MUST enforce the service provisioning 352 decisions of the RADIUS server. 354 The following RADIUS attributes SHOULD be used, as hint attributes 355 included in the Access-Request message to signal use of SNMP over a 356 secure transport (i.e. authPriv) to the RADIUS server: 358 1. Service-Type with a value of Framed-Management. 360 2. Framed-Management-Protocol with a value of SNMP. 361 3. Management-Transport-Protection with a value of Integrity- 362 Confidentiality-Protection. 364 Refer to [I-D.ietf-radext-management-authorization] for a detailed 365 description of these attributes. From the perspective of the RADIUS 366 Server, these attribute and value pairs indicate that the user is 367 requesting to use SNMP over an SNMP secure Transport Model. 369 The following RADIUS attributes are used in an Access-Accept message 370 to provision SNMP over a secure transport (i.e. authPriv): 372 1. Service-Type with a value of Framed-Management. 373 2. Framed-Management-Protocol with a value of SNMP. 374 3. Management-Transport-Protection with a value of Integrity- 375 Confidentiality-Protection. 377 Refer to [I-D.ietf-radext-management-authorization] for a detailed 378 description of these attributes. From the perspective of the NAS, 379 these attribute and value pairs indicate that the user is authorized 380 to use SNMP using an SNMP secure Transport Model. 382 The following RADIUS attributes MAY be optionally used, to authorize 383 use of SNMP without protection (i.e. authNoPriv): 385 1. Service-Type with a value of Framed-Management. 386 2. Framed-Management-Protocol with a value of SNMP. 387 3. Management-Transport-Protection with a value of No-Protection. 389 Refer to [I-D.ietf-radext-management-authorization] for a detailed 390 description of this attribute. From the perspective of the NAS, this 391 attribute and value pair indicates that the user is authorized to use 392 SNMP without a protected transport. 394 There are no combinations of RADIUS attributes that denote the 395 equivalent of SNMP noAuthNoPriv access, as RADIUS always involves the 396 authentication of a user (i.e. a principal) as a prerequisite for 397 authorization. RADIUS can be used to to provide an "Authorize-Only" 398 service, but only when the request contains a "cookie" from a 399 previous successful authentication with the same RADIUS server (i.e. 400 the RADIUS State Attribute). 402 The following RADIUS attributes are used to limit the extent of a 403 secure transport session carrying SNMP traffic, in conjunction with 404 an SNMP Transport Model: 406 1. Session-Timeout 407 2. Inactivity-Timeout. 409 Refer to [RFC2865] for a detailed description of these attributes. 410 From the perspective of the NAS, these attributes indicate session 411 timeouts to be applied to the secure transport sessions. The 412 Session-Timeout Attribute indicates the maximum number of seconds 413 that a session may exist before it is unconditionally disconnected. 414 The Inactivity-Timeout Attribute indicates the maximum number of 415 seconds that a transport session may exist without any protocol 416 activity (messages sent or received) before the session is 417 disconnected. These timeouts are enforced by the NAS. 419 2.4. SNMP Access Control Authorization 421 [I-D.ietf-radext-management-authorization] describes a RADIUS 422 attribute that can be used for SNMP access control authorization, 423 however, the details of how an SNMP Access Control Model, such as the 424 View-based Access Control Model (VACM) [RFC3415], might utilize 425 RADIUS authorization are a topic of current research, and beyond the 426 scope of this document. 428 3. Table of Attributes 430 The following table provides a guide to which attributes may be found 431 in which kinds of packets, and in what quantity. 433 Access- 434 Request Accept Reject Challenge # Attribute 435 --------------------------------------------------------------------- 436 0-1 0 0 0 1 User-Name [RFC2865] 437 0-1 0 0 0 2 User-Password [RFC2865] 438 0-1 0 0 0 4 NAS-IP-Address [RFC2865] 439 0-1 0-1 0 0 6 Service-Type [RFC2865] 440 0-1 0-1 0 0-1 24 State [RFC2865] 441 0 0-1 0 0 27 Session-Timeout [RFC2865] 442 0 0-1 0 0 28 Idle-Timeout [RFC2865] 443 0-1 0-1 0-1 0-1 80 Message-Authenticator [RFC3579] 444 0-1 0-1 0 0 TBA-2 Framed-Management-Protocol 445 [I-D.ietf-radext-management-authorization] 446 0-1 0-1 0 0 TBA-3 Management-Transport-Protection 447 [I-D.ietf-radext-management-authorization] 448 0 0+ 0 0 TBA-4 Management-Policy-Id 449 [I-D.ietf-radext-management-authorization] 451 The following table defines the meaning of the above table entries. 453 0 This attribute MUST NOT be present in a packet. 454 0+ Zero or more instances of this attribute MAY be present in 455 a packet. 456 0-1 Zero or one instance of this attribute MAY be present in 457 a packet. 458 1 Exactly one instance of this attribute MUST be present in 459 a packet. 461 Note that this document does not describe the usage of RADIUS 462 Accounting, nor Dynamic RADIUS Re-Authorization. Such RADIUS usages 463 are not currently envisioned for SNMP, and are beyond the scope of 464 this document. 466 4. IANA Considerations 468 This document makes no requests of IANA for new allocations, however 469 there are placeholder values ("TBA-n") in Section 3, that refer to 470 IANA assignments to be made in 471 [I-D.ietf-radext-management-authorization], which should be replaced 472 with actual values in this document, based on the corresponding IANA 473 assignments for [I-D.ietf-radext-management-authorization]. 475 Note to RFC Editor: This section should be removed upon publication 476 of this document as an RFC. 478 5. Security Considerations 480 This specification describes the use of RADIUS for purposes of 481 authentication and authorization. Threats and security issues for 482 this application are described in [RFC3579] and [RFC3580]; security 483 issues encountered in roaming are described in [RFC2607]. 485 Additional security considerations for use of SNMP with secure 486 Transport Models [I-D.ietf-isms-tmsm] and the Transport Security 487 Model [I-D.ietf-isms-transport-security-model] are found in the 488 Security Considerations sections of the respective documents. 490 If the SNMP Message Processing Module selects the SNMPv1 or SNMPv2c 491 Security Model as the security model to use (because the message is 492 SNMPv1 or SNMPv2), then securityName comes from the community name, 493 as per RFC3584. This may not be what is expected when using an SNMP 494 secure Transport Model. It is NOT RECOMMENDED that a combination of 495 a secure transport, RADIUS authentication/authorization, and the 496 SNMPv1 and/or SNMPv2c community models be used together, as it 497 necessitates the opening of an insecure access path within the Access 498 Control Subsystem. 500 If the SNMP User-based Security Model is selected (because the SNMPv3 501 message contains a msgSecurityModel=USM), then securityName is 502 determined using USM (after performing USM authentication). This may 503 not be what is expected when using an SNMP secure Transport Model 504 with an external authentication service, such as RADIUS. USM entries 505 for noAuthNoPriv access would allow messages utilizing USM to bypass 506 the secure transport. 508 There are good reasons to provision USM access in tandem with AAA- 509 based access, however. When the network is under duress, or the AAA- 510 service is unreachable, for any reason, it is important to have 511 access credentials stored in the local configuration data-store of 512 the managed entity. USM credentials are a likely way to fulfill this 513 requirement. This is analogous to configuring a local "root" 514 password in the "/etc/passwd" file of a UNIX workstation, to be used 515 as a backup means of login, for times when the Network Information 516 Service (NIS) authentication service is unreachable. 518 The Message-Authenticator (80) attribute SHOULD be used with RADIUS 519 messages that are described in this memo, as defined in [RFC3579]. 521 6. Acknowledgements 523 The authors would like to acknowledge the contributions of David 524 Harrington and Juergen Schoenwaelder for numerous helpful discussions 525 in this space, and Wes Hardaker for his thoughtful review comments. 527 7. References 529 7.1. Normative References 531 [I-D.ietf-isms-secshell] 532 Harrington, D., Salowey, J., and W. Hardaker, "Secure 533 Shell Transport Model for SNMP", 534 draft-ietf-isms-secshell-12 (work in progress), 535 October 2008. 537 [I-D.ietf-isms-tmsm] 538 Harrington, D. and J. Schoenwaelder, "Transport Subsystem 539 for the Simple Network Management Protocol (SNMP)", 540 draft-ietf-isms-tmsm-13 (work in progress), August 2008. 542 [I-D.ietf-isms-transport-security-model] 543 Harrington, D. and W. Hardaker, "Transport Security Model 544 for SNMP", draft-ietf-isms-transport-security-model-09 545 (work in progress), October 2008. 547 [I-D.ietf-radext-management-authorization] 548 Nelson, D. and G. Weber, "Remote Authentication Dial-In 549 User Service (RADIUS) Authorization for Network Access 550 Server (NAS) Management", 551 draft-ietf-radext-management-authorization-06 (work in 552 progress), October 2008. 554 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 555 Requirement Levels", BCP 14, RFC 2119, March 1997. 557 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 558 "Remote Authentication Dial In User Service (RADIUS)", 559 RFC 2865, June 2000. 561 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 562 Authentication Protocol", RFC 4252, January 2006. 564 7.2. Informative References 566 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 567 Implementation in Roaming", RFC 2607, June 1999. 569 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 570 Architecture for Describing Simple Network Management 571 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 572 December 2002. 574 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 575 Access Control Model (VACM) for the Simple Network 576 Management Protocol (SNMP)", STD 62, RFC 3415, 577 December 2002. 579 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 580 Dial In User Service) Support For Extensible 581 Authentication Protocol (EAP)", RFC 3579, September 2003. 583 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 584 "IEEE 802.1X Remote Authentication Dial In User Service 585 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 587 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 588 Dial In User Service (RADIUS) Implementation Issues and 589 Suggested Fixes", RFC 5080, December 2007. 591 Authors' Addresses 593 Kaushik Narayan 594 Cisco Systems, Inc. 595 10 West Tasman Drive 596 San Jose, CA 95134 597 USA 599 Phone: +1.408.526.8168 600 Email: kaushik_narayan@yahoo.com 602 David Nelson 603 Elbrys Networks, Inc. 604 75 Rochester Ave, Unit #3, 605 Portsmouth, NH 03801 606 USA 608 Phone: +1.603.570.2636 609 Email: d.b.nelson@comcast.net 611 Full Copyright Statement 613 Copyright (C) The IETF Trust (2008). 615 This document is subject to the rights, licenses and restrictions 616 contained in BCP 78, and except as set forth therein, the authors 617 retain all their rights. 619 This document and the information contained herein are provided on an 620 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 621 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 622 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 623 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 624 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 625 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 627 Intellectual Property 629 The IETF takes no position regarding the validity or scope of any 630 Intellectual Property Rights or other rights that might be claimed to 631 pertain to the implementation or use of the technology described in 632 this document or the extent to which any license under such rights 633 might or might not be available; nor does it represent that it has 634 made any independent effort to identify any such rights. Information 635 on the procedures with respect to rights in RFC documents can be 636 found in BCP 78 and BCP 79. 638 Copies of IPR disclosures made to the IETF Secretariat and any 639 assurances of licenses to be made available, or the result of an 640 attempt made to obtain a general license or permission for the use of 641 such proprietary rights by implementers or users of this 642 specification can be obtained from the IETF on-line IPR repository at 643 http://www.ietf.org/ipr. 645 The IETF invites any interested party to bring to its attention any 646 copyrights, patents or patent applications, or other proprietary 647 rights that may cover technology that may be required to implement 648 this standard. Please address the information to the IETF at 649 ietf-ipr@ietf.org.