Network Working Group K. Narayan
Internet-Draft Cisco Systems
Expires: January 9, 2006 E. Lear
Cisco Systems GmbH
J. Salowey
Cisco Systems
July 8, 2005
A BEEP Profile for SNMPv3 PDUs
draft-kaushik-tsms-beep-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 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Transport Mapping Security Model (TSMS) describes a framework
to provide a security for SNMPv3 by an underlying transport protocol.
This document leverages the TMSM framework and describes the use of
the Block Extensible Exchange Protocol (BEEP) for securing SNMPv3.
This specification describes BEEP Transport Mapping Security Model.
This document specifies the use of BEEP combined with SASL and TLS
as transport for SNMP requests and responses. We define a URI and
specify a BEEP profile to be used.
Narayan et al. Expires January 9, 2006 [Page 1]
Internet-Draft BEEP-TSMS July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Design Considerations . . . . . . . . . . . . . . . . . . 3
2. The BEEP Transport Mapping . . . . . . . . . . . . . . . . . . 3
2.1 Session Establishment . . . . . . . . . . . . . . . . . . 3
2.2 Greeting(s) . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 SASL . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 SNMP Channel Initiation . . . . . . . . . . . . . . . . . 4
2.5 Use of the SNMP channel . . . . . . . . . . . . . . . . . 5
2.6 SNMP Notifications . . . . . . . . . . . . . . . . . . . . 5
2.7 Authentication Model . . . . . . . . . . . . . . . . . . . 5
3. Identities used for authentication . . . . . . . . . . . . . . 6
4. BEEP Transport Mapping Security Model . . . . . . . . . . . . 7
4.1 TSMS Security Protocol Requirements . . . . . . . . . . . . 7
4.2 Passing Parameters between TMSP and MPSP . . . . . . . . . 7
5. Re-use of BEEP substrate . . . . . . . . . . . . . . . . . . . 7
5.1 Considerations for Substrate Re-use . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1 Normative References . . . . . . . . . . . . . . . . . . . 8
8.2 Informational References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
A. BEEP Profile for SNMP . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Narayan et al. Expires January 9, 2006 [Page 2]
Internet-Draft BEEP-TSMS July 2005
1. Introduction
The current SNMPv3 security model USM does not integrate well with
other authentication and access controls on devices.[8]. 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 NATs in order to
properly process requests.
The TSMS framework allows the use of a transport protocol such
as TLS, D-TLS etc. to provide integration with authentication
systems such as RADIUS, X.509 certificates, Local Accounts etc.
This document describes a BEEP Transport Mapping Security Model
that enables the use of BEEP as the transport protocol
for SNMPv3, the considerations for BEEP to be used as a TSMS
protocol are described below.
1.1 Design Considerations
There are several substantial benefits for 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]
Network management opeations typically happens via a variety of
managament protocols (NetConf, SNMP, Syslog) and in quite a few cases
involves more than one management protocol as part of the same
operation.Even if all management protocols were able to use common
authentication systems, it solves only part of the problem. Each of
these protocols will require independent authentication transactions
which may involve the same principal and credentials to be
authenticated repeatedly. The use of BEEP will potentially allow a
single BEEP session for all management protocols and will require
only one authentication transaction.
BEEP is ideal as a transport protocol for peer to peer communication
model, which is similar to the one described for SNMP in RFC3411 [7],
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.
Narayan et al. Expires January 9, 2006 [Page 3]
Internet-Draft BEEP-TSMS July 2005
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:
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
Narayan et al. Expires January 9, 2006 [Page 4]
Internet-Draft BEEP-TSMS July 2005
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:
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
[TBD]
2.7 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.
Narayan et al. Expires January 9, 2006 [Page 5]
Internet-Draft BEEP-TSMS July 2005
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 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 implement MUST have to deal with mapping 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.
Narayan et al. Expires January 9, 2006 [Page 6]
Internet-Draft BEEP-TSMS July 2005
4. BEEP Transport Mapping Security Model
4.1. TSMS Security Protocol Requirements
Section 3.1.1 of [TSMS] specifies the requirements for a protocol to
be used part of the TSMS framework. This section we look at whether
BEEP meets those requirements
1. BEEP was designed for the purpose it's use is being described
in this document. The primary objective of BEEP is provide a
framework to build application layer protocols.
2. BEEP requires no changes to work as part of the TSMS framework.
BEEP allows various protocol bindings to be described as BEEP
profiles and the BEEP profile for SNMP is described in the above
sections.
4.2. Passing parameters between TMSP and MPSP
[TBD]
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.
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.[6] In this
example we will look at the NETCONF over BEEP mapping as the other
application running on top of the substrate.[9]
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 [10]. 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
[TBD]
Narayan et al. Expires January 9, 2006 [Page 7]
Internet-Draft BEEP-TSMS July 2005
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] D. Harrington and J. Schoenwaelder, "Transport Mapping Security
Model (TMSM) for the Simple Network Management Protocol version
3 (SNMPv3)", draft-schoenw-snmp-tlsm-02.txt (work in progress),
November 2005.
[6] Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, 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.
[10] Lear, E. and K. Crozier, "Using the NETCONF Protocol over Blocks
Extensible Exchange Protocol (BEEP)", draft-ietf-netconf-beep-03
(work in progress), November 2004.
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.
Narayan et al. Expires January 9, 2006 [Page 8]
Internet-Draft BEEP-TSMS July 2005
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
2901 3rd Ave
Seattle, WA 98121
USA
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 9, 2006 [Page 9]
Internet-Draft BEEP-TSMS 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 9, 2006 [Page 10]