idnits 2.17.1 draft-ietf-isms-radius-usage-06.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 (April 29, 2009) is 5469 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-tmsm-17 -- 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-13 -- 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 == Outdated reference: A later version (-18) exists of draft-ietf-isms-secshell-16 Summary: 1 error (**), 0 flaws (~~), 6 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: October 31, 2009 Elbrys Networks, Inc. 6 April 29, 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-06.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 October 31, 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. RADIUS Operational Model . . . . . . . . . . . . . . . . . 4 77 1.3. RADIUS Usage With Secure Transports . . . . . . . . . . . 5 78 1.4. SNMP Transport Models . . . . . . . . . . . . . . . . . . 6 79 2. RADIUS Usage for SNMP Transport Models . . . . . . . . . . . . 6 80 2.1. RADIUS Authentication for Transport Protocols . . . . . . 8 81 2.2. RADIUS Authorization for Transport Protocols . . . . . . . 8 82 2.3. SNMP Service Authorization . . . . . . . . . . . . . . . . 9 83 3. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 10 84 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 89 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 94 1.1. General 96 This memo describes the use of a Remote Authentication Dial-In User 97 Service (RADIUS) authentication and authorization service by Simple 98 Network Management Protocol (SNMP) secure Transport Models to 99 authenticate users and authorize creation of secure transport 100 sessions. While the recommendations of this memo are generally 101 applicable to a broad class of SNMP Transport Models, the examples 102 focus on the Secure Shell Transport Model. 104 In the context of this document, a Network Access Server (NAS) is a 105 network device or host that contains an SNMP engine implementation, 106 utilizing SNMP Transport Models. It is customary in SNMP documents 107 to indicate which subsystem performs specific processing tasks. In 108 this document we leave such decisions to the implementer, as is 109 customary for RADIUS documents, and simply specify NAS behavior. 110 Such processing would quite likely be implemented in the secure 111 transport module. 113 1.2. RADIUS Operational Model 115 The RADIUS protocol [RFC2865] provides authentication and 116 authorization services for network access devices, usually referred 117 to as a Network Access Server (NAS). The RADIUS protocol operates, 118 at the most simple level, as a request-response mechanism. RADIUS 119 Clients, within the NAS, initiate a transaction by sending a RADIUS 120 Access-Request message to a RADIUS Server, with which the client 121 shares credentials. The RADIUS Server will respond with either an 122 Access-Accept message or an Access-Reject message. 124 RADIUS supports authentication methods compatible with plaintext 125 username and password mechanisms, MD5 Challenge/Response mechanisms, 126 Extensible Authentication Protocol (EAP) mechanisms, and HTTP Digest 127 mechanisms. Upon presentation of identity and credentials the user 128 is either accepted or rejected. RADIUS servers indicate a successful 129 authentication by returning an Access-Accept message. An Access- 130 Reject message indicates unsuccessful authentication. 132 Access-Accept messages are populated with one or more service 133 provisioning attributes, that control the type and extent of service 134 provided to the user at the NAS. The authorization portion may be 135 thought of as service provisioning. Based on the configuration of 136 the user's account on the RADIUS Server, upon authentication the NAS 137 is provided with instructions as to what type of service to provide 138 to the user. When that service provisioning does not match the 139 capabilities of the NAS, or of the particular interface to the NAS 140 over which the user is requesting access, RFC 2865 [RFC2865] requires 141 that the NAS MUST reject the access request. RFC 2865 describes 142 service provisioning attributes for management access to a NAS, as 143 well as various terminal emulation and packet forwarding services on 144 the NAS. This memo describes specific RADIUS service provisioning 145 attributes that are useful for use with secure transports and SNMP 146 Transport Models. 148 RADIUS servers are often deployed on an enterprise-wide or 149 organization-wide basis, covering a variety of disparate use cases. 150 In such deployments, all NASes and all users are serviced by a common 151 pool of RADIUS servers. In many deployments, the RADIUS Server will 152 handle requests from many different types of NASes with different 153 capabilities, and different types of interfaces, services and 154 protocol support. 156 In order for a RADIUS server to make the correct authorization 157 decision in all cases, the server will often need to know something 158 about the type of NAS at which the user is requesting access, the 159 type of service that the user is requesting, and the role of the user 160 in the organization. For example, many users may be authorized to 161 receive network access via a Remote Access Server (RAS), Virtual 162 Private Network (VPN) server, or LAN access switch. Typically only a 163 small sub-set of all users are authorized to access the 164 administrative interfaces of network infrastructure devices, e.g. the 165 Command Line Interface (CLI) or SNMP engine of switches and routers. 167 In order for the RADIUS server to have information regarding the type 168 of access being requested, it is common for the NAS (i.e. the RADIUS 169 client) to include "hint" attributes in the RADIUS Access-Request 170 message, describing the NAS and the type of service being requested. 171 This document recommends appropriate "hint" attributes for the SNMP 172 service type. 174 1.3. RADIUS Usage With Secure Transports 176 Some secure transport protocols that can be used with SNMP Transport 177 Models have defined authentication protocols supporting several 178 authentication methods. For example, the Secure Shell (SSH) 179 Authentication protocol [RFC4252] supports multiple methods (Public 180 Key, Password, Host-Based) to authenticate SSH clients. 182 SSH Server integration with RADIUS traditionally uses the username 183 and password mechanism. 185 Secure transport protocols do not, however, specify how the transport 186 interfaces to authentication clients, leaving such as implementation 187 specific. For e.g., the "password" method of SSH authentication 188 primarily describes how passwords are acquired from the SSH client 189 and transported to the SSH server, the interpretation of the password 190 and validation against password databases is left to SSH server 191 implementations. SSH server implementations often use the Pluggable 192 Authentication Modules (PAM) 193 [http://www.opengroup.org/rfc/rfc86.0.html] interface provided by 194 operating systems such as Linux and Solaris to integrate with 195 password based network authentication mechanisms such as RADIUS, 196 TACACS+, Kerberos, etc. 198 Secure transports do not typically specify how to utilize 199 authorization information obtained from an AAA service, such as 200 RADIUS. More often, user authentication is sufficient to cause the 201 secure transport server to begin delivering service to the user. 202 Access control in these situations is supplied by the application to 203 which the secure transport server session is attached. For example, 204 if the application is a Linux shell, the user's access rights are 205 controlled by that user account's group membership and the file 206 system access protections. This behavior does not closely follow the 207 traditional service provisioning model of AAA systems, such as 208 RADIUS. 210 1.4. SNMP Transport Models 212 The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines a 213 mechanism for providing transport layer security for SNMP, allowing 214 protocols such as SSH and TLS to be used to secure SNMP 215 communication. The Transport Subsystem allows the modular definition 216 of Transport Models for multiple secure transport protocols. 217 Transport Models rely upon the underlying secure transport for user 218 authentication services. The Transport Model (TM) then maps the 219 authenticated identity to a model-independent principal, which it 220 stores in the tmStateReference. When the selected security model is 221 the Transport Security Model (TSM), the expected behavior is for the 222 securityName to be set by the TSM from the authenticated principal 223 information stored in the tmStateReference by the TM. 225 The Secure Shell protocol provides a secure transport channel with 226 support for channel authentication via local accounts and integration 227 with various external authentication and authorization services such 228 as RADIUS, Kerberos, etc. The Secure Shell Transport Model 229 [I-D.ietf-isms-secshell] defines the use of the Secure Shell protocol 230 as the basis for a Transport Model. 232 2. RADIUS Usage for SNMP Transport Models 234 There are two use cases for RADIUS support of management access via 235 SNMP. These are (a) service authorization and (b) access control 236 authorization. RADIUS almost always involves user authentication as 237 prerequisite to authorization, and there is a user authentication 238 phase for each of these two use cases. The first use case is 239 discussed in detail in this memo, while the second use case is a 240 topic of current research, and beyond the scope of this document. 241 This document describes the way in which RADIUS attributes and 242 messages are applied to the specific application area of SNMP 243 Transport Models. User authentication and service authorization via 244 RADIUS are undertaken by the secure transport module, that underlies 245 the SNMP Transport Model. 247 User authentication for SNMP Transport Models has the same syntax and 248 semantics as user authentication for any other network service. In 249 the context of SNMP the "user" is thought of as a "principal" and may 250 represent a host, an application or a human. 252 Service authorization allows a RADIUS server to authorize an 253 authenticated principal to use SNMP, optionally over a secure 254 transport, typically using an SNMP Transport Model. This memo 255 describes mechanisms by which such information can be requested from 256 a RADIUS server and enforced within the NAS. An SNMP architecture, 257 [RFC3411], does not make a distinction between user authentication 258 and service authorization. In the case of existing, deployed 259 security models, such as the User-based Security Model (USM), this 260 distinction is not significant. For SNMP Transport Models, this 261 distinction is relevant and important. 263 It is relevant because of the way in which SSH implementations have 264 traditionally integrated with RADIUS Clients. Those SSH 265 implementations traditionally seek to obtain user authentication 266 (e.g. validation of a username and password) from an outside 267 authentication service, often via a Pluggable Authentication Module 268 (PAM) style interface. The service authorization in traditional SSH 269 server implementations comes via the restrictions that the operating 270 system (OS) shell (and file system, etc.) place on the user by means 271 of access controls tied to the username or the username's membership 272 in various user groups. These OS-style access controls are distinct 273 from the service provisioning features of RADIUS. If we wish to use 274 existing SSH server implementations, or slightly adapt them, for use 275 with SNMP Transport Models, and we wish to support RADIUS-provisioned 276 service authorization, we need to be aware that the RADIUS service 277 authorization information will need to be obtained by the relevant 278 SNMP models from the SSH module. 280 One reason that RADIUS-provisioned service authorization is important 281 is that in many deployments the RADIUS server's back-end 282 authentication database contains credentials for many classes of 283 users, only a small portion of which may be authorized to access the 284 management interfaces of managed entities (NASes) via SNMP. This is 285 in contrast to the way USM for SNMP works, in which all principals 286 entered to the local configuration data-store are authorized for 287 access to the managed entity. In the absence of RADIUS-provisioned 288 service authorization, network management access may be granted to 289 unauthorized, but properly authenticated, users. With SNMPv3, an 290 appropriately configured Access Control Model would serve to 291 alleviate the risk of unauthorized access. 293 2.1. RADIUS Authentication for Transport Protocols 295 This document will rely on implementation specific integration of the 296 transport protocols with RADIUS clients for user authentication. 298 It is RECOMMENDED that the integration of RADIUS clients with 299 transport protocols utilize appropriate "hint" attributes in RADIUS 300 Access-Request messages, to signal to the RADIUS server the type of 301 service being requested over the transport session. Specific 302 attributes for use with SNMP Transport Models are recommended in this 303 document. 305 RADIUS servers, compliant to this specification, MAY use RADIUS hint 306 attributes, as described herein, to inform the decision whether to 307 accept or reject the authentication request. 309 2.2. RADIUS Authorization for Transport Protocols 311 In compliance with RFC 2865, NASes MUST enforce implicitly mandatory 312 attributes, such as Service-Type, within an Access-Accept message. 313 NASes MUST treat Access-Accept Messages that attempt to provision 314 unsupported services as if they were an Access-Reject. NASes SHOULD 315 treat unknown attributes as if they were provisioning unsupported 316 services. See [RFC5080] for additional details. 318 A NAS that is compliant to this specification, MUST treat any RADIUS 319 Access-Accept message that provisions a level of transport protection 320 (e.g. SSH) that cannot be provided, and/or application service (e.g. 321 SNMP) that cannot be provided over that transport, as if an Access- 322 Reject message had been received instead. The RADIUS Service-Type 323 Attribute is the primary indicator of the service being provisioned, 324 although other attributes may also convey service provisioning 325 information. 327 For traditional SSH usage, RADIUS servers typically provision 328 management access service, as SSH is often used to access the command 329 line shell of a host system, e.g. the NAS. RFC 2865 defines two 330 types of management access service attributes, one for privileged 331 access to the Command Line Interface (CLI) of the NAS and one for 332 non-privileged CLI access. These traditional management access 333 services are not used with SNMP. 334 [I-D.ietf-radext-management-authorization] describes further RADIUS 335 service provisioning attributes for management access to the NAS, 336 including SNMP access. 338 2.3. SNMP Service Authorization 340 The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines the 341 notion of a session, although the specifics of how sessions are 342 managed is left to Transport Models. The Transport Subsystem defines 343 some basic requirements for transport protocols around creation and 344 deletion of sessions. This memo specifies additional requirements 345 for transport protocols during session creation, and for session 346 termination. 348 RADIUS servers compliant to this specification SHOULD use RADIUS 349 service provisioning attributes, as described herein, to specify SNMP 350 access over a secure transport. Such RADIUS servers MAY use RADIUS 351 hint attributes included in the Access-Request message, as described 352 herein, in determining what, if any, service to provision. 354 NASes compliant to this specification MUST use RADIUS service 355 provisioning attributes, as described in this section, when they are 356 present in a RADIUS Access-Accept message, to determine whether the 357 session can be created and MUST enforce the service provisioning 358 decisions of the RADIUS server. 360 The following RADIUS attributes SHOULD be used, as hint attributes 361 included in the Access-Request message to signal use of SNMP over a 362 secure transport (i.e. authPriv) to the RADIUS server: 364 1. Service-Type with a value of Framed-Management. 365 2. Framed-Management-Protocol with a value of SNMP. 366 3. Management-Transport-Protection with a value of Integrity- 367 Confidentiality-Protection. 369 The following RADIUS attributes are used in an Access-Accept message 370 to provision SNMP over a secure transport which provides both 371 integrity and confidentiality (i.e. authPriv): 373 1. Service-Type with a value of Framed-Management. 374 2. Framed-Management-Protocol with a value of SNMP. 375 3. Management-Transport-Protection with a value of Integrity- 376 Confidentiality-Protection. 378 The following RADIUS attributes MAY be optionally used, to authorize 379 use of SNMP without protection (i.e. authNoPriv): 381 1. Service-Type with a value of Framed-Management. 382 2. Framed-Management-Protocol with a value of SNMP. 383 3. Management-Transport-Protection with a value of No-Protection. 385 There are no combinations of RADIUS attributes that denote the 386 equivalent of SNMP noAuthNoPriv access, as RADIUS always involves the 387 authentication of a user (i.e. a principal) as a prerequisite for 388 authorization. RADIUS can be used to to provide an "Authorize-Only" 389 service, but only when the request contains a "cookie" from a 390 previous successful authentication with the same RADIUS server (i.e. 391 the RADIUS State Attribute). 393 The following RADIUS attributes are used to limit the extent of a 394 secure transport session carrying SNMP traffic, in conjunction with 395 an SNMP Transport Model: 397 1. Session-Timeout 398 2. Inactivity-Timeout. 400 Refer to [RFC2865] for a detailed description of these attributes. 401 The Session-Timeout Attribute indicates the maximum number of seconds 402 that a session may exist before it is unconditionally disconnected. 403 The Inactivity-Timeout Attribute indicates the maximum number of 404 seconds that a transport session may exist without any protocol 405 activity (messages sent or received) before the session is 406 disconnected. These timeouts are enforced by the NAS. 408 3. Table of Attributes 410 Table 1 provides a guide to which attributes may be found in which 411 kinds of packets, and in what quantity. 413 Access- 414 Request Accept Reject Challenge # Attribute 415 --------------------------------------------------------------------- 416 0-1 0 0 0 1 User-Name [RFC2865] 417 0-1 0 0 0 2 User-Password [RFC2865] 418 0-1 * 0 0 0 4 NAS-IP-Address [RFC2865] 419 0-1 * 0 0 0 95 NAS-IPv6-Address {RFC3162] 420 0-1 * 0 0 0 32 NAS-Identifier [RFC2865] 421 0-1 0-1 0 0 6 Service-Type [RFC2865] 422 0-1 0-1 0 0-1 24 State [RFC2865] 423 0 0-1 0 0 27 Session-Timeout [RFC2865] 424 0 0-1 0 0 28 Idle-Timeout [RFC2865] 425 0-1 0-1 0-1 0-1 80 Message-Authenticator [RFC3579] 426 0-1 0-1 0 0 TBA-2 Framed-Management-Protocol 427 [I-D.ietf-radext-management-authorization] 428 0-1 0-1 0 0 TBA-3 Management-Transport-Protection 429 [I-D.ietf-radext-management-authorization] 431 Table 1 433 Table 2 defines the meaning of the entries in Table 1. 435 0 This attribute MUST NOT be present in a packet. 436 0+ Zero or more instances of this attribute MAY be present in 437 a packet. 438 0-1 Zero or one instance of this attribute MAY be present in 439 a packet. 440 1 Exactly one instance of this attribute MUST be present in 441 a packet. 442 * Only one of these atribute options SHOULD be included. 444 Table 2 446 SSH integration with RADIUS traditionally uses usernames and 447 passwords (with the User-Password Attribute), but other secure 448 transports could use other authentication mechanisms, and would 449 include RADIUS authentication attributes appropriate for that 450 mechanism instead of User-Password. 452 This document does not describe the usage of RADIUS Accounting, nor 453 Dynamic RADIUS Re-Authorization. Such RADIUS usages are not 454 currently envisioned for SNMP, and are beyond the scope of this 455 document. 457 4. IANA Considerations 459 This document makes no requests of IANA for new allocations, however 460 there are placeholder values ("TBA-n") in Section 3, that refer to 461 IANA assignments to be made in 462 [I-D.ietf-radext-management-authorization], which should be replaced 463 with actual values in this document, based on the corresponding IANA 464 assignments for [I-D.ietf-radext-management-authorization]. 466 5. Security Considerations 468 This specification describes the use of RADIUS for purposes of 469 authentication and authorization. Threats and security issues for 470 this application are described in [RFC3579] and [RFC3580]; security 471 issues encountered in roaming are described in [RFC2607]. 473 Additional security considerations for use of SNMP with secure 474 Transport Models [I-D.ietf-isms-tmsm] and the Transport Security 475 Model [I-D.ietf-isms-transport-security-model] are found in the 476 Security Considerations sections of the respective documents. 478 If the SNMPv1 or SNMPv2c Security Model is used, then securityname 479 comes from the community name, as per RFC3584. If the User-based 480 Security Model is selected, then securityName is determined using 481 USM. This may not be what is expected when using an SNMP secure 482 Transport Model with an external authentication service, such as 483 RADIUS. 485 Simultaneously using a secure transport with RADIUS authentication 486 and authorization, and the SNMPv1 or SNMPv2c or USM security models 487 is NOT RECOMMENDED. See the coexistence section of 488 [I-D.ietf-isms-tmsm]. 490 There are good reasons to provision USM access to supplement with 491 AAA-based access, however. When the network is under duress, or the 492 AAA-service is unreachable, for any reason, it is important to have 493 access credentials stored in the local configuration data-store of 494 the managed entity. USM credentials are a likely way to fulfill this 495 requirement. This is analogous to configuring a local "root" 496 password in the "/etc/passwd" file of a UNIX workstation, to be used 497 as a backup means of login, for times when the Network Information 498 Service (NIS) authentication service is unreachable. 500 The Message-Authenticator (80) attribute [RFC3579] SHOULD be used 501 with RADIUS messages that are described in this memo. 503 6. Acknowledgements 505 The authors would like to acknowledge the contributions of David 506 Harrington and Juergen Schoenwaelder for numerous helpful discussions 507 in this space, and Wes Hardaker for his thoughtful review comments. 509 7. References 511 7.1. Normative References 513 [I-D.ietf-isms-tmsm] 514 Harrington, D. and J. Schoenwaelder, "Transport Subsystem 515 for the Simple Network Management Protocol (SNMP)", 516 draft-ietf-isms-tmsm-17 (work in progress), April 2009. 518 [I-D.ietf-isms-transport-security-model] 519 Harrington, D. and W. Hardaker, "Transport Security Model 520 for SNMP", draft-ietf-isms-transport-security-model-13 521 (work in progress), April 2009. 523 [I-D.ietf-radext-management-authorization] 524 Nelson, D. and G. Weber, "Remote Authentication Dial-In 525 User Service (RADIUS) Authorization for Network Access 526 Server (NAS) Management", 527 draft-ietf-radext-management-authorization-06 (work in 528 progress), October 2008. 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, March 1997. 533 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 534 "Remote Authentication Dial In User Service (RADIUS)", 535 RFC 2865, June 2000. 537 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 538 Dial In User Service (RADIUS) Implementation Issues and 539 Suggested Fixes", RFC 5080, December 2007. 541 7.2. Informative References 543 [I-D.ietf-isms-secshell] 544 Harrington, D., Salowey, J., and W. Hardaker, "Secure 545 Shell Transport Model for SNMP", 546 draft-ietf-isms-secshell-16 (work in progress), 547 April 2009. 549 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 550 Implementation in Roaming", RFC 2607, June 1999. 552 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 553 Architecture for Describing Simple Network Management 554 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 555 December 2002. 557 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 558 Dial In User Service) Support For Extensible 559 Authentication Protocol (EAP)", RFC 3579, September 2003. 561 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, 562 "IEEE 802.1X Remote Authentication Dial In User Service 563 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 565 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 566 Authentication Protocol", RFC 4252, January 2006. 568 Authors' Addresses 570 Kaushik Narayan 571 Cisco Systems, Inc. 572 10 West Tasman Drive 573 San Jose, CA 95134 574 USA 576 Phone: +1.408.526.8168 577 Email: kaushik_narayan@yahoo.com 579 David Nelson 580 Elbrys Networks, Inc. 581 75 Rochester Ave, Unit #3, 582 Portsmouth, NH 03801 583 USA 585 Phone: +1.603.570.2636 586 Email: d.b.nelson@comcast.net