INTERNET-DRAFT Ken Hornstein <draft-hornstein-snmpv3-ksm-02.txt> NRL March 1, 2001 Wes Hardaker Expires: September 1, 2001 UC Davis A Kerberos Security Model for SNMPv3 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Distribution of this memo is unlimited. It is filed as <draft- hornstein-snmpv3-ksm-02.txt>, and expires on September 1, 2001. Please send comments to the authors. Abstract This document describes a proposed Kerberos Security Model (KSM) for SNMP version 3 for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for providing SNMP message level security with Kerberos [RFC1510]. Introduction and Rationale Kerberos [RFC1510] is a security system utilizing symmetric key cryp- tography. In Kerberos, all keys are stored on a central Key Distri- bution Center (KDC) and communication is required with the KDC as part of the authentication process. Hornstein, Hardaker [Page 1]
RFC DRAFT March 1, 2001 The tradeoffs between centralized and non-centralized services are well known. One of the design goals of SNMP is to rely on as few network services as possible, because these services may very well be unavailable at the very time you wish to use network management to repair the network. As a result, there has not been any significant work done in exploring centralized authentication systems with SNMP. However, the authors of this draft feel that centralized authentica- tion systems still have their place within the SNMP framework. In many environments there are multiple classes of users. Some users will only have the ability to monitor the network, where some (presumably smaller) group of users will have the ability to perform administrative tasks. It is our contention that in many cases, only the users that do administration will need authentication when network services are unavailable. For the larger class of users that only do monitoring, centralized authentication would be perfectly appropriate. Note that we recognize that this user service model may not be appropriate for all environments. Goals of this Security Model As specified in the SNMP Architecture RFC [RFC2271], there are threats that a security model must protect against. These include: Modification of Information The modification threat is the danger that some unauthorized SNMP entity may alter in-transit SNMP messages generated on behalf of an authorized principal in such a way as to effect unauthorized management operations, including falsifying the value of an object. Masquerade The masquerade threat is the danger that management operations not authorized for some principal may be attempted by assuming the identity of another principal that has the appropriate authoriza- tions. Message Stream Modification The SNMP protocol is typically based upon a connectionless tran- sport service which may operate over any subnetwork service. The re-ordering, delay or replay of messages can and does occur through the natural operation of many such subnetwork services. The message stream modification threat is the danger that messages may be maliciously re-ordered, delayed or replayed to an extent which is greater than can occur through the natural operation of a subnetwork service, in order to effect unauthorized management Hornstein, Hardaker [Page 2]
RFC DRAFT March 1, 2001 operations. Disclosure The disclosure threat is the danger of eavesdropping on the exchanges between SNMP engines. Protecting against this threat may be required as a matter of local policy. The Kerberos Security Model provides protection against all of these threats, as these features are already built into the Kerberos proto- col [RFC1510]. This Security Model provides no protection against Denial of Service or Traffic Analysis attacks. SNMP Messages Using this Security Model The syntax of an SNMP message using this Security Model adheres to the message format defined in the version-specific Message Processing Model document (for example [RFC2272]). The field msgSecurityParameters in SNMPv3 messages has a data type of OCTET STRING. Its value is the BER serialization of a KRB_AP_REQ messsage for Request messages and the BER serialization of a KRB_AP_REP message for Response messages. The formats of the KRB_AP_REQ and KRB_AP_REP messages are defined by the Kerberos 5 RFC [RFC1510]. The application specific checksum (referred to in section 3.2.2 of [RFC1510]) which is contained in the authenticator of the KRB_AP_REQ shall be computed using the BER serialization of the fields prior to the msgSecurityParameters field. Implementations MUST include this checksum for all Request messages. Generating an Outgoing SNMP Message This Section describes the procedure followed by an SNMP engine when- ever it generates a message containing a management operation (like a request, a response, a notification, or a report) on behalf of a user, with a particular securityLevel. 1) a) 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. Otherwise, Hornstein, Hardaker [Page 3]
RFC DRAFT March 1, 2001 b) 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 ser- vice have not already been cached. 2) The resulting BER serialized KRB_AP_REQ or KRB_AP_REP is placed into the securityParameters field. 3) a) 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. Otherwise, b) 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. 3) The resulting BER serialized KRB_PRIV or KRB_SAFE message is placed as the msgData field. 4) The completed message with its length is returned to the calling module with the statusInformation set to success. Processing an Incoming SNMP Message This section describes the procedure followed by an SNMP engine when- ever it receives a message containing a management operation on behalf of a user, with a particular securityLevel. 1) If the received securityParameters is not the serialization of a KRB_AP_REQ or KRB_AP_REP message, then the snmpInASNParseErrs counter [RFC1907] is incremented, and an error indication (par- seError) is returned to the calling module. 2) The KRB_AP_REQ/KRB_AP_REP (depending if this is a request or a response) is verified via the Kerberos protocol, and the client identity is extracted from the message. The client principal is converted into an ASCII string via the rules specified in RFC 1510 [RFC1510] and this is used as the securityName for this PDU. 3) a) If the securityLevel specified that this message was to be protected from disclosure, the msgData field will be ver- fied by Kerberos. If this field is not the BER serialization of a KRB_PRIV message, then the snmpInASNParseErrs counter Hornstein, Hardaker [Page 4]
RFC DRAFT March 1, 2001 [RFC1907] is incremented, and an error indication (parseError) is returned to the calling module. If the Kerberos verifica- tion fails, an error indication is returned. Otherwise, b) The msgData field will be verified by Kerberos. If this field is not the BER serialization of a KRB_SAFE message, then the snmpInASNParseErrs counter [RFC1907] is incremented, and an error indication (parseError) is returned to the calling module. If Kerberos verification fails, an error indication is returned. 4) If this message is a request, the session key and other Kerberos information needed for a response will be placed into the securi- tyStateReference field. 5) The statusInformation is set to success and a return is made to the calling module. Security considerations The security of this Security Model depends entirely on the security of Kerberos and the basic assumptions that it is built upon. Thus, the security considerations of the KSM are the same as the Kerberos protocol itself. Authors' Note The authors of this Internet-Draft acknowledge that the outline and a large amount of the text of this draft comes from the USM RFC [RFC2274]. Expiration This Internet-Draft expires on September 1, 2001. References [RFC1510] The Kerberos Network Authentication System; Kohl, Newman; Sep- tember 1993. [RFC1907] Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2); Case, McCloghrie, Rose, Wald- busser; January 1996. Hornstein, Hardaker [Page 5]
RFC DRAFT March 1, 2001 [RFC2271] An Architecture for Describing SNMP Management Frameworks; Har- rington, Presuhn, Wijnen; January 1998. [RFC2272] Message Processing and Dispatching for the Simple Network Management Protocol (SNMP); Case, Harrington, Presuhn, Wijnen; January 1998. [RFC2274] User-based Security Model (USM) for version 3 of the Simple Net- work Management Protocol (SNMPv3); Blumenthal, Wijnen; January 1998. Authors' Addresses Ken Hornstein US Naval Research Laboratory Bldg A-49, Room 2 4555 Overlook Avenue Washington DC 20375 USA Phone: +1 (202) 404-4765 EMail: kenh@cmf.nrl.navy.mil Wes Hardkar IT-DCAS University of California, Davis Davis CA 95616 USA Phone: +1 (530) 754-7571 EMail: wjhardaker@ucdavis.edu Hornstein, Hardaker [Page 6]