Network Working Group K. Narayan Internet-Draft Cisco Systems Inc. Expires: December 21, 2006 D. Nelson Enterasys Networks Inc. June 19, 2006 RADIUS Usage for SNMP SSH Security Model draft-narayan-isms-sshsm-radius-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Secure Shell Security Model (SSHSM) describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within a Transport Mapping. This memo describes the usage of the Secure Shell Security Model with a RADIUS authentication and authorization system. Requirements Language Narayan & Nelson Expires December 21, 2006 [Page 1] Internet-Draft RADIUS Usage for SNMP SSH Security Model June 2006 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3. RADIUS Integration Mechanism . . . . . . . . . . . . . . . . . 3 3.1. RADIUS Authentication . . . . . . . . . . . . . . . . . . 3 3.2. RADIUS Authorization . . . . . . . . . . . . . . . . . . . 4 3.2.1. SNMP Service Authorization . . . . . . . . . . . . . . 4 3.2.2. SNMP User Authorization . . . . . . . . . . . . . . . 5 3.2.3. RADIUS protocol operation . . . . . . . . . . . . . . 5 3.2.4. RADIUS Authorize-Only protocol operation . . . . . . . 6 3.3. RADIUS Authorize-Only Requirements . . . . . . . . . . . . 6 3.4. Attribute Interpretation . . . . . . . . . . . . . . . . . 7 4. SSHSM and RADIUS Binding . . . . . . . . . . . . . . . . . . . 7 4.1. Binding the authenticated Principal . . . . . . . . . . . 7 4.2. SNMP Service Authorization . . . . . . . . . . . . . . . . 7 4.3. SNMP User Authorization . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Narayan & Nelson Expires December 21, 2006 [Page 2] Internet-Draft RADIUS Usage for SNMP SSH Security Model June 2006 1. Introduction This memo describes the usage of the Secure Shell Security Model (SSHSM) with a RADIUS authentication system. Integration of SSHSM with RADIUS will enable the use of a RADIUS server infrastructure for SNMP authentication, which would provide centralized management of user accounts instead of managing accounts on every SNMP engine. The RADIUS server also allows for a common identity to be shared across several management protocols thereby removing the need for separate maintenance, and thereby reducing administrative overhead. 2. Problem Statement The Secure Shell Security Model [sshsm] describes a Security Model for SNMP using the Secure Shell protocol using a transport mapping [tmsm]. The Secure Shell protocol [RFC4251] provides a secure transport channel [RFC4253] with support for channel authentication [RFC4252] via local accounts and integration with various external authentication and authorization servers such as RADIUS, Kerberos, TACACS, etc. This document describes only RADIUS integration. SSHSM requires the SNMP protocol to continue to handle authorization of individual SNMP requests, this authorization can happen well after the SSH channel has been established and requires the SNMP engine to have knowledge of the SNMP securityName and any additional binding that is required for SNMP authorization. The RADIUS protocol [RFC2865]is a widely deployed means of authentication and authorization for network access and administrative access to network devices. The RADIUS protocol does not have explicitly separate requests for authentication and authorization and all authorization information is communicated during the authentication exchange. This limits implementation and deployment options for integration of SSHSM with the RADIUS protocol. This memo specifies a method for integration of SSHSM with the RADIUS protocol. 3. RADIUS Integration Mechanism 3.1. RADIUS Authentication The Secure Shell (SSH) Authentication protocol [sshsm] describes how SSH integrates with various types of authentication credentials and systems. This document describes how SSHSH will utilize RADIUS authentication, and optionally RADIUS authorization, provided through Narayan & Nelson Expires December 21, 2006 [Page 3] Internet-Draft RADIUS Usage for SNMP SSH Security Model June 2006 the SSH authentication process. Existing SSH implementations have been integrated with RADIUS Client implementations, and form the basis for the requirements of SSHSM to utilize existing, deployed authentication systems. RADIUS currently provides authentication methods compatible with username and password mechanisms, MD5 Challenge mechanisms, Extensible Authentication Protocol (EAP) mechanisms, and HTTP Digest mechanisms. SSH integration with RADIUS traditionally used the username and password mechanism. Sometimes this integration is via well known service APIs such as Pluggable Authentication Method (PAM). RADIUS will indicate a successful authentication by returning an Access-Accept message. An Access-Reject message indicates unsuccessful authentication. 3.2. RADIUS Authorization The RADIUS protocol [RFC2865] provides user authentication and authorization. The user authentication portion is pretty straightforward. Upon presentation of identity and credentials the user is either accepted or rejected. The authorization portion may be thought of as service provisioning. Based on the configuration of the user's account with the RADIUS Server, upon authentication the Network Access Server (NAS) is provided with instructions as to what type of service to provide to the user. When that service provisioning does not match the capabilities of the NAS, or of the particular interface to the NAS over which the user is requesting access, RFC 2865 [RFC2865] requires that the NAS MUST reject the access request. RADIUS Servers will usually populate Access-Accept messages with one or more service provisioning attributes. For a description of the basic set of attributes, refer to [RFC2865]. RFC 2865 describes service provisioning attributes for management access to a NAS, as well as various terminal emulation and packet forwarding services on the NAS. For SSH usage, RADIUS provisions management access service. RFC 2865 defines two types of management access service attributes, one for privileged access to the Command Line Interface (CLI) of the NAS and one for non-privileged CLI access. [radman] describes further RADIUS service provisioning attributes for management access to the NAS, including SNMP access. When SSHSM is used with RADIUS authorization, the SNMP-related attributes defined in this document SHOULD be used to provision SNMP access over SSH, using SSHSM. 3.2.1. SNMP Service Authorization The most common usage of SSH is to provide remote access to the operating system prompt (a shell environment). Access to the shell Narayan & Nelson Expires December 21, 2006 [Page 4] Internet-Draft RADIUS Usage for SNMP SSH Security Model June 2006 prompt is provided upon successful authentication. Authorization is implicitly provided by the access control mechanisms of NAS's operating system, e.g. permissions to invoke certain programs or access certain files. In order to utilize RADIUS authorization, and to provide for enforcement of authorization levels when connecting directly to an SNMP engine, via SSH, an explicit form of authorization is required. The following RADIUS attributes will be used to authorize SNMPv3 over SSH; 1. Service-Type with a value of Framed-Management. 2. Framed-Management-Protocol with a value of SNMPv3. Refer to [radman] for a detailed description of these attributes. From the perspective of SSHSM, these two attribute and vlaue pairs indicate that the SSH session is authorized to use SNMP over that session. It is a matter of implementation detail as to which component provides the authorization checking. 3.2.2. SNMP User Authorization One additional level of user authorization is useful in conjunction with SNMPv3, and in particular with SSHSM. The SNMP architectural model provides for a modular access control mechanism. One such mechanism is the View-Based Access Control Method (VACM). The User- Based Security Method (USM) integrates with VACM, by mapping the user identity as defined in USM to access rights within VACM. When using RADIUS authentication and authorization with SSHSM, it is possible to achieve a similar mapping of user identity to access rights. Rather than using a locally stored mapping table, as is the case with USM, SSHSM may take advantage of access rights information provisioned by RADIUS. Typically, this access rights information will be implemented at the RADIUS Server based on the group membership status of the user account. The RADIUS attribute that communicates the access rights group name is the Management-Policy-Id attribute. This attribute contains a printable string, which comprises a policy or group name of local scope to the NAS. The NAS will require a mapping of the group name to the specific access control method, e.g. VACM. This mapping will need to be provisioned in non-volatile store on each SNMP engine, however it is unlikely to change very often and is likely to be related to a broad category of access rights, e.g. read- only, read-write, security-manager, network-manager, etc. This mapping mechanism is implementation specific. 3.2.3. RADIUS protocol operation The RADIUS protocol operates, at the most simple level, as a request- response mechanism. RADIUS Clients, with the NAS, initiate a transaction by sending a RADIUS Access-Request message to a RADIUS Narayan & Nelson Expires December 21, 2006 [Page 5] Internet-Draft RADIUS Usage for SNMP SSH Security Model June 2006 Server, with which the client shares credentials. The RADIUS Server will respond with either an Access-Accept message of an Access-Reject message. In many deployments, the RADIUS Server will be handling request from many different types of NASes with different capabilities, and different types of interfaces, services and protocol support. In order to support a diverse environment, and to provision the appropriate set of services, it is helpful if the RADIUS Server knows something about the access request in addition to the user's identity and credentials. The RADIUS Client will often include attributes in the Access-Request message that indicate the nature of the service that the user is requesting, as a hint to the RADIUS Server. In the case of SSHSM, the RADIUS Client SHOULD include the following hint attributes in Access-Request messages: 1. Service-Type with a value of Framed-Management. 2. Framed-Management-Protocol with a value of SNMPv3. 3.2.4. RADIUS Authorize-Only protocol operation The RADIUS protocol inherently couples authentication with authorization. Authorization data, i.e. service provisioning attributes, are included in the Access-Accept message. Some other authentication and authorization protocols, such as TACACS, separate out the authorization phase from the authentication phase. Dynamic RADIUS [RFC3576] allows re-authorization of existing NAS sessions by means of a Change of Authorization (CoA) request. In this instance, a CoA sequence is initiated by a RADIUS Server. It may be possible to use CoA request with SSHSM. This is a topic for further study. When RADIUS is used to provide Authorize-Only types of provisioning, such as with RFC 3576, there is an expectation that the original authentication for the NAS session was provided by RADIUS, and in fact provided by the RADIUS Server that initiates the CoA request. RFC 2865 requires that any RADIUS Access-Request with a Service-Type of Authorize-Only contain the State attribute that was obtained from the RADIUS Server during the initial authentication. This State attribute serves as a form of "cookie" between the server and client. 3.3. RADIUS Authorize-Only Requirements The usage of RADIUS by SSHSM does not require that RADIUS be able to provide a separate authorization only phase, but it is different. One use case for separate authorization is where the initial SSH session authentication is provided by an authentication service, such as Kerberos, and subsequent session authorization is desired from RADIUS. The RADIUS protocol was not designed to act as an authorize- only service for use with other forms of authentication services. Narayan & Nelson Expires December 21, 2006 [Page 6] Internet-Draft RADIUS Usage for SNMP SSH Security Model June 2006 The current restriction that RADIUS CoA request be accompanied by a State attribute from the original RADIUS authentication effectively prohibit this mode of operation. This is a topic that requires additional study. 3.4. Attribute Interpretation If a NAS conforming to this specification receives an Access-Accept packet containing a Service-Type or Framed-Management-Protocol attribute which it cannot apply, it MUST act as though it had received an Access-Reject. [RFC3576] requires that a NAS receiving a Change of Authorization Request (CoA-Request) reply with a CoA-NAK if the Request contains an unsupported attribute. It is recommended that an Error-Cause attribute with value set to "Unsupported Attribute" (401) be included in the CoA-NAK. As noted in [RFC3576], authorization changes are atomic so that this situation does not result in session termination and the pre-existing configuration remains unchanged. As a result, no accounting messages should be generated. 4. SSHSM and RADIUS Binding 4.1. Binding the authenticated Principal The Secure Shell Protocol server [RFC4251]will invoke RADIUS authentication as part of "ssh-userauth" service. The SSH engine would retain the user name field of the SSH_MSG_USERAUTH_REQUEST message as part of the SSH environment after successful authentication. As part of processing Incoming messages the SSHSM will query the SSH engine to extract the username and map it an appropriate securityName. This mapping will available in the Local Configuration Database (LCD) and by default the securityName is set to the user name that was authenticated by SSH. 4.2. SNMP Service Authorization Service authorization for SNMP can be handled in two ways. Service Authorization can be handled by the SSH engine, the SSH engine must check whether the user has access to the SNMP service by verifying the values of the Service-Type and Framed-Management-Protocol attributes. In case the requested service is not available, the server should disconnect the session. The other alternative is for SSHSM to perform the service authorization, this will require the SSH engine to retain the Service-Type and Framed-Management-Protocol attributes returned by the RADIUS server in the SSH environment. As part of processing Narayan & Nelson Expires December 21, 2006 [Page 7] Internet-Draft RADIUS Usage for SNMP SSH Security Model June 2006 Incoming messages the SSHSM will query the SSH engine for the Service-Type and Framed-Management and authorize the SNMP service. This alternative is less efficient since the decision to the disconnect the session happens as part of processing the first incoming SNMP packet. This memo recommends the use of the SSH engine for service authorization. 4.3. SNMP User Authorization SNMPv3 provides granular user authorization via the View-Based Access Control Model (VACM), currently the securityName is used to bind the principal authenticated by the User Security Model (USM) to authorization provided by VACM. SSHSM can continue to rely on this model for user authorization but this model does present some management challenges when dealing with RADIUS. The use of RADIUS protocol is allow central management of users to prevent the proliferation of users to thousands of managed entities. Using the securityName as a binding for authorization would require these centrally managed users or binding between these users and the SNMP securityName to be defined on all SNMP engines, this undermines the purpose of a central RADIUS server. One alternative suggested by this memo is to use user groups managed by the RADIUS server to create binding the binding between SSHSM and VACM. This user group communicated in Management-Filter-ID can be mapped into a VACM groupName. The current VACM specification has the vacmSecurityToGroupTable, this table maps a combination of securityModel and securityName into a groupName which is used to define an access control policy for a group of principals. The SNMP engine can use an alternative mapping that relies on the Management- Filter-ID, this mapping can be implementation specific. The Management-Filter-ID for a particular securityName can be acquired during the SSH session establishment but it would need to be stored as part of the SSH environment which would require implementation specific extensions. The alternative is for SSHSM to use a RADIUS Authorize-Only request to acquire the Management-Filter-ID while processing the first incoming SNMP request. 5. IANA Considerations This document makes no request of IANA. Narayan & Nelson Expires December 21, 2006 [Page 8] Internet-Draft RADIUS Usage for SNMP SSH Security Model June 2006 Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations This specification describes the use of RADIUS for purposes of authentication and authorization. Threats and security issues for this application are described in [RFC3579] and [RFC3580]; security issues encountered in roaming are described in [RFC2607]. This document specifies a new attribute that can be included in existing RADIUS packets, which are protected as described in [RFC3579] and [RFC3576]. See those documents for a more detailed description. A Framed-Management-Protocol or Management-Policy-Id attribute sent by a RADIUS server may not be understood by the NAS which receives it. A legacy NAS not compliant with this specification may silently discard the Framed-Management-Protocol or Management-Policy-Id attributes while permitting the user to access the SNMP engine. This can lead to users improperly receiving management access to the NAS. 7. Acknowledgements 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. Narayan & Nelson Expires December 21, 2006 [Page 9] Internet-Draft RADIUS Usage for SNMP SSH Security Model June 2006 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [radman] Nelson, D. and G. Weber, "RADIUS NAS-Management Authorization", draft-nelson-radius-management-authorization-03.txt (work in progress), June 2006. [sshsm] Harrington, D. and J. Salowey, "Secure Shell Security Model for SNMP", draft-ietf-isms-secshell-03.txt (work in progress), May 2006. [tmsm] Harrington, D. and J. Schoenwaelder, "Transport Mapping Security Model (TMSM) Architectural Extension for the Simple Network Management Protocol (SNMP)", draft-ietf-isms-tmsm-02.txt (work in progress), May 2006. 8.2. Informative References [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. Narayan & Nelson Expires December 21, 2006 [Page 10] Internet-Draft RADIUS Usage for SNMP SSH Security Model June 2006 Authors' Addresses Kaushik Narayan Cisco Systems Inc. 10 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408-526-8168 Fax: Email: kaushik_narayan@yahoo.com David Nelson Enterasys Networks Inc. 50 Minuteman Road Andover, MA 01810-1008 USA Phone: +1 978-684-1330 Fax: Email: dnelson@enterasys.com Narayan & Nelson Expires December 21, 2006 [Page 11] Internet-Draft RADIUS Usage for SNMP SSH Security Model June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Narayan & Nelson Expires December 21, 2006 [Page 12]