Internet DRAFT - draft-ietf-snmpv3-ksm
draft-ietf-snmpv3-ksm
INTERNET-DRAFT Ken Hornstein
<draft-ietf-snmpv3-ksm-00.txt> NRL
June 25, 1999 Wes Hardaker
Expires: December 25, 1999 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-ietf-
snmpv3-ksm-00.txt>, and expires on December 21, 1999. 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 25, 1999
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 25, 1999
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].
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,
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
Hornstein, Hardaker [Page 3]
RFC DRAFT June 25, 1999
service 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
[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,
Hornstein, Hardaker [Page 4]
RFC DRAFT June 25, 1999
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 25, 1999.
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.
[RFC2271]
An Architecture for Describing SNMP Management Frameworks; Har-
rington, Presuhn, Wijnen; January 1998.
[RFC2272]
Hornstein, Hardaker [Page 5]
RFC DRAFT June 25, 1999
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]
