[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
INTERNET-DRAFT                                             Ken Hornstein
<draft-hornstein-snmpv3-ksm-01.txt>                                  NRL
June 12, 2000                                               Wes Hardaker
Expires: December 12, 2000                                      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-01.txt>, and expires on December 12, 2000.
   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                                                  June 12, 2000


   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                                                  June 12, 2000


      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                                                  June 12, 2000


       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                                                  June 12, 2000


          [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 December 12, 2000.

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                                                  June 12, 2000


   [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]