isms R. Pejaver Internet-Draft Y. Lee Intended status: Standards Track Comcast Expires: January 27, 2011 July 26, 2010 Keroberos Security Model for SNMPv3 draft-pejaver-ismi-kerberos-00 Abstract This memo describes the use of Kerberos [RFC4120] service with Simple Network Management Protocol (SNMP) to authenticate users, authorize them to access specific MIB objects and to encrypt data for confidentiality. User authorization information is securely encapsulated inside the AuthorizationData field in a Kerberos ticket. The recommendations of this memo may be eventually extended to applications other than SNMP. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 27, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Pejaver & Lee Expires January 27, 2011 [Page 1] Internet-Draft Keroberos Security Model for SNMPv3 July 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Security Model Objectives . . . . . . . . . . . . . . . . 3 2.3. Kerberos Service Operational Model . . . . . . . . . . . . 4 2.4. System Block Diagram . . . . . . . . . . . . . . . . . . . 5 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. PAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. SNMP Requests . . . . . . . . . . . . . . . . . . . . . . 6 3.4. SNMP Responses . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Integrating RADIUS & Two factor authentication . . . . . . 8 4. Comparative Analysis . . . . . . . . . . . . . . . . . . . . . 8 4.1. Advantages of this Security Model . . . . . . . . . . . . 8 4.2. Disadvantages of this Security Model . . . . . . . . . . . 8 4.3. Issues with security models based on transport sessions . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Pejaver & Lee Expires January 27, 2011 [Page 2] Internet-Draft Keroberos Security Model for SNMPv3 July 2010 1. 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 RFC 2119 [RFC2119]. 2. Introduction 2.1. General This memo defines a Kerberos [RFC4120] based security model that supports centralized administration of user authentication and authorization, and data confidentiality via encryption for SNMPv3. SNMPv3 allows the definition of new security models. The first security models [I-D.ietf-isms-radius-vacm] defined, USM and VACM, did not support centralized security administration. Recent work based on session based approaches are not suitable for large networks containing untrusted managed devices. A Kerberos based model was proposed earlier but did not go beyond the internet draft stage. This memo builds on the earlier proposal [draft-hornstein-snmpv3-ksm] and adds support for centralized authorization. Kerberos is a "trusted third party" security system. It uses symmetric key cryptography (as opposed to PKI) and is simple enough to be implemented on small managed devices. Once deployed in an enterprise network, it can provide a security foundation for many different applications. However, deploying Kerberos in a large network is a significant undertaking and hence the model proposed herein may not be suitable for all organizations. This memo addresses security for SNMP GETs and SETs. SNMP TRAPs can be secured in a similar way but are considered out of scope of this memo. Lastly, this memo does not address details of the Kerberos server and the Authorization Database. 2.2. Security Model Objectives The SNMP Architecture [RFC3411] lists the following well understood requirements: o Modification of Information o Masquerade o Message Stream Modification Pejaver & Lee Expires January 27, 2011 [Page 3] Internet-Draft Keroberos Security Model for SNMPv3 July 2010 o Disclosure The above requirements can be restated as the need for user authentication, message encryption and message integrity protection. In addition, there often are the following operational requirements: o Granular Authorization: Some administrators may be authorized to modify MIB values, while others may be limited to only viewing them. Further, some administrators may modify sensitive MIB values, while others may not. Administrators' privileges may be reflected by the roles assigned to them, or by other authorization models such as permissions bits, privilege levels, etc. o Centralized security administration: User credentials for both authentication and authorization need to be administered from a central point. o Efficiency: Low end managed devices often have constraints such as, inability to save state between SNMP commands, and the lack of computational capability that is required to support PKI based protocols. Also, SNMP messages are optimally exchanged using UDP as the transport. 2.3. Kerberos Service Operational Model Kerberos uses the concept of shared secrets to allow principals to securely communicate with each other. Principals may be human users (administrators) or hosts (managed devices.) Each principal shares a secret key with the Kerberos server. For human users, the key is derived from a password that is entered by the user. For hosts, the key has to be securely stored on the host so that it cannot be copied or modified by potential attackers. The key must be installed on each managed device. The managed device must be "Kerberized" and contains software that implements the Kerberos protocol and decrypts Kerberos tickets. The workstation that runs the Network Management Application must be Kerberized to support Kerberos login and to save TGTs. The Network Management Application itself must be Kerberized to get service tickets for each managed device before it sends a SNMP request. Kerberizing hosts and applications mostly involves inserting calls to the Kerberos library into existing code. The Network Management Application requests a service ticket from the Kerberos server by sending it a TGS_REQ. It gets a TGS_REP in response. It then constructs and sends the managed device an AP_REQ and gets back a AP_REP in response. Pejaver & Lee Expires January 27, 2011 [Page 4] Internet-Draft Keroberos Security Model for SNMPv3 July 2010 2.4. System Block Diagram +--------+ | Authz | | DB | +--------+ | | +--------+ +...............................|Kerberos|....+ . +--------------------------|Server | . . | +--------+ . . Kerberos . . Ticket Shared . Request Kerberos . | Secret . | . +-------------+ +-----------------+ | Network | | | | Management | SNMP | Managed | | Application |------------------| Network Device | +-------------+ UDP +-----------------+ Figure 1 Figure 1 depicts the relationship between the major components of the proposed solution. The dashed lines indicate message exchanges while dotted lines indicate a shared secret. The administrator on a workstation should first login to the Kerberos server and obtain a TGT. The TGT is cached on the workstation. Subsequently, the Network Management Application uses the TGT to obtain service tickets for each Managed Network Device that it accesses. It sends SNMPv3 requests over UDP to the Managed Device. The Managed Device uses its Kerberos secret to decrypt the ticket and extract information from it to securely complete the request. The Authorization Database contains a mapping of acess privileges for each device for each user and is accessed securely by the Kerberos server. 3. Proposal 3.1. Outline The proposal is virtually identical to that made earlier in [draft-hornstein-snmpv3-ksm]. In the SNMPv3 packet header, the Pejaver & Lee Expires January 27, 2011 [Page 5] Internet-Draft Keroberos Security Model for SNMPv3 July 2010 msgSecurityModel field will contain a new value indicating the use of the Kerberos Security Model. The SNMPv3 msgSecurityParameters field will contain Kerberos AP_REQ in a SNMP request and will contain Kerberos AP_REP in a SNMP response. 3.2. PAC The Kerberos ticket in the AP_REQ is expected to contain user authorization information, referred to here as a PAC (Privilege Attribute Certificate.) The PAC is inserted into the encrypted ticket by the Kerberos server and cannot be modified by others. It is an indication of the privileges assigned to the requesting user. A PAC will be the permissions for the specific user on the identified device. Its structure and semantics may vary depending on the authorization model of the managed device. Examples are: o Privilege bits: { Read, Read-Sensitive, Write, Write-Sensitive, Reboot, ... } o Privilege level: { 0 .. 7 } o Role: { enum Admin, BackupOperator, OperationsManager, Auditor } o Combination: Bits & Role A PAC can also define encryption requirements (encrypt payload or not) and whether "reverse authentication" and "reverse encryption" is required, though the securityLevel field may be preferred. The method used by the Kerberos Server to include the PAC is outside the scope of this note. 3.3. SNMP Requests The Network Management Application will use the Kerberos library functions and previously obtained TGT to construct a AP_REQ. This PDU is BER serialized and copied into the SNMPv3 securityParameters field. As described earlier in [draft-hornstein-snmpv3-ksm]: 1. If any securityStateReference is passed (Response message), then information concerning the state of the Kerberos protocol is extracted from the cachedSecurityData. This typically includes a session key and client principal name. This data is used to construct an appropriate KRB_AP_REP message. Pejaver & Lee Expires January 27, 2011 [Page 6] Internet-Draft Keroberos Security Model for SNMPv3 July 2010 2. Otherwise, the current Kerberos credentials available to the client, the Kerberos service name of "host", and the Kerberos localization information (which consist of a DNS domain name and optionally an IP address when using the IP suite) of the destination SNMP engine are used to construct an KRB_AP_REQ message. This may involve contacting a Kerberos KDC if credentials for this service have not already been cached. 3. The resulting BER serialized KRB_AP_REQ or KRB_AP_REP is placed into the securityParameters field. 4. If the securityLevel specificies that the message is to be protected from disclosure, then the SNMP payload (the scopedPDU) is used as the payload of a KRB_PRIV message. 5. Otherwise, If the securityLevel just specifies that the message is to be authenticated, the SNMP payload (the scopedPDU) is used as the payload of a KRB_SAFE message. 6. The resulting BER serialized KRB_PRIV or KRB_SAFE message is placed as the msgData field. 7. The completed message with its length is returned to the calling module with the statusInformation set to success. 3.4. SNMP Responses The Managed Device will use the Kerberos library functions and its stored secret to decrypt the AP_REQ message and extract the following values: o Principal name of requestor: This value is the securityName and may be used for log messages. o Session Encryption Key: Which is used by the library functions to decrypt the SNMP payload. o PAC: which is used in the authorization decision. VACM may be used as described in [I-D.ietf-isms-radius-vacm] The Session Encryption Key will be used if the response payload is to be encrypted. Lastly, if Reverse Authentication is requested, then the managed Device constructs a AP_REP PDU and inserts it into the securityParameters field. Pejaver & Lee Expires January 27, 2011 [Page 7] Internet-Draft Keroberos Security Model for SNMPv3 July 2010 3.5. Integrating RADIUS & Two factor authentication Ideally, RADIUS and Two factor authentication should be invoked only once when the administrator is "logging in". These services should not be invoked each time a different managed device is selected. If RADIUS is the source of authorization information, then this information should be cached somewhere. Alternatively, it can be inserted into the AuthorizationData field in the TGT. Thereafter, this data can be copied from the TGT into each service ticket. 4. Comparative Analysis 4.1. Advantages of this Security Model o Small Number of UDP Packet Exchanges. o Managed Device can make an authorization decision without communicating with any other service. o Managed Device does not need to retain any state information between SNMP requests. o Compatible with VACM 4.2. Disadvantages of this Security Model o Does not support token based two factor authentication. Kerberos does not currently support this capability. 4.3. Issues with security models based on transport sessions One of the approaches to SNMP security is to set up a secure "transport" connection using SSH between the Management Application and the Managed Device. Some of the issues with this approach are: 1. Setup overhead for ssh (and TLS) precludes short SNMP exchanges (like status polls.) 2. User authentication hits the RADIUS server for each device accessed. Ideally, RADIUS should be invoked only once during user "login". 3. Every Managed Device needs to be configured as a RADIUS client. 4. Every Managed Device needs to be trusted since it sees user passwords. It would be tempting for a hacker to spoof a Managed Device and steal the administrators' passwords. Pejaver & Lee Expires January 27, 2011 [Page 8] Internet-Draft Keroberos Security Model for SNMPv3 July 2010 5. Managed Device code is more complicated. It has to retain much more state. 6. SSH (or TLS) uses public key cryptography during session setup, which is somewhat compute intensive. 5. IANA Considerations The following IDs should be allocated: 1. SNMPv3 SecurityModel ID for Kerberos Security Model 2. Kerberos AuthorizationData type ID indicating that the content is a PAC. 3. Kerberos PreAuthentication data type indicating that the content is a PAC request. 6. Security Considerations This model depends on Kerberos and inherits its security attributes. Major considerations are: 1. The secret keys stored on managed devices are often hard to protect and manage. This is especially true when the devices are physically located in untrusted zones. However, an attacker that copies the secret key is limited to impersonating the device and cannot affect other devices in the network. 2. The model depends on the Kerberos server being available online to generate service tickets. If the server becomes unavailable then SNMP operations will be affected. However, the Kerberos server can be replicated, and service tickets that have already been issued will continue to work until they expire. 7. Acknowledgements The author would like to acknowledge the previous internet draft [draft-hornstein-snmpv3-ksm]. A section of text has been copied verbatim from that document. 8. References Pejaver & Lee Expires January 27, 2011 [Page 9] Internet-Draft Keroberos Security Model for SNMPv3 July 2010 8.1. Normative References [I-D.ietf-isms-radius-vacm] Narayan, K., Nelson, D., and R. Presuhn, "Using Authentication, Authorization, and Accounting services to Dynamically Provision View-based Access Control Model User-to-Group Mappings", draft-ietf-isms-radius-vacm-08 (work in progress), July 2010. [I-D.ietf-isms-transport-security-model] Harrington, D. and W. Hardaker, "Transport Security Model for SNMP", draft-ietf-isms-transport-security-model-14 (work in progress), May 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. 8.2. Informative References [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. Authors' Addresses Rajaram Pejaver Comcast One Comcast Center Philadelphia 19103 U.S.A. Email: rajaram_pejaver@cable.comcast.com URI: http://www.comcast.com Pejaver & Lee Expires January 27, 2011 [Page 10] Internet-Draft Keroberos Security Model for SNMPv3 July 2010 Yiu L. Lee Comcast One Comcast Center Philadelphia 19103 U.S.A. Email: yiu_lee@cable.comcast.com URI: http://www.comcast.com Pejaver & Lee Expires January 27, 2011 [Page 11]