Network Working Group K. Narayan Internet-Draft Cisco Systems, Inc. Intended status: Standards Track D. Nelson Expires: August 5, 2007 Independent contributor Feb 2007 RADIUS Usage for SNMP SSH Security Model draft-narayan-isms-sshsm-radius-01.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 August 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The Secure Shell Security Model (SSHSM) describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within an SNMP Transport Mapping. This memo describes the usage of the Secure Shell Security Model with a RADIUS authentication and authorization system. Narayan & Nelson Expires August 5, 2007 [Page 1] Internet-Draft RADIUS Usage for SNMP SSH Security Model Feb 2007 Requirements Language 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. SSH and RADIUS authentication . . . . . . . . . . . . . . 4 3.3. RADIUS Authorization . . . . . . . . . . . . . . . . . . . 4 3.3.1. SNMP Service Authorization . . . . . . . . . . . . . . 5 3.3.2. SNMP User Authorization . . . . . . . . . . . . . . . 5 3.3.3. RADIUS protocol operation . . . . . . . . . . . . . . 6 3.3.4. RADIUS Authorize-Only protocol operation . . . . . . . 6 3.4. RADIUS Authorize-Only Requirements . . . . . . . . . . . . 7 3.5. Attribute Interpretation . . . . . . . . . . . . . . . . . 7 3.6. SSH Integration with RADIUS . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Narayan & Nelson Expires August 5, 2007 [Page 2] Internet-Draft RADIUS Usage for SNMP SSH Security Model Feb 2007 1. Introduction This memo describes the usage of the Secure Shell Security Model (SSHSM) with a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization 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) [sshsm] describes a Security Model for SNMP using the Secure Shell protocol using a transport mapping [tmsm]. The Secure Shell protocol provides a secure transport channel with support for channel authentication [RFC4252] via local accounts and integration with various external authentication and authorization servers such as RADIUS, Kerberos, 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 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 RADIUS protocol provides authentication methods compatible with username and password mechanisms, MD5 Challenge mechanisms, Extensible Authentication Protocol (EAP) mechanisms, and HTTP Digest mechanisms. RADIUS will indicate a successful authentication by Narayan & Nelson Expires August 5, 2007 [Page 3] Internet-Draft RADIUS Usage for SNMP SSH Security Model Feb 2007 returning an Access-Accept message. An Access-Reject message indicates unsuccessful authentication. SSH integration with RADIUS traditionally used the username and password mechanism. 3.2. SSH and RADIUS authentication The Secure Shell (SSH) Authentication protocol [RFC4252] describes a generic authentication protocol and support multiple methods that can be used SSH servers to authenticate SSH clients, these methods include Public Key, Password and Host identity (hosts.equiv). The "password" method of SSH authentication primarily describes how passwords are acquired from the SSH client and transported to the SSH server, the interpretation of the password and validation against password databases is left to SSH server implementations. SSH server implementations typically use the Pluggable Authentication Mechanism [pam] interface provided by operating systems such as Linux and Solaris to integrate with password based network authentication mechanisms such as RADIUS, TACACS+, Kerberos, etc. This document describes how SSHSM will utilize RADIUS authentication, and optionally RADIUS authorization, provided through the SSH authentication process. This document will rely of implementation specific integration of SSH and RADIUS to achieve these goals. 3.3. 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 on the RADIUS Server, and upon service "hint" attributes included in the Access-Request message, an Access-Accept message will provide the Network Access Server (NAS) with instructions as to what type of service teh NAS is 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 user's 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 Narayan & Nelson Expires August 5, 2007 [Page 4] Internet-Draft RADIUS Usage for SNMP SSH Security Model Feb 2007 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.3.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 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.3.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 mechamism 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 Narayan & Nelson Expires August 5, 2007 [Page 5] Internet-Draft RADIUS Usage for SNMP SSH Security Model Feb 2007 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.3.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 Server, with which the client shares credentials. The RADIUS Server will respond with either an Access-Accept message or an Access-Reject message. In some caces, such as with EAP authentication methods, the RADIUS Server may respond with an Access-Challenge, in which case the RADIUS client will respond with another Access-Request. 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.3.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 Narayan & Nelson Expires August 5, 2007 [Page 6] Internet-Draft RADIUS Usage for SNMP SSH Security Model Feb 2007 obtained from the RADIUS Server during the initial authentication. This State attribute serves as a form of "cookie" between the server and client. 3.4. RADIUS Authorize-Only Requirements The usage of RADIUS by SSHSM does not require that RADIUS be able to provide a separate authorization only phase, however it would be desireable to be able to do so. 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. 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.5. 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 packets should be generated. 3.6. SSH Integration with RADIUS As mentioned in Section 3.2, the RADIUS client is often integrated with the SSH server using an intermediary such as Pluggable Authentiation Modules (PAM) [pam]. It may also be integrated directly, and any such intregation is a matter of implementaion. It is typical for host-based of the SSH server to use AAA services, such as RADIUS, simply for authentication. Any authorization is usually provided by the shell envirohment into which the remote user connects. For usage with SSHSM, there is no equivalent shell environment, and it may be useful for authorization data, e.g. RADIUS service provisioning attributes, to be utilized by the SSH server in making its decision to allow or deny an SSH connection. The RADIUS attributes of interest to SSHSM are described in Section 3.3.1 and Section 3.3.3. The ability of the SSH server to Narayan & Nelson Expires August 5, 2007 [Page 7] Internet-Draft RADIUS Usage for SNMP SSH Security Model Feb 2007 use this kind of authorization information in session establishment is a matter of implementaion. RADIUS clients export this type of information, and intermediate layers, such as PAM, provide mechanisms to pass these parameters through to the application that is using the AAA services, i.e. SSH. Section 3.3.2 talks about the option of using RADIUS authorization information in an SNMP access control model, such as View-based Access Control Model (VACM). This option is the topic of current study. The modular SNMP architecture encourages models to restrict information that is shared across an Application Service Interface (ASI) to that which is model-independent. The Transport Mapping Security Model (TMSM) does use a cache, known as the tmStateReference, to keep information that is required by the underlying transport layer. It is possible, therefore, for an implementation of an access control model to make use of the content of the tmStateReference, in an implementation-dependent fashion, to obtain authorization parameters, passed to the TMSM by the underlying transport layer, e.g. SSH, which may have been received from an AAA service, e.g. RADIUS. Whether that is a recommended and secure practice, remains open for discussion. Alternatively, the access control model could make use of AAA services directly, i.e. make calls to the RADIUS client, to obtain authorization information useful for access control. This is a second use case for an Authorize-Only operation in RADIUS. There are some practical limitations to that approach, however. The access control model identifies the principal requesting access by means of the securityName. When the access control information is configured in a local configuration store, as is the case with User-based Security Model (USM) and VACM, the access control model can look up the access rights in the local configuration store. If an access control model were to substitute a RADIUS authentication request transaction for the local lookup, it would need to take advantage of an Authorize-Only RADIUS operation, because the full authentication credentials are not available, just the securityName (User-Name). Currently, the RADIUS protocol prohibits the use of Authorize-Only operations unless they are tied to a previous, successful RADIUS authentication by means of a RADIUS State attribute. The only way an access control model would have accesss to the appropriate RADIUS State attribute would be for that information to be retreived from a session-related cache, such as the tmStateReference. Thus, we degenerate to the previous alternative. Additional study is required. Narayan & Nelson Expires August 5, 2007 [Page 8] Internet-Draft RADIUS Usage for SNMP SSH Security Model Feb 2007 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. 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 amy be 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. 6. Acknowledgements 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [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, Narayan & Nelson Expires August 5, 2007 [Page 9] Internet-Draft RADIUS Usage for SNMP SSH Security Model Feb 2007 July 2003. [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. [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [radman] Nelson, D. and G. Weber, "RADIUS NAS-Management Authorization", draft-nelson-radius-management-authorization-04.txt (work in progress), February 2007. [sshsm] Harrington, D. and J. Salowey, "Secure Shell Security Model for SNMP", draft-ietf-isms-secshell-05.txt (work in progress), October 2006. 7.2. Informative References [pam] Samar, V. and R. Schemers, "Unified Login With Pluggable Authentication Modules (PAM)", Open Software Foundation http://www.opengroup.org/tech/rfc/rfc86.0.html, October 1995. [tmsm] Harrington, D. and J. Schoenwaelder, "Transport Mapping Security Model (TMSM) Architectural Extension for the Simple Network Management Protocol (SNMP)", draft-ietf-isms-tmsm-06.txt (work in progress), May 2006. [tsms] Harrington, D., "Transport Security Model for SNMP", draft-ietf-isms-transport-security-model-03.txt (work in progress), February 2007. Narayan & Nelson Expires August 5, 2007 [Page 10] Internet-Draft RADIUS Usage for SNMP SSH Security Model Feb 2007 Authors' Addresses Kaushik Narayan Cisco Systems, Inc. 10 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408-526-8168 Email: kaushik_narayan@yahoo.com David Nelson Independent contributor 72 Old Chester Road Derry, NH 03038-4022 USA Phone: +1 606-432-2796 Email: d.b.nelson@comcast.net Narayan & Nelson Expires August 5, 2007 [Page 11] Internet-Draft RADIUS Usage for SNMP SSH Security Model Feb 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Narayan & Nelson Expires August 5, 2007 [Page 12]