NMRG D. Harrington
Internet-Draft Independent
Expires: April 19, 2005 J. Schoenwaelder
International University Bremen
October 19, 2004
Transport Layer Security Model (TLSM) for the Simple Network
Management Protocol version 3 (SNMPv3)
draft-schoenw-snmp-tlsm-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 April 19, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes the Transport Layer Security Model (TLSM) for
the Simple Network Management Protocol (SNMP) version 3 for use in
the SNMP architecture. At this stage, this document does not provide
a complete solution - it rather identifies and discusses some key
aspects that need discussion and future work.
Harrington & Schoenwaelder Expires April 19, 2005 [Page 1]
Internet-Draft SNMPv3 Transport Layer Security Model October 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. TLS/TCP and DTLS/UDP . . . . . . . . . . . . . . . . . . . . . 4
4. SASL Authentication for SNMP . . . . . . . . . . . . . . . . . 4
5. Architectural Considerations . . . . . . . . . . . . . . . . . 5
5.1 An Architecture Extension for Transport Security Models . 5
5.1.1 Cached Security Data . . . . . . . . . . . . . . . . . 6
5.2 TLS Transport Security Model . . . . . . . . . . . . . . . 7
5.2.1 TLS Cached Security Data . . . . . . . . . . . . . . . 8
5.3 Message Processing Model for TLS Security . . . . . . . . 8
5.4 MP Security Model for TLS Security . . . . . . . . . . . . 9
5.5 MIB Module for TLS Security . . . . . . . . . . . . . . . 9
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 9
7.2 Informative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 11
Harrington & Schoenwaelder Expires April 19, 2005 [Page 2]
Internet-Draft SNMPv3 Transport Layer Security Model October 2004
1. Introduction
The standard SNMPv3 protocol [RFC3410] supports the User-based
Security Model (USM) as defined [RFC3414]. The USM security model
was designed to work with any transports and to be independent of
other existing security infrastructures. USM therefore requires a
separate user and key management infrastructure. Operators have
reported that deploying another user and key management
infrastructure in order to use SNMPv3 is a reason for not deploying
SNMPv3 at this point in time.
This document proposes to introduce a Transport Layer Security Model
(TLSM) as an extension of the SNMPv3 architecture which allows
security to be provided by an SNMP transport system. Such a TLSM
would then enable to use existing security mechanism such as (TLS)
[RFC2246], Kerberos [RFC1510] or SASL [RFC2222] within the SNMPv3
architecture.
This document provides the motivation for leveraging transport layer
security mechanisms for secure SNMP communication, identifies some
key issues and provides some proposals for design choices that may be
made to provide a workable solution that meets operational
requirements and fits into the SNMP architecture defined in [RFC3411]
2. Motivation
There are a number of Internet security protocols and mechanisms that
are in wide spread use. Many of them try provide a generic
infrastructure to be used by many different application layer
protocols. The motivation of behind TSLM is to leverage these
protocols where it seems useful. The key challenge to be solved is
to map the security provided by a secure transport into the SNMP
architecture so that SNMP continues to work without any surprises.
Transport layer security protocols SHOULD ideally provide the
protection against the following threads [RFC3411]:
1. modification of information
2. masquerade
3. message stream modification
4. disclosure
Accoring to [RFC3411], it is not required to protect against denial
of service or traffic analysis.
For SNMP access control to function properly, the security mechanism
must establish a securityName, which is the security model
independent identifier for a principal, and a securityLevel. The
Harrington & Schoenwaelder Expires April 19, 2005 [Page 3]
Internet-Draft SNMPv3 Transport Layer Security Model October 2004
SNMP architecture distinguishes between no authentication and no
privacy (noAuthNoPriv), authentication without privacy (authNoPriv)
and authentication with privacy (authPriv). Hence, the
authentication of a securityName plays an important role and must be
considered by any transport layer security mechanism.
3. TLS/TCP and DTLS/UDP
SNMP supports multiple transports. The preferred transport for SNMP
over IP is UDP [RFC3417]. An experimental transport for SNMP over
TCP is defined in [RFC3430].
Transport Layer Security (TLS) [RFC2246] traditionally requires a
connection-oriented transport and is usually used over TCP. Datagram
Transport Layer Security (DTLS) [DTLS] provides security services
equivalent to TLS for connection-less transports such as UDP.
[D]TLS provides all the security services needed from an SNMP
architectural point of view. Although it is possible to derive a
securityName from the public key certificates (e.g. the subject
field), this approach requires to install certificates on agents and
as well as managers, leading to a certificate management problem
which again does not integrate well with established AAA systems.
Another option is to run an authentication exchange which is
integrated with TLS, such as Secure Remote Password with TLS
[SRP-TLS]. A similar option would be to use Kerberos authentication
with TLS as defined in [RFC2712].
It is important to stress that the authentication exchange must be
integrated into the TLS mechanism to prevent man-in-the-middle
attacks. While SASL [RFC2222] is often used on top of a TLS
encrypted channel to authenticate users, this choice seems to be
problematic until the mechanism to cryptographically bind SASL into
the TLS mechanism has been defined.
TODO: Need to discuss to what extend DTLS is a reasonable choice for
SNMP interactions.
TODO: What is the status of the work to cryptographically bind SASL
to [D]TLS?
TODO: More details need to be worked out...
4. SASL Authentication for SNMP
The Simple Authentication and Security Layer (SASL) [RFC2222]
provides a hook for authentication and security mechanisms to be used
Harrington & Schoenwaelder Expires April 19, 2005 [Page 4]
Internet-Draft SNMPv3 Transport Layer Security Model October 2004
in application protocols. SASL supports a number of authentication
and security mechanisms, among them Kerberos via the GSSAPI
mechanism.
TODO: More details need to be worked out ...
5. Architectural Considerations
The SNMP management framework has a well defined modular architecture
[RFC 3411] to allow the evolution of the SNMP protocol standards over
time. This architecture provides a Security Subsystem which is
responsible for realizing security services. Transport layer
security is by its very nature a security layer which is plugged in
between the transport layer and an application protocol. Hence, it
is important to describe how transport security fits into the SNMP
architecture.
5.1 An Architecture Extension for Transport Security Models
Transport security protocols will be called from the Transport
Mapping portion of an SNMP engine. This proposed architecture
extension is meant to serve as a template for others who wish to
connect transport security models to the SNMPv3 administrative
architecture.
The transport mapping provides only some aspects of security.
Transport mapping security may provide privacy and data integrity and
authentication and authorization policy retrievals, or some subset of
these features, but, as with USM, the messaging model includes a
security model which ties various security models for the same
principal to a securityName which can be used for subsequent
processing. These two separate security models will be referred to
here as a TM-security model and a MP-security model.
This document proposed a solution illustrated by the following
diagram, which is a modified version of the diagram taken from the
SNMP architecture document.
TODO: Insert drawing here...
The RFC3411 architecture has no ASI parameters for passing security
information between the transport mapping and the dispatcher, and
between the dispatcher and the message processing model. Since the
TM-security model and MP-security model are co-resident within an
implementation, it is assumed there is a trust relationship that
exists within the implementation. There are three approaches that
could be used for passing information between the TM-securitymodel
and the MP-security model.
Harrington & Schoenwaelder Expires April 19, 2005 [Page 5]
Internet-Draft SNMPv3 Transport Layer Security Model October 2004
RFC3411 discusses the purpose, and an explicit non-purpose, of the
ASI approach: "This modularity of specification is not meant to be
interpreted as imposing any specific requirements on implementation."
The ISMS WG should discuss which is the preferred approach to use in
the specification, although the ASI is not an API, and following the
ASI is not required for interoperability, so implementors are really
free to use any method they choose.
A cache mechanism could be used, in which the TM-security model puts
information about the security applied to an incoming message, and an
MP-security model extracts that information from the cache. The
cache is not passed in the ASI. Given that there may be multiple
TM-security caches, a cache-ID probably needs to be passed in the
message in the ASI so the MP-security model knows which cache to
consult. This approach would be consistent with the
securityStateReference cache already being passed around in the ASI.
The cache could be thought of as an additional parameter in the ASI.
The ASI would not need to be changed since the designers expected
that additional parameters could be passed for value-add features of
specific implementations.
Alternatively, a header could encapsulate the SNMP message to pass
necessary information from the TM-security model to the dispatcher
and then to the MP-security model. The message header would be
included in the wholeMessage ASI parameter, and would be removed by a
corresponding messaging model. This would imply a new messaging
model would need to be specified as well. The other approaches may
be able to use the standard SNMPv3 messaging model, with a new
MP-security model.
5.1.1 Cached Security Data
From RFC3411: "For each message received, the Security Model caches
the state information such that a Response message can be generated
using the same security information, even if the Local Configuration
Datastore is altered between the time of the incoming request and the
outgoing response.
A Message Processing Model has the responsibility for explicitly
releasing the cached data if such data is no longer needed. To
enable this, an abstract securityStateReference data element is
passed from the Security Model to the Message Processing Model. The
cached security data may be implicitly released via the generation of
a response, or explicitly released by using the stateRelease
primitive, as described in section 4.5.1."
The cache may need to contain the following information:
Harrington & Schoenwaelder Expires April 19, 2005 [Page 6]
Internet-Draft SNMPv3 Transport Layer Security Model October 2004
securityStateReference - a unique identifier for the saved
information
transportDomain
transportAddress
TM-securityModel - an indicator of which mechanisms were used
TM-securityName - a model-specific identifier of the security
principal
TM-securityLevel - an indicator of which security services were
provide by the transport security model
The following are determined by the Message Processing Model:
msgID,
contextEngineID
contextName
securityModel
securityName
securityLevel
reportableFlag
5.2 TLS Transport Security Model
DTLS has been proposed as a UDP-based TLS. In the following
discussion of the architectural requirements, the term TLS is used,
but DTLS is implied as well. Assuming TLS and DTLS provide
comparable security, the choice should have little impact on SNMP
architectural considerations.
TLS will create an association between the transport mapping of one
SNMP entity and the transport mapping of another SNMP entity. The
tunnel may provide encryption and data integrity. Both encryption
and data integrity are optional features in TLS. The TLS TM-security
model MUST specify that the TLS Handshake Protocol provide
authentication if auth is requested in the SecurityLevel of the SNMP
message request (RFC3412 4.1.1). The authentication SHOULD be mutual
authentication. The TLS TM-security model MUST specify that the
messages be encrypted if priv is requested in the SecurityLevel
parameter of the SNMP message request (RFC3412 4.1.1). More details
are provided below.
The transport mapping establishes the private tunnel without passing
anything to the SNMP dispatcher. After the tunnel is established,
then SNMP messages can be sent through the tunnel to the dispatcher.
SNMP messages sent through the tunnel are decrypted by the TLS
security model and presented unencrypted to the SNMP dispatcher.
Given this, flags in the SNMPv3 message header could be manipulated
by the TLS security model if necessary, but my tendency is to try to
leave these alone and favor wrapping the normal SNMPv3 message in a
Harrington & Schoenwaelder Expires April 19, 2005 [Page 7]
Internet-Draft SNMPv3 Transport Layer Security Model October 2004
transport-security-model header, thus requiring a new messaging model
document as well.
Once the tunnel is established, multiple SNMP messages can be passed
through the same tunnel.
5.2.1 TLS Cached Security Data
Upon establishment of a TLS/DTLS session, the TM-security model will
cache the state information. A securityStateReference that is unique
within the SNMP entity will be stored in the cache, and passed to the
corresponding MP-security model, to enable lookup. The MP security
model will pass the securityStateReference to the Message Processing
Model for memory management.
securityStateReference - a unique identifier for the saved
information
transportDomain
transportAddress.
TM-securityModel - an indicator of which mechanisms were used
TM-securityName - a model-specific identifier of the security
principal
TM-securityLevel - an indicator of which security services were
provided by the transport security model
For notifications, if the cache has been released and then session
closed, then the MP-security model will request the TM-security model
to establish a session, populate the cache, and pass the
securityStateReference to the MP-security model.
TODO: We need to determine what state needs to be saved here.
5.3 Message Processing Model for TLS Security
Messages should be handled identically to the RFC3412 procedures.
Are there any differences other than the MP-security model
processing?
ReportPDU should be identical, so discovery is the same.
a new security model enumeration is needed
Harrington & Schoenwaelder Expires April 19, 2005 [Page 8]
Internet-Draft SNMPv3 Transport Layer Security Model October 2004
5.4 MP Security Model for TLS Security
Document what comes from the state passed in from the TM-security
model.
Document how the mapping from model-specific principal to the
model-independent securityName is handled.
5.5 MIB Module for TLS Security
Each security model should use its own mib module, rather than
utilizing the USM MIB, to eliminate dependencies on a model that
could be replaced some day. See RFC3411 section 4.1.1.
The TLS mib module needs to provide the mapping from model-specific
identity to a model-independent securityName.
TODO: Module needs to be worked out once things become stable...
6. Acknowledgments
The authors would like to thank Ira McDonald, Ken Hornstein, Nagendra
Modadugu, <your name here> for their comments and suggestions.
7. References
7.1 Normative References
[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.
[RFC3417] Presuhn (Editor), R., "Transport Mappings for the Simple
Network Management Protocol (SNMP)", STD 62, RFC 3417,
December 2002.
[RFC3430] Schoenwaelder, J., "Simple Network Management Protocol
(SNMP) over Transmission Control Protocol (TCP) Transport
Mapping", RFC 3430, December 2002.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
Harrington & Schoenwaelder Expires April 19, 2005 [Page 9]
Internet-Draft SNMPv3 Transport Layer Security Model October 2004
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
[RFC2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", STD 62, RFC RFC2222, October 1997.
[DTLS] Rescola, E. and N. Modadugu, "Datagram Transport Layer
Security", ID draft-rescorla-dtls-01.txt, July 2004.
7.2 Informative References
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for
Internet-Standard Management Framework", RFC 3410,
December 2002.
[RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712,
October 1999.
[SRP-TLS] Taylor, D., Wu, T., Mavroyanopoulos, M. and T. Perrin,
"Using SRP for TLS Authentication", ID
draft-ietf-tls-srp-08.txt, August 2004.
Authors' Addresses
David Harrington
Independent
Harding Rd
Portsmouth NH
USA
Phone: +1 603 436 8634
EMail: dbharrington@comcast.net
Juergen Schoenwaelder
International University Bremen
Campus Ring 1
28725 Bremen
Germany
Phone: +49 421 200-3587
EMail: j.schoenwaelder@iu-bremen.de
Harrington & Schoenwaelder Expires April 19, 2005 [Page 10]
Internet-Draft SNMPv3 Transport Layer Security Model October 2004
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 (2004). 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.
Harrington & Schoenwaelder Expires April 19, 2005 [Page 11]