isms R. Pejaver
Internet-Draft Y. Lee
Intended status: Standards Track Comcast
Expires: April 28, 2011 W. Hardaker
SPARTA, Inc.
K. Hornstein
US Naval Research Laboratory
October 25, 2010
Kerberos Security Model for SNMPv3
draft-pejaver-isms-kerberos-01
Abstract
This memo describes the use of Kerberos service with Simple Network
Management Protocol (SNMP) to authenticate users, authorize them to
access specific MIB objects, and to protect SNMP messages by using
integrity protection and encryption. User authorization information
is securely encapsulated inside the AuthorizationData field in a
Kerberos ticket.
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 April 28, 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
Pejaver, et al. Expires April 28, 2011 [Page 1]
Internet-Draft Kerberos Security Model for SNMPv3 October 2010
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
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. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Security Model Requirements . . . . . . . . . . . . . . . 4
2.4. Message Protection Requirements . . . . . . . . . . . . . 5
2.5. Kerberos Service Operational Model . . . . . . . . . . . . 5
2.6. User Authorization Information . . . . . . . . . . . . . . 6
3. Elements of the model . . . . . . . . . . . . . . . . . . . . 6
3.1. How KSM fits into the SNMP Architecture . . . . . . . . . 7
3.2. High Level Architecture . . . . . . . . . . . . . . . . . 9
3.3. Outline of the Proposal . . . . . . . . . . . . . . . . . 10
3.4. Services for generating an outgoing SNMP request . . . . . 10
3.5. Services for generating an outgoing SNMP response . . . . 11
3.6. Services for processing an incoming SNMP message . . . . . 12
4. Elements of the procedure . . . . . . . . . . . . . . . . . . 13
4.1. Procedure for outgoing requests . . . . . . . . . . . . . 13
4.2. Procedure for incoming requests . . . . . . . . . . . . . 14
4.3. Procedure for authorizing incoming requests . . . . . . . 15
4.4. Procedure for outgoing responses . . . . . . . . . . . . . 15
4.5. Procedure for incoming responses . . . . . . . . . . . . . 16
5. Unconfirmed messages . . . . . . . . . . . . . . . . . . . . . 16
6. Comparative Analysis . . . . . . . . . . . . . . . . . . . . . 16
6.1. Addressing the requirements . . . . . . . . . . . . . . . 16
6.2. Advantages of KSM . . . . . . . . . . . . . . . . . . . . 16
6.3. Disadvantages of this Security Model . . . . . . . . . . . 17
6.4. Issues with models based on transport sessions . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Implementation Details . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Pejaver, et al. Expires April 28, 2011 [Page 2]
Internet-Draft Kerberos Security Model for SNMPv3 October 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-based Security Model (KSM) that supports
centralized administration of user authentication and authorization
for SNMPv3 [RFC3411]. Encryption of the payload is optional, as is
Integrity protection for the whole SNMP message. Kerberos is defined
in [RFC4120].
SNMPv3 allows for the definition of new security models. The first
security models, USM [RFC3414]and VACM [RFC3415], do not support
centralized security administration. Kerberos is a widely-deployed
security infrastructure that provides centrally administered
authentication, authorization and message protection for large scale
networks. This model allows SNMP to leverage that infrastructure.
Kerberos is a "trusted third party" security system. It uses
symmetric key cryptography and is simple enough to be implemented on
small managed devices like modems and home routers.
This memo describes Kerberos related data structures and PDUs only at
a level necessary for an explanation of the model. It is assumed
that readers are already familiar with the SNMPv3 [RFC3411] and
Kerberos [RFC4120] protocols. Specific details for implementing KSM
are included in the Appendix A.
This memo addresses security for all SNMP operations and discusses
how a SNMP command responder can use the user authorization
information in RADIUS [RFC5608] servers to make authorization
decisions for requested SNMP operations.
2.2. Use Cases
The following are some of the less common use cases that serve as a
basis for generating requirements for this security model.
o The managed devices may not be trustable because of their physical
location in untrusted areas, like in customers' homes.
Specifically, they cannot be trusted with information that can be
used to access other managed devices, for example, the userids and
Pejaver, et al. Expires April 28, 2011 [Page 3]
Internet-Draft Kerberos Security Model for SNMPv3 October 2010
passwords of the administrators that manage these devices.s
o The managed devices may be low end devices like modems and
wireless routers in customers' homes. They may have limited CPU
and memory capabilities.
o Large numbers (millions) of managed devices may be polled for
status periodically and frequently by automated (unmanned) status
monitoring programs.
2.3. Security Model Requirements
The SNMP Architecture [RFC3411] lists the following well understood
requirements:
REQ1: Modification of Information: The modification threat is the
danger that an unauthorized 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.
REQ2: Masquerade: The masquerade threat is the danger that
management operations not authorized for some user may be
attempted by assuming the identity of another user that has
the appropriate authorizations.
REQ3: Message Stream Modification: The SNMP protocol is typically
based upon a connection-less transport service which may
operate over any sub-network service. The re-ordering, delay
or replay of messages can and does occur through the natural
operation of many such sub- network 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
sub-network service, in order to effect unauthorized
management operations.
REQ4: Disclosure: The disclosure threat is the danger of
eavesdropping on the exchanges between managed agents and a
management station. Protecting against this threat may be
required as a matter of local policy.
The above requirements can be restated as the need for user
authentication, message encryption, message integrity and message
replay protection over UDP.
In addition, many environments often require additional operational
constraints, such as:
Pejaver, et al. Expires April 28, 2011 [Page 4]
Internet-Draft Kerberos Security Model for SNMPv3 October 2010
REQ5: Centralized security administration: User credentials for both
authentication and authorization need to be administered from
a central point.
REQ6: Convenience: it must not be necessary to for an administrator
to reauthenticate to each and every device that is accessed,
unless subsequent access to a device requires stronger
authentication.
REQ7: Strong Authentication: Two factor authentication must be
supported for access to sensitive devices. However, the
administrator should not be required to reauthenticate for
each and every device that is accessed.
REQ8: Efficiency: The model should support low end managed devices
that 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.
Small devices optimally exchange messages using transports
such as UDP. The set up and tear down overheads for
connections between the SNMP command generators and command
responders should be minimal. The connections may be short-
lived and should not be required to be persistent.
2.4. Message Protection Requirements
The model should support the levels of security as described in the
SNMP Architecture:
o noAuthNoPriv - without authentication and without privacy. This
option will not protect either the SNMP message or header.
o authNoPriv - with authentication but without privacy. Both the
SNMP request and response will be authenticated. The entire
message (including the SNMP header) will be integrity protected.
o authPriv - with both authentication and privacy. Both the SNMP
request and response will be authenticated. The entire message
(including the SNMP header) will be integrity protected and the
scopedPDU will be further protected for confidentiality.
2.5. 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
(typically administrators) or hosts (both managing and managed
devices.) Each principal has a unique name and shares it's unique
secret key with the Kerberos server. For human users, the key is
Pejaver, et al. Expires April 28, 2011 [Page 5]
Internet-Draft Kerberos Security Model for SNMPv3 October 2010
derived from a password that is entered by the user during login.
For hosts, the secret key has to be generated during installation and
is securely stored on the host. Note that a SNMP Manager (a command
generator) may be an unattended daemon (e.g. an automated status
poller,) or an interactive program run by an administrator.
Before attempting any SNMP exchanges, the Manager should obtain a
Ticket Granting Ticket (TGT) from the Kerberos Key Distribution
Center (KDC). The descriptions below assume that this step has been
completed. The SNMP command generators use the TGT to obtain
Kerberos service tickets for each managed device that they
subsequently accesses.
Note that the command generator has to get the TGT only once before
accessing multiple command responders. There is a concept of "single
signon" inherent in this model. If the installation's policy
requires it, then two factor (token based) authentication for
administrators should be performed at this point. Any interactivity
required for resynchronizing tokens can be easily handled in this
situation. Kerberos must set a flag in the TGT indicating that the
required authentication was completed. This flag can be checked
before an SNMP request is performed.
2.6. User Authorization Information
The Kerberos ticket can contain user authorization information. This
information is inserted into the AuthorizationData field of 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.
For KSM, this value must contain the permissions for the specific
user on the identified device. Though the semantics of this value
can vary widely, for SNMP it is constrained to be a VACM groupName
that the user should be placed into. This value can also be a role,
privilege, or permission bits, without change in the syntax.
This information will be configured and maintained centrally in an
Authorization Database, and not on each individual managed device.
Each managed device must be aware of the privileges associated with
that groupName.
3. Elements of the model
Pejaver, et al. Expires April 28, 2011 [Page 6]
Internet-Draft Kerberos Security Model for SNMPv3 October 2010
3.1. How KSM fits into the SNMP Architecture
Figure 1 shows the positioning of the KSM Module in a SNMP command
responder. KSM is shown as a peer to the User-based Security Model
(USM). The positioning of the KSM Module in a SNMP command generator
is similar.
Pejaver, et al. Expires April 28, 2011 [Page 7]
Internet-Draft Kerberos Security Model for SNMPv3 October 2010
+------------------------------+
| Network |
+------------------------------+
^ ^ ^
| | |
v v v
+-------------------------------------------------------------------+
| +--------------------------------------------------+ |
| | Transport Subsystem | |
| | +-----+ +-----+ +-----+ +-----+ +-------+ | |
| | | UDP | | TCP | | SSH | | TLS | . . . | other | | |
| | +-----+ +-----+ +-----+ +-----+ +-------+ | |
| +--------------------------------------------------+ |
| ^ |
| | |
| Dispatcher v |
| +-------------------+ +---------------------+ +----------------+ |
| | Transport | | Message Processing | | Security | |
| | Dispatch | | Subsystem | | Subsystem | |
| | | | +------------+ | | +------------+ | |
| | | | +->| v1MP |<--->| | KSM | | |
| | | | | +------------+ | | +------------+ | |
| | | | | +------------+ | | +------------+ | |
| | | | +->| v2cMP |<--->| | USM | | |
| | Message | | | +------------+ | | +------------+ | |
| | Dispatch <--------->| +------------+ | | ... | |
| | | | +->| v3MP |<--->| ... | |
| | | | | +------------+ | | +------------+ | |
| | PDU Dispatch | | | +------------+ | | | Other | | |
| +-------------------+ | +->| otherMP |<--->| | Model(s) | | |
| ^ | +------------+ | | +------------+ | |
| | +---------------------+ +----------------+ |
| v |
| +-------+-------------------------+---------------+ |
| ^ ^ ^ |
| | | | |
| v v v |
| +-------------+ +---------+ +--------------+ +-------------+ |
| | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | |
| | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | |
| | Application | | | | Applications | | Application | |
| +-------------+ +---------+ +--------------+ +-------------+ |
| ^ ^ |
| | | |
| v v |
| +----------------------------------------------+ |
| | MIB instrumentation | SNMP entity |
+-------------------------------------------------------------------+
Pejaver, et al. Expires April 28, 2011 [Page 8]
Internet-Draft Kerberos Security Model for SNMPv3 October 2010
Figure 1: SNMP Command Responder Architecture
In Figure 1, a SNMPv3 message may reach the SNMP command responder
using any supported transport. For example, UDP is an expected
common transport to be used with KSM. The Message Dispatcher
forwards the message to the Message Processing Subsystem. If the
msgSecurityModel specifies KSM, then the message is forwarded to the
KSM module.
3.2. High Level Architecture
Figure 2 depicts the relationship between the major components of the
proposed solution. The dashed lines indicate message exchanges while
dotted lines indicate a shared secret.
+--------+
| Authz |
| DB |
+--------+
|
|
+--------+
+...............................|Kerberos|....+
. +--------------------------|Server | .
. | +--------+ .
. Kerberos .
. Ticket Shared
. Request Kerberos
. | Secret
. | .
+-------------+ +-----------------+
| Network | | |
| Management | SNMP | Managed |
| Application |------------------| Network Device |
+-------------+ UDP +-----------------+
Figure 2: High-level Architecture
The Authorization Database is a centralized repository that contains
a mapping of access privileges for each user to each device. It is
accessed securely by the Kerberos server. Note that details of the
Kerberos Server and the Authorization Database are out of scope of
this document.
The following sequence summarizes most SNMP request and response
exchanges. They are detailed in subsequent sections.
Pejaver, et al. Expires April 28, 2011 [Page 9]
Internet-Draft Kerberos Security Model for SNMPv3 October 2010
1. The SNMP command generator first obtains a service ticket for the
specific command responder from the KDC. The Kerberos server may
look up the authorization information for the requestor to the
managed device by checking the authorization database. This
information may be inserted into the service ticket, which is
returned to the requestor.
2. The SNMP command generator sends a SNMPv3 request to the SNMP
command responder. This request contains a Kerberos AP_REQ in
the SNMPv3 securityParameters field.
3. When the SNMP command responder receives the SNMPv3 request, it
must check the Session Key and the Lifetime of the ticket
contained inside the AP_REQ. If the ticket has expired, the SNMP
command responder must reject the SNMPv3 request.
4. The SNMP command responder responds with a SNMPv3 reply. This
reply must contain a Kerberos AP_REP in the SNMPv3
securityParameters field.
5. The SNMP command generator receives the reply and must validate
the Kerberos AP_REP.
Subsequent SNMP requests sent from the SNMP command generator to the
same SNMP command responder can reuse the ticket obtained in step 1.
A fresh AP_REQ will be constructed using the previously obtained
information.
3.3. Outline of the Proposal
The msgSecurityModel field in the SNMPv3 packet header must contain a
new value indicating the use of the Kerberos Security Model. The
SNMPv3 securityLevel field must contain a value indicating whether or
not authentication and privacy are being requested. The SNMPv3
securityParameters field must contain a Kerberos AP_REQ in a SNMP
request and must contain a Kerberos AP_REP in a SNMP response. These
Kerberos structures contain service tickets, which in turn contain an
encryption key. The encryption key must be used to protect the
scopedPDU. The Kerberos ticket may also contain user authorization
information (like a GroupName) in the AuthorizationData field. This
information may be used by VACM in the SNMP command responder to make
an authorization decision.
3.4. Services for generating an outgoing SNMP request
When a SNMP command generator needs to make a SNMP request, it must
generate an SNMP PDU. The Security Subsystem is invoked after the
SNMP PDU is constructed. As described in [RFC3411], the Message
Pejaver, et al. Expires April 28, 2011 [Page 10]
Internet-Draft Kerberos Security Model for SNMPv3 October 2010
Processing subsystem invokes the Security Subsystem using the
following interface provided by KSM
statusInformation =
generateRequestMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN securityModel -- for the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN scopedPDU -- message (plaintext) payload
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of the generated message
)
Figure 3
o securityModel: Must be Kerberos Security Model (KSM).
o securityName: The name of the principal requesting the command.
This name will identify the Kerberos credentials (TGT) that will
be used.
o securityLevel: This determines if the message needs to be
protected from disclosure and if the message needs to be
authenticated.
o scopedPDU: The payload will be protected as needed and will be
copied as part of the wholeMsg.
o securityParameters: This is filled in by KSM.
3.5. Services for generating an outgoing SNMP response
Similarly, when a SNMP command responder needs to respond to a SNMP
request, it must generate an SNMP response PDU. KSM provides the
following interface:
Pejaver, et al. Expires April 28, 2011 [Page 11]
Internet-Draft Kerberos Security Model for SNMPv3 October 2010
statusInformation = -- success or errorIndication
generateResponseMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN securityModel -- for the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN scopedPDU -- message (plaintext) payload
IN securityStateReference -- reference to security state
-- information from original
-- request
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of generated message
)
Figure 4
o securityStateReference: A handle/reference to cachedSecurityData
that was generated when processing the incoming Request message to
which this is the Response message.
3.6. Services for processing an incoming SNMP message
When the SNMP command responder receives a SNMP request, the message
is passed through the Transport Dispatcher and the Message Processing
Subsystem to the KSM Module. As described in [RFC3411], the Message
Processing Subsystem invokes the Security Subsystem using the
following interface provided by KSM:
Pejaver, et al. Expires April 28, 2011 [Page 12]
Internet-Draft Kerberos Security Model for SNMPv3 October 2010
statusInformation = -- errorIndication or success
-- error counter OID/value if error
processIncomingMsg(
IN messageProcessingModel -- typically, SNMP version
IN maxMessageSize -- of the sending SNMP entity
IN securityParameters -- for the received message
IN securityModel -- for the received message
IN securityLevel -- Level of Security
IN wholeMsg -- as received on the wire
IN wholeMsgLength -- length as received on the wire
OUT securityEngineID -- authoritative SNMP entity
OUT securityName -- identification of the principal
OUT scopedPDU, -- message (plaintext) payload
OUT maxSizeResponseScopedPDU -- maximum size sender can handle
OUT securityStateReference -- reference to security state
) -- information, needed for response
Figure 5
o securityParameters: These are the security parameters as received
in the message.
o securityModel: Must be Kerberos Security Model.
o securityName: The name of the principal requesting the command is
filled in by KSM.
o securityStateReference: A handle/reference to cachedSecurityData
to be used when securing an outgoing Response message..
4. Elements of the procedure
4.1. Procedure for outgoing requests
This section describes the procedure followed by an SNMP engine
whenever it generates a message containing an outgoing request (like
a request, a notification, or a report) on behalf of a user, with a
particular securityLevel.
If the securityLevel is noAuthNoPriv, then the scopedPDU is simply
copied as part of the output wholeMsg.
The Kerberos credentials are located using the specified
securityName. The Kerberos principal name of the command responder
service is determined. This should be composed of the service name
"snmp" and the hostname. The hostname should be the textual
representation of the IP address (v4 or v6). For example,
Pejaver, et al. Expires April 28, 2011 [Page 13]
Internet-Draft Kerberos Security Model for SNMPv3 October 2010
"snmp/192.168.1.25@realm.com".
A fresh Kerberos AP_REQ must be constructed for each message
transmission and retransmission. Note that Kerberos will reuse a
suitable unexpired service ticket if it is already available. If
SNMP authentication is required, then the Kerberos Mutual
authentication option must be requested.
If the securityLevel of the message is set to AuthPriv, the scopedPdu
payload must be encrypted using the encryption key in the AP_REQ
message.
The ksmSecurityParameters is constructed as follows.
ksmSecurityParameters ::= SEQUENCE {
-- The Kerberos 5 checksum type used to checksum this message
ksmChecksumType INTEGER(0..2147483647),
-- The actual keyed checksum data returned by Kerberos
ksmChecksum OCTET STRING,
-- The Kerberos 5 message (AP_REQ)
ksmKerberosMsg OCTET STRING,
}
Figure 6
o ksmChecksumType is an integer which corresponded to the checksum
algorithm used to secure this message as defined by Kerberos.
o ksmChecksum is the space for the checksum and is initialized with
the value 0.
o ksmKerberosMsg is the Kerberos 5 AP_REQ message.
The checksum algorithm defined by ksmChecksumtype is run and
resulting value is placed into ksmChecksum. The ASN.1 structure is
BER encoded as an OCTET STRING and copied into the SNMPv3
msgSecurityParameters.
4.2. Procedure for incoming requests
This section describes the procedure followed by an SNMP engine
whenever it receives a message containing a management operation on
behalf of a user, with a particular securityLevel.
The securityParameters value must be deserialized. The
ksmKerberosMsg value must contain a Kerberos AP_REQ message. This
message must be processed and the service ticket must be extracted.
Pejaver, et al. Expires April 28, 2011 [Page 14]
Internet-Draft Kerberos Security Model for SNMPv3 October 2010
The Kerberos principal name of the requestor must be obtained from
the ticket. This name must be returned as the value of securityName.
If present, the requesting user's authorization information is also
extracted from the ticket and associated with the
securityStateReference.
If the securityLevel of the message is set to AuthPriv, the payload
must be decrypted using the encryption key in the AP_REQ message.
Lastly, the integrity of the entire message must be checked.
4.3. Procedure for authorizing incoming requests
This section describes the procedures followed by an Access Control
module that implements the View-based Access Control Model when
checking access rights as requested by an application (for example a
Command Responder or a Notification Originator application). The
Access Control subsystem invokes the View-based Access Control Model
with the following primitive:
statusInformation = -- success or errorIndication
isAccessAllowed(
IN securityModel -- Security Model in use
IN securityName -- principal who wants to access
IN securityLevel -- Level of Security
IN viewType -- read, write, or notify view
IN contextName -- context containing variableName
IN variableName -- OID for the managed object
)
Figure 7
The securityName, securityModel and the authorization information
that was extracted from the ticket are used to identify a groupName
that will be used to make the access control decision. If the
authorization information is the groupName, then it can be directly
used.
4.4. Procedure for outgoing responses
After the SNMP command has been completed, the results need to be
communicated back to the requestor. This procedure is similar to
that for the outgoing request.
A fresh Kerberos AP_REP must be constructed for each message
response.
Pejaver, et al. Expires April 28, 2011 [Page 15]
Internet-Draft Kerberos Security Model for SNMPv3 October 2010
If the securityLevel of the message is set to AuthPriv, the scopedPdu
payload must be encrypted using the encryption key received earlier.
The ksmSecurityParameters is constructed as described earlier, except
that the AP_REP message is used instead of the AP_REQ message. If
authentication is requested, a message checksum is computed as
described earlier.
4.5. Procedure for incoming responses
Lastly, this section describes the procedures for processing response
messages on the command generator. The procedure is similar to that
of processing incoming requests, except that a Kerberos AP_REP
message appears instead of the AP_REQ.
5. Unconfirmed messages
Traps and Reports are handled just as all other outgoing requests. A
fresh AP_REQ must be constructed for each message. No response is
expected or processed.
InformsRequests are confirmed messages and are handled like other
confirmed requests. A response is expected and processed.
6. Comparative Analysis
6.1. Addressing the requirements
KSM uses the standard Kerberos protocols to effectively address the
following basic security requirements: Modification of Information,
Masquerade, Message Stream Modification and Disclosure.
Typical Kerberos implementations do not support two factor token
based authentication, but atleast one such implementation has been
built and deployed in a large scale.
6.2. Advantages of KSM
o Small Number of UDP packet exchanges.
o SNMP command responder can make an authorization decision without
communicating with any other service.
o SNMP command responder does not need to retain any state
information between SNMP requests.
Pejaver, et al. Expires April 28, 2011 [Page 16]
Internet-Draft Kerberos Security Model for SNMPv3 October 2010
o Compatible with VACM.
6.3. Disadvantages of this Security Model
Tickets are device specific, so the SNMP command generator must
obtain a ticket for each command responder before SNMP exchanges are
started. Hence, the generator must get a larger number of tickets if
it wants to communicate with a large number of SNMP command
generators devices. However, this burden is placed on the command
generator and not on the managed device.
A fresh AP_REQ (AP_REP) must be constructed for each command
(response) generated. However, only the first AP_REQ will require
communications with the Kerberos server to get a service ticket.
6.4. Issues with models based on transport sessions
One of the approaches to SNMP security is to set up a secure
"transport" connection using SSH between the SNMP command generator
and the SNMP command responder. Some of the issues with this
approach are:
1. Every SNMP command responder needs to be trusted since it sees
administrator passwords. It would be tempting for a hacker to
spoof a SNMP command responder and steal the passwords, which
could then be used to attack other managed devices.
2. Every SNMP command responder needs to be configured as a RADIUS
client.
3. User authentication hits the RADIUS server for each device
accessed. Ideally, RADIUS should be invoked only once during
user "login".
4. Token based two-factor authentication is not fully supported
because interactivity may be required for resynchronization and
'new PIN' modes.
5. Setup overhead for ssh (and TLS) precludes short SNMP exchanges
(like status polls.)
6. SNMP command responder code is more complicated. It has to
retain much more state.
7. SSH (or TLS) uses public key cryptography during session setup,
which is somewhat compute intensive.
Pejaver, et al. Expires April 28, 2011 [Page 17]
Internet-Draft Kerberos Security Model for SNMPv3 October 2010
7. IANA Considerations
The following IDs and constants should be allocated:
1. SNMPv3 SecurityModel ID for Kerberos Security Model (KSM)
2. Kerberos AuthorizationData type ID indicating that the content is
SNMP Authorization information.
3. Kerberos PreAuthentication data type indicating that the content
is requesting that SNMP Authorization information be added.
8. 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. SNMP
command generators may wish to request service tickets ahead of
needing them to ensure that access to a device is possible even
if network outages occur between the command generators and the
KDC.
9. Acknowledgements
Authors would like to acknowledge the previous internet draft
[draft-hornstein-snmpv3-ksm].
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Pejaver, et al. Expires April 28, 2011 [Page 18]
Internet-Draft Kerberos Security Model for SNMPv3 October 2010
[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.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415,
December 2002.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC5608] Narayan, K. and D. Nelson, "Remote Authentication Dial-In
User Service (RADIUS) Usage for Simple Network Management
Protocol (SNMP) Transport Models", RFC 5608, August 2009.
10.2. Informative 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-11
(work in progress), September 2010.
Appendix A. Implementation Details
Sample code for KSM implementation: TBD.
Authors' Addresses
Rajaram Pejaver
Comcast
One Comcast Center
Philadelphia, PA 19103
U.S.A.
Email: rajaram_pejaver@cable.comcast.com
URI: http://www.comcast.com
Pejaver, et al. Expires April 28, 2011 [Page 19]
Internet-Draft Kerberos Security Model for SNMPv3 October 2010
Yiu L. Lee
Comcast
One Comcast Center
Philadelphia, PA 19103
U.S.A.
Email: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
Wes Hardaker
SPARTA, Inc.
P.O. Box 382
Davis, CA 95617
USA
Phone: +1 530 792 1913
Email: ietf@hardakers.net
URI: http://www.hardakers.net/
Ken Hornstein
US Naval Research Laboratory
Bldg A-49, Room 2, 4555 Overlook Avenue
Washington DC 20375
U.S.A.
Phone: +1 (202) 404-4765
Email: Kenh@cmf.nrl.navy.mil
Pejaver, et al. Expires April 28, 2011 [Page 20]