Network Working Group K. Narayan
Internet-Draft Cisco Systems
Expires: January 12, 2006 E. Lear
Cisco Systems GmbH
J. Salowey
Cisco Systems
July 11, 2005
A BEEP Profile for SNMPv3 PDUs
draft-kaushik-isms-btsm-00.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 12, 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.
Narayan, et al. Expires January 12, 2006 [Page 1]
Internet-Draft BTSM 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) . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 SASL . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 SNMP Channel Initiation . . . . . . . . . . . . . . . . . 5
2.5 Use of the SNMP channel . . . . . . . . . . . . . . . . . 6
2.6 SNMP Notifications . . . . . . . . . . . . . . . . . . . . 6
2.7 Passing Security Parameters from SNMPv3 . . . . . . . . . 6
2.8 Authentication Model . . . . . . . . . . . . . . . . . . . 6
3. Identities used for authentication . . . . . . . . . . . . . . 7
4. SNMPv3 Security Model Requirements . . . . . . . . . . . . . . 7
5. Re-use of BEEP substrate . . . . . . . . . . . . . . . . . . . 7
5.1 Considerations for Substrate Re-use . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1 Normative References . . . . . . . . . . . . . . . . . . . 9
8.2 Informational References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
A. BEEP Profile for SNMP . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 12
Narayan, et al. Expires January 12, 2006 [Page 2]
Internet-Draft BTSM 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.[9]. For
example, it is impossible to integrate USM with RADIUS.[4] 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 appropriate. 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
SNMP has traditionally been transported over UDP. There are good
reasons for this approach. Because SNMP is a network management
protocol, if a network failure occurs it may prove difficult to
impossible to establish a TCP connection. In addition, the cost of
connection state on both the network element and the network
management station has been viewed as concern. For those uses where
these concern remains SNMP over UDP remains a viable alternative.
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 12, 2006 [Page 3]
Internet-Draft BTSM July 2005
1.3 Choice of BEEP
There are several substantial benefits for Block Extensible Exchange
Protocol (BEEP).[5] 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 invoke 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 [8]. The fact that any peer can
initiate a connection simplifies NAT and firewall traversal.
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 device at the end of a BEEP connection may play the role of an
initiator. Devices 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.
2.2 Greeting(s)
After a transport connection is established, as greetings are
exchanged, devices SHOULD each announce support for TLS, and
optionally SASL. For instance:
Narayan, et al. Expires January 12, 2006 [Page 4]
Internet-Draft BTSM July 2005
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 STARTs a channel with the TLS profile. Once TLS has been
successfully negotiated a new greeting is sent by both initiator and
listener. This new greeting will contain any available SASL profiles
along with the SNMP profile, http://iana.org/beep/snmp.
2.3 SASL
If SASL profiles are specified, a channel is started by either or
both sides 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.
2.4 SNMP Channel Initiation
Either initiator or listner MAY advertise the SNMP profile. If
neither 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:
I: MSG 0 1 . 52 116
I: Content-Type: application/beep+xml
I:
I:
I:
I:
I: END
In this case the initiator has started the SNMP channel. If it is
successful, the other end will respond with a positive RPY. For
example:
Narayan, et al. Expires January 12, 2006 [Page 5]
Internet-Draft BTSM July 2005
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 SNMP Notifications
2.7 Passing Security Parameters from SNMPv3
2.8 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. In cases where the participants have
different types of credentials then it is likely that both will be
needed. This specification makes the following recommendations:
1. The TLS channel used to provide channel protection. At the very
least the BEEP listener 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-
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
Narayan, et al. Expires January 12, 2006 [Page 6]
Internet-Draft BTSM July 2005
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 Recipient SNMP engines will be authenticated
through TLS and must either have a public/private key pair and
certificate or share a key with the command generator or notification
receiver. Originator SNMP engines 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 SNMP securityName MUST be used in all cases to represent the
authenticated name of the client principal but the snmpEngineID may
not be used to represent the authenticated name of the SNMP engine.
SNMP engine implementations MUST provide a mapping from the
authenticated name to an engineID.
Recipient SNMP engines may 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
Recipient SNMP engines MUST be able to map the authenticated entity
to the engineID. Implementations may have this mapping configured as
part of SNMPv3 engine configuration. Originator SNMP engines MUST
authenticate with the SNMP securityName and the securityName MUST be
defined as the subject Name within the X.509 certificate in case of
PKI authentication of the client principal.
4. SNMPv3 Security Model Requirements
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
Narayan, et al. Expires January 12, 2006 [Page 7]
Internet-Draft BTSM July 2005
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.
5.1 Considerations for Substrate Re-use
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.[10]
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.
What's more, 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 [11]. 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.
The level of protocol security through the approach in this
Narayan, et al. Expires January 12, 2006 [Page 8]
Internet-Draft BTSM July 2005
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 implemetnations do not. So long the underlying transport
is encrypted, the risk is limited to an attack on the encryption
method, the device, or the radius server itself.
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. References
8.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,
RFC 3205, February 2002.
[8] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
for Describing Simple Network Management Protocol (SNMP)
Management Frameworks", STD 62, RFC 3411, December 2002.
[9] 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.
Narayan, et al. Expires January 12, 2006 [Page 9]
Internet-Draft BTSM July 2005
[10] 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.
8.2 Informational References
[11] 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
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???
Narayan, et al. Expires January 12, 2006 [Page 10]
Internet-Draft BTSM July 2005
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 12, 2006 [Page 11]
Internet-Draft BTSM 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 12, 2006 [Page 12]