Network Working Group K. Narayan
Internet-Draft Cisco Systems
Expires: January 14, 2006 E. Lear
Cisco Systems GmbH
J. Salowey
Cisco Systems
July 13, 2005
A BEEP Profile for SNMPv3 PDUs
draft-kaushik-isms-btsm-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on January 14, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
In response to the need for a security model for SNMP that integrates
with other device security models, we specify the use of BEEP
combined with SASL and TLS as a transport for SNMP requests and
responses. We define a URI and specify a BEEP profile to be used,
and we relate our work to the Transport Mapping Security Model.
Narayan, et al. Expires January 14, 2006 [Page 1]
Internet-Draft BTSMS July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Authentication Design Considerations . . . . . . . . . . . 3
1.2 Transport Design Decisions . . . . . . . . . . . . . . . . 3
1.3 Choice of BEEP . . . . . . . . . . . . . . . . . . . . . . 4
2. The BEEP Transport Mapping . . . . . . . . . . . . . . . . . . 4
2.1 Session Establishment . . . . . . . . . . . . . . . . . . 4
2.2 Greeting(s) . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 SASL . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 SNMP Channel Initiation . . . . . . . . . . . . . . . . . 5
2.5 Use of the SNMP channel . . . . . . . . . . . . . . . . . 6
2.6 Authentication Model . . . . . . . . . . . . . . . . . . . 6
3. Identities used for authentication . . . . . . . . . . . . . . 7
4. BEEP Transport Mapping Security Model . . . . . . . . . . . . 8
4.1 BEEP and TMSM Security Requirements . . . . . . . . . . . 8
5. Re-use of BEEP substrate . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1 Normative References . . . . . . . . . . . . . . . . . . . 10
9.2 Informational References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
A. BEEP Profile for SNMP . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 13
Narayan, et al. Expires January 14, 2006 [Page 2]
Internet-Draft BTSMS July 2005
1. Introduction
[EDITOR NOTE: This is a drafty draft.]
The current SNMPv3 security model USM does not integrate well with
other authentication and access controls on devices.[10] For
example, it is impossible to integrate USM with RADIUS. In addition,
SNMP's UDP transport poses certain limitations, such as the need for
application awareness at firewalls and network address translators
(NATs) in order to properly process requests.
1.1 Authentication Design Considerations
No new authentication mechanism is needed for SNMP. Instead,
integration with the existing approaches is necessary. Hence, an
approach that makes use of general authentication mechanisms that can
in turn call more specific functions will provide the most
flexibility to meeting end user requirements.
1.2 Transport Design Decisions
The ubiquitous transport mapping for SNMP has always been over UDP.
However, a transport mapping for over TCP is specified in [11]. Some
of the advantages and disadvantages of UDP versus TCP are well-
described in that document, including costs/overhead, connection
state, flow control, and message segmentation.
However, since the time SNMP was first designed the network
architecture has shifted substantially. Two critical components,
firewalls and NATs have become prevalent. Both NATs and firewalls
make UDP communication anywhere from spotty to impossible, depending
on as much implementation as policy, where it would be clearly more
desirable for the limitation to be solely based on policy.
Because connection state is available for all to inspect, NATs and
firewalls have an easy time of determining who initiated a
communication and on what port. Hence, a policy decision is easier
than it would be in UDP where state must be maintained within the
application. Use of transport layer security allows connection state
state to remain out in the open, even when the application protocol
is encrypted.
Finally, many firealls and NATs will allow communiations only in a
single direction - outbound from the device being protected or being
"NATted", and so a "call-home" function is desirable.
Narayan, et al. Expires January 14, 2006 [Page 3]
Internet-Draft BTSMS July 2005
1.3 Choice of BEEP
We specify in this document the use of Block Extensible Exchange
Protocol (BEEP).[12] There are several substantial benefits for BEEP.
First, it meets the fundamental need of operators to integrate with
existing authentication infrastructure. It can do this through the
use of SASL, which can integrate with Radius or other centralized
password verification mechanisms to authenticate sessions.[2] BEEP
uses SASL for authentication and TLS to provide confidentiality and
integrity protection.[3]
A TCP transport mapping is defined for BEEP.[6]. This combined with
its peer to peer approach allows for TCP connections to originate in
either direction independently of whether an end plays the role of
the manager or the managed element.
In addition network management operations typically happen via a
variety of managament protocols (e.g., NETCONF, SNMP, SYSLOG) and in
The use of BEEP will potentially allow a single BEEP session for all
management protocols and will require only one authentication
transaction per pair of devices.
As mentioned earlier, BEEP is an ideal as a transport protocol for
peer to peer communication model, which is similar to the one
described for SNMP in RFC3411 [9]. The fact that any peer can
initiate a connection simplifies NAT and firewall traversal.
The Transport Mapping Security Model [13] describes a framework to
provide a security for SNMPv3 via an underlying transport protocol.
This document leverages the TMSM framework and describes the use of
the BEEP for securing SNMPv3. This specification describes BEEP
Transport Mapping Security Model.
2. The BEEP Transport Mapping
All SNMP over BEEP implementations MUST implement the profile and
functional mapping between SNMP and BEEP as described below.
2.1 Session Establishment
Either SNMP engine at the end of a BEEP connection may play the role
of an initiator. SNMP engines MUST be configured to listen to or
connect using a specific BEEP transport connection. Port XXX is
assigned for BEEP over SNMP. Alternatively, the SNMP profile may be
announced on any BEEP transport connection where the security
policies match.
[RFC Editor: - please replace XXX with the appropriate IANA
Narayan, et al. Expires January 14, 2006 [Page 4]
Internet-Draft BTSMS July 2005
assignment.]
2.2 Greeting(s)
After a transport connection is established, as greetings are
exchanged, SNMP engines SHOULD each announce support for TLS if they
possess credentials to act as a TLS server and optionally for SASL.
For instance:
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml
L:
L:
L:
L:
Once greetings are exchanged, if TLS is announced as above, the
listener SNMP engine STARTs a channel with the TLS profile. If both
SNMP engines announce support for TLS, then the SNMP engine that
initiated the BEEP connection acts as the TLS client. Once TLS has
been successfully negotiated a new greeting is sent by both SNMP
engines. This new greeting will contain any available SASL profiles
along with the SNMP profile, http://iana.org/beep/snmp.
Implementations of this specification MUST support
TLS_RSA_WITH_AES_128_CBC_SHA as specified RFC 3268 [8].
Implementations SHOULD support client side authentication with TLS.
2.3 SASL
If SASL profiles are specified, a channel is started by either or
both SNMP engines with the list of SASL profiles available. An
answer is then supplied indicating which profile is to be used for
authentication. For examples, see RFC-3080. Implementations SHOULD
support SASL PLAIN and DIGEST profiles.
2.4 SNMP Channel Initiation
Either initiator or listner SNMP engines MAY advertise the SNMP
profile. If neither SNMP engine advertises the profile or if the
initiator advertises the profile but the listener is not configured
to use it or any other profile, the listener should shutdown the BEEP
connection (see below) and log an error that indicates that nobody
wanted to actually use the BEEP connection for anything.
For example:
Narayan, et al. Expires January 14, 2006 [Page 5]
Internet-Draft BTSMS July 2005
I: MSG 0 1 . 52 116
I: Content-Type: application/beep+xml
I:
I:
I:
I:
I: END
In this case the initiator SNMP engine has started the SNMP channel.
If it is successful, the other end will respond with a positive RPY.
For example:
L: RPY 0 1 . 221 83
L: Content-Type: application/beep+xml
L:
L:
L: END
Conversely if the channel cannot be created, an ERR response is sent.
2.5 Use of the SNMP channel
The SNMP channel is used to transmit complete SNMP PDUs encoded in
ASN.1.
2.6 Authentication Model
Authentication will occur at two places. One is where transport
layer security such as TLS is provided and the other is at the
application layer where a mechanism such as SASL can be used. Both
of these mechanisms can support a variety of credentials and both can
provide a security layer, however this specification recommends that
TLS MUST be used to provide the security layer. This specification
makes the following recommendations:
1. The TLS channel used to provide channel protection. At the very
least SNMP entities that contain one or more command recievers
and/or notification generation applications (traditionally been
called an SNMP agent) MUST provide an X.509 certificate and each
side that side (listener or initiator) MUST have a reliable trust
anchor with appropriate policies to handle a network failure.
2. If both parties are authenticated during the TLS conversation
then SASL EXTERNAL method is used.
3. If one party is not authenticated during the TLS conversation
then an appropriate SASL mechanism is invoked to authenticate the
un-authenticated party. It is RECOMMENDED to implement SASL-
Narayan, et al. Expires January 14, 2006 [Page 6]
Internet-Draft BTSMS July 2005
DIGEST mechanism. Other SASL mechanisms may be supported. SASL
PLAIN MAY be used if the back-end authentication mechanism does
not support digests AND TLS is used. PLAIN MUST NOT be used if
TLS is not used.
4. In some cases it is possible that the side that is accepting the
initial connection does not have the credentials to act as a TLS
server. The may happen when an SNMP engine is initiating a
connection to send a notification and it has public key based
credentials and the notification receiver is expected to use
password based credentials. In this case TLS may be proceed with
the connection initiator acting as the TLS server and the
connection acceptor acting as TLS client. The capability to act
as a TLS server with an entity is advertised through the BEEP
channel negotiation. If both sides indicate they can act as a
TLS server that the entity accepting the connection assumes the
server role.
It is expected that SNMP entities that contain one or more command
processors and/or notification generators will be authenticated
through TLS and must either have a public/private key pair and
certificate or share a key with the SNMP entities that contain one or
more command generator and/or notification receiver. SNMP entities
that contain one or more command generators and/or notification
recievers will be authenticated through TLS or a SASL mechanism.
This allows them to use a wide variety of credentials such as
passwords, public key certificates, Kerberos tickets, and shared
keys.
3. Identities used for authentication
As described in the previous section, the specification deals will
authentication at two levels, i.e. authentication of the end points
to setup the channel and authentication of the application principal.
RFC3411 does have a notion of two separate identities, the SNMP
engines are identified by thier engineID, i.e. the snmpEngineID and
client principal is identified by the securityName.
The authenticated name of the client principal SHOULD be the SNMP
securityName and in instances that is not the case, implementations
MUST be to able to map the authenticated name to securityName. The
snmpEngineID MAY be used represent an authenticated name or this MAY
require mapping.
SNMP entities that contain one or more command processors and/or
notification generators MUST authenticate using a X.509 certificate,
the snmpEngineID MAY be used as the subject Name within the X.509
certificate. In case a different entity is used as subject Name, the
SNMP engines MUST be able to map the authenticated entity to the
Narayan, et al. Expires January 14, 2006 [Page 7]
Internet-Draft BTSMS July 2005
engineID. Implementations may have this mapping configured as part
of SNMPv3 engine configuration. SNMP entities that contain one or
more command generators and/or notification recievers MUST
authenticate with the SNMP securityName and the securityName SHOULD
be defined as the subject Name within the X.509 certificate in case
of PKI authentication of the client principal.
4. BEEP Transport Mapping Security Model
The BEEP Transport Mapping Security Model is intended conform to the
framework described in [13]. This includes the implementation of the
security model in two parts, the BEEP Security Mapping Security
Process (SMSP) and the BEEP Transport Mapping Security Process
(TMSP). The tmStateReference MUST be used to pass information
between the BEEP TMSP and SMSP and the securityStateReference MUST be
used to pass information between the BEEP SMSP and TMSP. The
securityStateReference cache for BEEP would be TBD.
4.1 BEEP and TMSM Security Requirements
TMSM states that as per [RFC3411], Transport mapping security
protocols SHOULD provide the protection against the following
message-oriented threats:
1. Modification of Information
2. Masquerade
3. Message stream modification
4. Disclosure
BEEP meets all these requirements, BEEP uses TLS and SASL to provide
mutual authentication of the SNMP engines to prevent masquerade. TLS
is also used to provide integrity protection to prevent data
modification and confidentiality protection to prevent disclosure.
TLS provides true replay protection that is used to prevent message
stream modification.
5. Re-use of BEEP substrate
BEEP is designed to allow multiple independent subsystems communicate
over a single transport stream. This is appropriate under certain
circumstances. In those cases where an appropriate transport
connection already exists, the SNMP profile is simply announced as
part of the greeting by one side of the connection and invoked by the
other.
We consider the question of whether re-use of a particular substrate
is appropriate based on RFC-3205 (BCP-56) Section 3.[7] In this
example we will look at the NETCONF over BEEP mapping as the other
application running on top of the substrate.[12]
Narayan, et al. Expires January 14, 2006 [Page 8]
Internet-Draft BTSMS July 2005
The principle question from BCP-56 is this: does addition of one of
the two protocols in question represent a substantially new service?
The answer is clearly not. We know this because the whole point of
SNMP over BEEP with SASL/TLS is to integrate the security model with
that of the rest of the administrative model on the device, which is
what NETCONF is expected to use. We further know this because the
sort of data the protocols are meant to carry are substantially
similar.
There are two substantial benefits of combining the two:
o Improved network performance and fairness through the use of a
shared TCP window as discussed in [14]. This may be a minor or
major point, but it's a bit early to say.
o Simplified configuration and improved performance on firewalls,
and potentially on end devices as well. It's one less port to
have to keep track of, and it's one less port check to have to
process.
For these reasons it is reasonable to consider using SNMP and NETCONF
on the same BEEP channel. A similar analysis should be done with
other potential applications. For instance, it is unlikely that one
would make use of an insecure channel for SNMP, such as what might be
found with instant messaging protocols.
6. Security Considerations
This BEEP profile marks a departure from USM in several respects.
First, the localization algorithm is not used. Instead,
authentication occurs through TLS and/or SASL. It is therefore
possible and indeed likely that a system will be configured to use a
centralized password database. USM prevents compromised of such
databases when a network element is compromised. If an attacker has
full access to the network element that includes what code is
running, such attacks may again be possible.
Since SASL and TLS support a wide range of credentials, the level of
protocol security through the approach in this specification is
extremely flexible, and is as much a choice of deployment as it is
implementation. For instance, MD5-DIGEST can only be used if the
back-end store supports it. As of this writing most RADIUS
implementations do not. The SASL PLAIN mechanism sends a user name
and password in clear text to the peer. This means that a
compromised peer has access to the password and therefore the
password is compromised for all uses. This is less secure than USM
which provides for password localization to ensure that a compromised
peer only has access to credential that has a reduced scope of
applicability. Likewise it is possible to support anonymous
cuphersuites with TLS in which neither side is authenticated, but an
Narayan, et al. Expires January 14, 2006 [Page 9]
Internet-Draft BTSMS July 2005
encrypted tunnel is established. This type of negotiation is open to
man-in-the-middle attacks and is NOT RECOMMENDED.
TLS is negotiated only once per BEEP connection. The level of
security MUST be set upon the initiation of the connection and MUST
not be changed during the life of the connection. For example one
should not change the underlying protection from an encrypted to
unencrypted or change the identity of the peers once data is flowing
over a session. BEEP also only allows for one SASL negotiation per
connection. If new identities or new protection levels are required
than a new BEEP connection MUST be initiated.
7. IANA Considerations
The IANA will assign a TCP port for this specification.
The IANA will register "http://iana.org/BEEP/SNMP" as a BEEP profile.
8. Acknowledgments
Thanks in large part to Keith McCloghrie who knows more about SNMP
than all the authors put together.
9. References
9.1 Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[2] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
[3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A., and
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
January 1999.
[4] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[5] Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, March 2001.
[6] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081,
March 2001.
[7] Moore, K., "On the use of HTTP as a Substrate", BCP 56,
Narayan, et al. Expires January 14, 2006 [Page 10]
Internet-Draft BTSMS July 2005
RFC 3205, February 2002.
[8] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002.
[9] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
for Describing Simple Network Management Protocol (SNMP)
Management Frameworks", STD 62, RFC 3411, December 2002.
[10] 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.
[11] Schoenwaelder, J., "Simple Network Management Protocol Over
Transmission Control Protocol Transport Mapping", RFC 3430,
December 2002.
[12] Lear, E. and K. Crozier, "Using the NETCONF Protocol over
Blocks Extensible Exchange Protocol (BEEP)",
draft-ietf-netconf-beep-05 (work in progress), April 2005.
[13] Harrington, D. and J. Schoenwaelder, "Transport Mapping
Security Model (TMSM) for the Simple Network Management
Protocol version 3 (SNMPv3)", draft-schoenw-snmp-tlsm-02 (work
in progress), May 2005.
9.2 Informational References
[14] Nielson, H., Gettys, J., Baird-Smith, A., Prud'hommeaux, E.,
Lee, H., and C. Lilley, "Network performance effects of
HTTP/1.1, CSS1, and PNG", Proceedings of the ACM SIGCOMM 1997,
October 1997.
Authors' Addresses
Kaushik Narayan
Cisco Systems
170 W. Tasman Dr.
San Jose 95134
US
Email: kaushik@cisco.com
Narayan, et al. Expires January 14, 2006 [Page 11]
Internet-Draft BTSMS July 2005
Eliot Lear
Cisco Systems GmbH
Glatt-com
Glattzentrum, ZH CH-8301
Switzerland
Phone: +41 1 878 7525
Email: lear@cisco.com
Joseph Salowey
Cisco Systems
170 W. Tasman Dr.
San Jose 95134
US
Email: jsalowey@cisco.com
Appendix A. BEEP Profile for SNMP
Profile Identification: http://iana.org/BEEP/snmp
Message Exhanged during Channel Creation: none
Messages starting one-to-one exhanges: as defined in RFC341???
Messages in positive replies: as defined in RFC341???
Messages in negative replies: none
Messages in one-to-many exchanges: none
message Semantics: as specified by RFC341X???
Contact: As listed in authors section of this document
Narayan, et al. Expires January 14, 2006 [Page 12]
Internet-Draft BTSMS July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Narayan, et al. Expires January 14, 2006 [Page 13]