< draft-ietf-isms-dtls-tm-11.txt   draft-ietf-isms-dtls-tm-12.txt >
ISMS W. Hardaker ISMS W. Hardaker
Internet-Draft Sparta, Inc. Internet-Draft Sparta, Inc.
Intended status: Standards Track May 4, 2010 Intended status: Standards Track May 6, 2010
Expires: November 5, 2010 Expires: November 7, 2010
Transport Layer Security (TLS) Transport Model for the Simple Network Transport Layer Security (TLS) Transport Model for the Simple Network
Management Protocol (SNMP) Management Protocol (SNMP)
draft-ietf-isms-dtls-tm-11.txt draft-ietf-isms-dtls-tm-12.txt
Abstract Abstract
This document describes a Transport Model for the Simple Network This document describes a Transport Model for the Simple Network
Management Protocol (SNMP), that uses either the Transport Layer Management Protocol (SNMP), that uses either the Transport Layer
Security protocol or the Datagram Transport Layer Security (DTLS) Security protocol or the Datagram Transport Layer Security (DTLS)
protocol. The TLS and DTLS protocols provide authentication and protocol. The TLS and DTLS protocols provide authentication and
privacy services for SNMP applications. This document describes how privacy services for SNMP applications. This document describes how
the TLS Transport Model (TLSTM) implements the needed features of a the TLS Transport Model (TLSTM) implements the needed features of a
SNMP Transport Subsystem to make this protection possible in an SNMP Transport Subsystem to make this protection possible in an
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 5, 2010. This Internet-Draft will expire on November 7, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 22 skipping to change at page 3, line 22
3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2. Message Protection . . . . . . . . . . . . . . . . . . 12 3.1.2. Message Protection . . . . . . . . . . . . . . . . . . 12
3.1.3. (D)TLS Connections . . . . . . . . . . . . . . . . . . 13 3.1.3. (D)TLS Connections . . . . . . . . . . . . . . . . . . 13
3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 14 3.2. Security Parameter Passing . . . . . . . . . . . . . . . . 14
3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 14 3.3. Notifications and Proxy . . . . . . . . . . . . . . . . . 14
4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 15 4. Elements of the Model . . . . . . . . . . . . . . . . . . . . 15
4.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 15 4.1. X.509 Certificates . . . . . . . . . . . . . . . . . . . . 15
4.1.1. Provisioning for the Certificate . . . . . . . . . . . 15 4.1.1. Provisioning for the Certificate . . . . . . . . . . . 15
4.2. (D)TLS Usage . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. (D)TLS Usage . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 17 4.3. SNMP Services . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1. SNMP Services for an Outgoing Message . . . . . . . . 17 4.3.1. SNMP Services for an Outgoing Message . . . . . . . . 18
4.3.2. SNMP Services for an Incoming Message . . . . . . . . 18 4.3.2. SNMP Services for an Incoming Message . . . . . . . . 19
4.4. Cached Information and References . . . . . . . . . . . . 19 4.4. Cached Information and References . . . . . . . . . . . . 19
4.4.1. TLS Transport Model Cached Information . . . . . . . . 19 4.4.1. TLS Transport Model Cached Information . . . . . . . . 20
4.4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . 20 4.4.1.1. tmSecurityName . . . . . . . . . . . . . . . . . . 20
4.4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . 20 4.4.1.2. tmSessionID . . . . . . . . . . . . . . . . . . . 20
4.4.1.3. Session State . . . . . . . . . . . . . . . . . . 20 4.4.1.3. Session State . . . . . . . . . . . . . . . . . . 20
5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 20 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 21
5.1. Procedures for an Incoming Message . . . . . . . . . . . . 21 5.1. Procedures for an Incoming Message . . . . . . . . . . . . 21
5.1.1. DTLS over UDP Processing for Incoming Messages . . . . 21 5.1.1. DTLS over UDP Processing for Incoming Messages . . . . 21
5.1.2. Transport Processing for Incoming SNMP Messages . . . 23 5.1.2. Transport Processing for Incoming SNMP Messages . . . 23
5.2. Procedures for an Outgoing SNMP Message . . . . . . . . . 24 5.2. Procedures for an Outgoing SNMP Message . . . . . . . . . 24
5.3. Establishing or Accepting a Session . . . . . . . . . . . 26 5.3. Establishing or Accepting a Session . . . . . . . . . . . 26
5.3.1. Establishing a Session as a Client . . . . . . . . . . 26 5.3.1. Establishing a Session as a Client . . . . . . . . . . 26
5.3.2. Accepting a Session as a Server . . . . . . . . . . . 28 5.3.2. Accepting a Session as a Server . . . . . . . . . . . 28
5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 29 5.4. Closing a Session . . . . . . . . . . . . . . . . . . . . 29
6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 29 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 29
6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 30 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 30
skipping to change at page 3, line 51 skipping to change at page 3, line 51
6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 30 6.3. Statistical Counters . . . . . . . . . . . . . . . . . . . 30
6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 30 6.4. Configuration Tables . . . . . . . . . . . . . . . . . . . 30
6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 30 6.4.1. Notifications . . . . . . . . . . . . . . . . . . . . 30
6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 30 6.5. Relationship to Other MIB Modules . . . . . . . . . . . . 30
6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 31 6.5.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 31
7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 31 7. MIB Module Definition . . . . . . . . . . . . . . . . . . . . 31
8. Operational Considerations . . . . . . . . . . . . . . . . . . 53 8. Operational Considerations . . . . . . . . . . . . . . . . . . 53
8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 53 8.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.2. Notification Receiver Credential Selection . . . . . . . . 54 8.2. Notification Receiver Credential Selection . . . . . . . . 54
8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 54 8.3. contextEngineID Discovery . . . . . . . . . . . . . . . . 54
8.4. Transport Considerations . . . . . . . . . . . . . . . . . 54 8.4. Transport Considerations . . . . . . . . . . . . . . . . . 55
8.5. IPv6 and securityName mapping when used with TSM and
VACM . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9. Security Considerations . . . . . . . . . . . . . . . . . . . 55 9. Security Considerations . . . . . . . . . . . . . . . . . . . 55
9.1. Certificates, Authentication, and Authorization . . . . . 55 9.1. Certificates, Authentication, and Authorization . . . . . 55
9.2. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 56 9.2. (D)TLS Security Considerations . . . . . . . . . . . . . . 56
9.3. MIB Module Security . . . . . . . . . . . . . . . . . . . 57 9.2.1. TLS Version Requirements . . . . . . . . . . . . . . . 56
9.2.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . 56
9.3. Use with SNMPv1/SNMPv2c Messages . . . . . . . . . . . . . 56
9.4. MIB Module Security . . . . . . . . . . . . . . . . . . . 57
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
12.1. Normative References . . . . . . . . . . . . . . . . . . . 60 12.1. Normative References . . . . . . . . . . . . . . . . . . . 60
12.2. Informative References . . . . . . . . . . . . . . . . . . 61 12.2. Informative References . . . . . . . . . . . . . . . . . . 61
Appendix A. Target and Notification Configuration Example . . . . 62 Appendix A. Target and Notification Configuration Example . . . . 62
A.1. Configuring a Notification Originator . . . . . . . . . . 62 A.1. Configuring a Notification Originator . . . . . . . . . . 62
A.2. Configuring TLSTM to Utilize a Simple Derivation of A.2. Configuring TLSTM to Utilize a Simple Derivation of
tmSecurityName . . . . . . . . . . . . . . . . . . . . . . 63 tmSecurityName . . . . . . . . . . . . . . . . . . . . . . 63
A.3. Configuring TLSTM to Utilize Table-Driven Certificate A.3. Configuring TLSTM to Utilize Table-Driven Certificate
skipping to change at page 16, line 38 skipping to change at page 16, line 38
An example of this type of mapping setup can be found in Appendix A. An example of this type of mapping setup can be found in Appendix A.
This tmSecurityName may be later translated from a TLSTM specific This tmSecurityName may be later translated from a TLSTM specific
tmSecurityName to a SNMP engine securityName by the security model. tmSecurityName to a SNMP engine securityName by the security model.
A security model, like the TSM security model [RFC5591], may perform A security model, like the TSM security model [RFC5591], may perform
an identity mapping or a more complex mapping to derive the an identity mapping or a more complex mapping to derive the
securityName from the tmSecurityName offered by the TLS Transport securityName from the tmSecurityName offered by the TLS Transport
Model. Model.
The standard VACM access control model constrains securityNames to be
32 octets or less in length. A TLSTM generated tmSecurityName,
possibly in combination with a messaging or security model that
increases the length of the securityName, might cause the
securityName length to exceed 32 octets. For example, a 32 octet
tmSecurityName derived from an IPv6 address, paired with a TSM
prefix, will generate a 36 octet securityName. Such a securityName
will not be able to be used with standard VACM or TARGET MIB modules.
Operators should be careful to select algorithms and subjectAltNames
to avoid this situation.
A pictorial view of the complete transformation process (using the A pictorial view of the complete transformation process (using the
TSM security model for the example) is shown below: TSM security model for the example) is shown below:
+-------------+ +-------+ +-----+ +-------------+ +-------+ +-----+
| Certificate | | | | | | Certificate | | | | |
| Path | | TLSTM | tmSecurityName | TSM | | Path | | TLSTM | tmSecurityName | TSM |
| Validation | --> | | ----------------->| | | Validation | --> | | ----------------->| |
+-------------+ +-------+ +-----+ +-------------+ +-------+ +-----+
| |
| securityName | securityName
skipping to change at page 20, line 22 skipping to change at page 20, line 29
a different tmSecurityName. a different tmSecurityName.
On the (D)TLS server side of a connection the tmSecurityName is On the (D)TLS server side of a connection the tmSecurityName is
derived using the procedures described in Section 5.3.2 and the SNMP- derived using the procedures described in Section 5.3.2 and the SNMP-
TLS-TM-MIB's snmpTlstmCertToTSNTable DESCRIPTION clause. TLS-TM-MIB's snmpTlstmCertToTSNTable DESCRIPTION clause.
On the (D)TLS client side of a connection the tmSecurityName is On the (D)TLS client side of a connection the tmSecurityName is
presented to the TLS Transport Model by the application (possibly presented to the TLS Transport Model by the application (possibly
because of configuration specified in the SNMP-TARGET-MIB). because of configuration specified in the SNMP-TARGET-MIB).
The securityName MAY be derived from the tmSecurityName by a Security Transport-model-aware security models derive tmSecurityName from a
Model and MAY be used to configure notifications and access controls securityName, possibly configured in MIB modules for notifications
in MIB modules. Transport Models SHOULD generate a predictable and access controls. Transport Models SHOULD use predictable
tmSecurityName so operators will know what to use when configuring tmSecurityNames so operators will know what to use when configuring
MIB modules that use securityNames derived from tmSecurityNames. The MIB modules that use securityNames derived from tmSecurityNames. The
TLSTM generates predictable tmSecurityNames based on the TLSTM generates predictable tmSecurityNames based on the
configuration found in the SNMP-TLS-TM-MIB's snmpTlstmCertToTSNTable configuration found in the SNMP-TLS-TM-MIB's snmpTlstmCertToTSNTable
and relies on the network operators to have configured this table and relies on the network operators to have configured this table
appropriately. appropriately.
4.4.1.2. tmSessionID 4.4.1.2. tmSessionID
The tmSessionID MUST be recorded per message at the time of receipt. The tmSessionID MUST be recorded per message at the time of receipt.
When tmSameSecurity is set, the recorded tmSessionID can be used to When tmSameSecurity is set, the recorded tmSessionID can be used to
skipping to change at page 30, line 30 skipping to change at page 30, line 30
addressing requirements. addressing requirements.
o A certificate fingerprint allowing MIB module objects to o A certificate fingerprint allowing MIB module objects to
generically refer to a stored X.509 certificate using a generically refer to a stored X.509 certificate using a
cryptographic hash as a reference pointer. cryptographic hash as a reference pointer.
6.3. Statistical Counters 6.3. Statistical Counters
The SNMP-TLS-TM-MIB defines counters that provide network management The SNMP-TLS-TM-MIB defines counters that provide network management
stations with information about session usage and potential errors stations with information about session usage and potential errors
that a MIB-instrumented device may be experiencing. that a device may be experiencing.
6.4. Configuration Tables 6.4. Configuration Tables
The SNMP-TLS-TM-MIB defines configuration tables that an The SNMP-TLS-TM-MIB defines configuration tables that an
administrator can use for configuring a MIB-instrumented device for administrator can use for configuring a device for sending and
sending and receiving SNMP messages over (D)TLS. In particular, receiving SNMP messages over (D)TLS. In particular, there are MIB
there are MIB tables that extend the SNMP-TARGET-MIB for configuring tables that extend the SNMP-TARGET-MIB for configuring (D)TLS
(D)TLS certificate usage and a MIB table for mapping incoming (D)TLS certificate usage and a MIB table for mapping incoming (D)TLS client
client certificates to SNMPv3 securityNames. certificates to SNMPv3 securityNames.
6.4.1. Notifications 6.4.1. Notifications
The SNMP-TLS-TM-MIB defines notifications to alert management The SNMP-TLS-TM-MIB defines notifications to alert management
stations when a (D)TLS connection fails because a server's presented stations when a (D)TLS connection fails because a server's presented
certificate did not meet an expected value certificate did not meet an expected value
(snmpTlstmServerCertificateUnknown) or because cryptographic (snmpTlstmServerCertificateUnknown) or because cryptographic
validation failed (snmpTlstmServerInvalidCertificate). validation failed (snmpTlstmServerInvalidCertificate).
6.5. Relationship to Other MIB Modules 6.5. Relationship to Other MIB Modules
skipping to change at page 31, line 26 skipping to change at page 31, line 26
[RFC3413] and SNMPv2-CONF [RFC2580]. [RFC3413] and SNMPv2-CONF [RFC2580].
7. MIB Module Definition 7. MIB Module Definition
SNMP-TLS-TM-MIB DEFINITIONS ::= BEGIN SNMP-TLS-TM-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, MODULE-IDENTITY, OBJECT-TYPE,
OBJECT-IDENTITY, mib-2, snmpDomains, OBJECT-IDENTITY, mib-2, snmpDomains,
Counter32, Unsigned32, Gauge32, NOTIFICATION-TYPE Counter32, Unsigned32, Gauge32, NOTIFICATION-TYPE
FROM SNMPv2-SMI FROM SNMPv2-SMI -- RFC2578 or any update thereof
TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType, TEXTUAL-CONVENTION, TimeStamp, RowStatus, StorageType,
AutonomousType AutonomousType
FROM SNMPv2-TC FROM SNMPv2-TC -- RFC2579 or any update thereof
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF FROM SNMPv2-CONF -- RFC2580 or any update thereof
SnmpAdminString SnmpAdminString
FROM SNMP-FRAMEWORK-MIB FROM SNMP-FRAMEWORK-MIB -- RFC3411 or any update thereof
snmpTargetParamsName, snmpTargetAddrName snmpTargetParamsName, snmpTargetAddrName
FROM SNMP-TARGET-MIB FROM SNMP-TARGET-MIB -- RFC3413 or any update thereof
; ;
snmpTlstmMIB MODULE-IDENTITY snmpTlstmMIB MODULE-IDENTITY
LAST-UPDATED "201005040000Z" LAST-UPDATED "201005060000Z"
ORGANIZATION "ISMS Working Group" ORGANIZATION "ISMS Working Group"
CONTACT-INFO "WG-EMail: isms@lists.ietf.org CONTACT-INFO "WG-EMail: isms@lists.ietf.org
Subscribe: isms-request@lists.ietf.org Subscribe: isms-request@lists.ietf.org
Chairs: Chairs:
Juergen Schoenwaelder Juergen Schoenwaelder
Jacobs University Bremen Jacobs University Bremen
Campus Ring 1 Campus Ring 1
28725 Bremen 28725 Bremen
Germany Germany
skipping to change at page 32, line 35 skipping to change at page 32, line 35
Copyright (c) 2010 IETF Trust and the persons identified as Copyright (c) 2010 IETF Trust and the persons identified as
the document authors. All rights reserved. the document authors. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info)." (http://trustee.ietf.org/license-info)."
REVISION "201005040000Z" REVISION "201005060000Z"
DESCRIPTION "This version of this MIB module is part of DESCRIPTION "This version of this MIB module is part of
RFC XXXX; see the RFC itself for full legal RFC XXXX; see the RFC itself for full legal
notices." notices."
-- NOTE to RFC editor: replace XXXX with actual RFC number -- NOTE to RFC editor: replace XXXX with actual RFC number
-- for this document and change the date to the -- for this document and change the date to the
-- current date and remove this note -- current date and remove this note
::= { mib-2 www } ::= { mib-2 www }
-- RFC Ed.: replace www with IANA-assigned number under the mib-2 -- RFC Ed.: replace www with IANA-assigned number under the mib-2
skipping to change at page 35, line 23 skipping to change at page 35, line 23
DESCRIPTION clause or in the surrounding documentation." DESCRIPTION clause or in the surrounding documentation."
REFERENCE REFERENCE
"RFC 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE "RFC 1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE
RFC 3490: Internationalizing Domain Names in Applications RFC 3490: Internationalizing Domain Names in Applications
I-D.ietf-6man-text-addr-representation: I-D.ietf-6man-text-addr-representation:
A Recommendation for IPv6 Address Text Representation A Recommendation for IPv6 Address Text Representation
" "
SYNTAX OCTET STRING (SIZE (1..255)) SYNTAX OCTET STRING (SIZE (1..255))
-- RFC Editor: if I-D.ietf-6man-text-addr-representation fails to get -- RFC Editor: if I-D.ietf-6man-text-addr-representation fails to get
-- published then replace the reference to
-- I-D.ietf-6man-text-addr-representation with a reference to
-- "RFC3513: Internet Protocol Version 6 (IPv6) Addressing Architecture"
-- instead.
SnmpTLSFingerprint ::= TEXTUAL-CONVENTION SnmpTLSFingerprint ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1x:254x" DISPLAY-HINT "1x:254x"
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A fingerprint value that can be used to uniquely reference "A fingerprint value that can be used to uniquely reference
other data of potentially arbitrary length. other data of potentially arbitrary length.
A SnmpTLSFingerprint value is composed of a 1-octet hashing A SnmpTLSFingerprint value is composed of a 1-octet hashing
algorithm identifier followed by the fingerprint value. The algorithm identifier followed by the fingerprint value. The
octet value encoded is taken from the IANA TLS HashAlgorithm octet value encoded is taken from the IANA TLS HashAlgorithm
Registry (RFC5246). The remaining octets are filled using the Registry (RFC5246). The remaining octets are filled using the
results of the hashing algorithm. results of the hashing algorithm.
This TEXTUAL-CONVENTION allows for a zero-length (blank) This TEXTUAL-CONVENTION allows for a zero-length (blank)
SnmpTLSFingerprint value for use in tables where the SnmpTLSFingerprint value for use in tables where the
fingerprint value may be optional. MIB definitions or fingerprint value may be optional. MIB definitions or
implementations may refuse to accept a zero-length value as implementations may refuse to accept a zero-length value as
appropriate." REFERENCE "RFC 5246: The Transport Layer appropriate."
Security (TLS) Protocol Version 1.2 REFERENCE "RFC 5246: The Transport Layer
http://www.iana.org/assignments/tls-parameters/ " SYNTAX OCTET Security (TLS) Protocol Version 1.2
STRING (SIZE (0..255)) http://www.iana.org/assignments/tls-parameters/
"
SYNTAX OCTET STRING (SIZE (0..255))
-- Identities for use in the snmpTlstmCertToTSNTable -- Identities for use in the snmpTlstmCertToTSNTable
snmpTlstmCertToTSNMIdentities OBJECT IDENTIFIER snmpTlstmCertToTSNMIdentities OBJECT IDENTIFIER
::= { snmpTlstmIdentities 1 } ::= { snmpTlstmIdentities 1 }
snmpTlstmCertSpecified OBJECT-IDENTITY snmpTlstmCertSpecified OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION "Directly specifies the tmSecurityName to be used for DESCRIPTION "Directly specifies the tmSecurityName to be used for
this certificate. The value of the tmSecurityName this certificate. The value of the tmSecurityName
to use is specified in the snmpTlstmCertToTSNData to use is specified in the snmpTlstmCertToTSNData
column. The snmpTlstmCertToTSNData column must column. The snmpTlstmCertToTSNData column must
contain a non-zero length SnmpAdminString compliant contain a non-zero length SnmpAdminString compliant
skipping to change at page 36, line 31 skipping to change at page 36, line 33
be passed in lower case. be passed in lower case.
Example rfc822Name Field: FooBar@Example.COM Example rfc822Name Field: FooBar@Example.COM
is mapped to tmSecurityName: FooBar@example.com" is mapped to tmSecurityName: FooBar@example.com"
::= { snmpTlstmCertToTSNMIdentities 2 } ::= { snmpTlstmCertToTSNMIdentities 2 }
snmpTlstmCertSANDNSName OBJECT-IDENTITY snmpTlstmCertSANDNSName OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION "Maps a subjectAltName's dNSName to a DESCRIPTION "Maps a subjectAltName's dNSName to a
tmSecurityName after first converting it to all tmSecurityName after first converting it to all
lower case." lower case (note that RFC5280 does not specify
converting to lower case so this involves an extra
step)."
REFERENCE "RFC5280 - Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation
List (CRL) Profile"
::= { snmpTlstmCertToTSNMIdentities 3 } ::= { snmpTlstmCertToTSNMIdentities 3 }
snmpTlstmCertSANIpAddress OBJECT-IDENTITY snmpTlstmCertSANIpAddress OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION "Maps a subjectAltName's iPAddress to a DESCRIPTION "Maps a subjectAltName's iPAddress to a
tmSecurityName by transforming the binary encoded tmSecurityName by transforming the binary encoded
address as follows: address as follows:
1) for IPv4 the value is converted into a decimal 1) for IPv4 the value is converted into a decimal
dotted quad address (e.g. '192.0.2.1') dotted quad address (e.g. '192.0.2.1')
skipping to change at page 37, line 33 skipping to change at page 37, line 41
certificate of the above types MUST be used when certificate of the above types MUST be used when
deriving the tmSecurityName. The mapping algorithm deriving the tmSecurityName. The mapping algorithm
specified in the 'Algorithm' column MUST be used to specified in the 'Algorithm' column MUST be used to
derive the tmSecurityName." derive the tmSecurityName."
::= { snmpTlstmCertToTSNMIdentities 5 } ::= { snmpTlstmCertToTSNMIdentities 5 }
snmpTlstmCertCommonName OBJECT-IDENTITY snmpTlstmCertCommonName OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION "Maps a certificate's CommonName to a tmSecurityName DESCRIPTION "Maps a certificate's CommonName to a tmSecurityName
after converting it to a UTF-8 encoding." after converting it to a UTF-8 encoding. The usage
of CommonNames is deprecated and users are
encouraged to use subjectAltName mapping methods
instead."
::= { snmpTlstmCertToTSNMIdentities 6 } ::= { snmpTlstmCertToTSNMIdentities 6 }
-- The snmpTlstmSession Group -- The snmpTlstmSession Group
snmpTlstmSession OBJECT IDENTIFIER ::= { snmpTlstmObjects 1 } snmpTlstmSession OBJECT IDENTIFIER ::= { snmpTlstmObjects 1 }
snmpTlstmSessionOpens OBJECT-TYPE snmpTlstmSessionOpens OBJECT-TYPE
SYNTAX Counter32 SYNTAX Counter32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
skipping to change at page 48, line 5 skipping to change at page 48, line 16
If the server's presented certificate has passed If the server's presented certificate has passed
certification path validation [RFC5280] to a configured certification path validation [RFC5280] to a configured
trust anchor, and an active row exists with a zero-length trust anchor, and an active row exists with a zero-length
snmpTlstmAddrServerFingerprint value, then the snmpTlstmAddrServerFingerprint value, then the
snmpTlstmAddrServerIdentity column contains the expected snmpTlstmAddrServerIdentity column contains the expected
host name. This expected host name is then compared against host name. This expected host name is then compared against
the server's certificate as follows: the server's certificate as follows:
- Implementations MUST support matching the expected host - Implementations MUST support matching the expected host
name against a dNSName in the subjectAltName extension name against a dNSName in the subjectAltName extension
field and SHOULD support checking the name against the field and MAY support checking the name against the
common name portion of the subject distinguished name. CommonName portion of the subject distinguished name.
- The '*' (ASCII 0x2a) wildcard character is allowed in the - The '*' (ASCII 0x2a) wildcard character is allowed in the
dNSName of the subjectAltName extension (and in common dNSName of the subjectAltName extension (and in common
name, if used to store the host name), but only as the name, if used to store the host name), but only as the
left-most (least significant) DNS label in that value. left-most (least significant) DNS label in that value.
This wildcard matches any left-most DNS label in the This wildcard matches any left-most DNS label in the
server name. That is, the subject *.example.com matches server name. That is, the subject *.example.com matches
the server names a.example.com and b.example.com, but does the server names a.example.com and b.example.com, but does
not match example.com or a.b.example.com. Implementations not match example.com or a.b.example.com. Implementations
MUST support wildcards in certificates as specified above, MUST support wildcards in certificates as specified above,
skipping to change at page 55, line 5 skipping to change at page 55, line 18
TLS and DTLS based protocols. Each of these protocols are TLS and DTLS based protocols. Each of these protocols are
additionally based on other transports (TCP and UDP). These two base additionally based on other transports (TCP and UDP). These two base
protocols also have operational considerations that must be taken protocols also have operational considerations that must be taken
into consideration when selecting a (D)TLS based protocol to use such into consideration when selecting a (D)TLS based protocol to use such
as its performance in degraded or limited networks. It is beyond the as its performance in degraded or limited networks. It is beyond the
scope of this document to summarize the characteristics of these scope of this document to summarize the characteristics of these
transport mechanisms. Please refer to the base protocol documents transport mechanisms. Please refer to the base protocol documents
for details on messaging considerations with respect to MTU size, for details on messaging considerations with respect to MTU size,
fragmentation, performance in lossy-networks, etc. fragmentation, performance in lossy-networks, etc.
8.5. IPv6 and securityName mapping when used with TSM and VACM
It is possible to create a condition where it is impossible to map a
subjectAltName to a securityName when all of the following conditions
are true:
o The snmpTlstmCertToTSNMapType object of a snmpTlstmCertToTSNEntry
is set to the snmpTlstmCertSANIpAddress identity value.
o The X.509 certificate presented by the client contains a
subjectAltName with an IPv6 address in it.
o The security model in use is the Transport Security Model.
o The snmpTsmConfigurationUsePrefix object in the SNMP-TSM-MIB is
set to 'true'.
o The View-based Access Control Model is being used to authorize
requests.
If all of these conditions are true then the length of the generated
tmSecurityName will always be 32 octet characters and the
securityName generated by the TSM will be at least 36, which is
longer than the length allowed by the VACM.
Thus, the use of IPv6 subjectAltName to tmSecurityName mapping is NOT
RECOMMENDED when snmpTsmConfigurationUsePrefix is set to true.
9. Security Considerations 9. Security Considerations
This document describes a transport model that permits SNMP to This document describes a transport model that permits SNMP to
utilize (D)TLS security services. The security threats and how the utilize (D)TLS security services. The security threats and how the
(D)TLS transport model mitigates these threats are covered in detail (D)TLS transport model mitigates these threats are covered in detail
throughout this document. Security considerations for DTLS are throughout this document. Security considerations for DTLS are
covered in [RFC4347] and security considerations for TLS are covered in [RFC4347] and security considerations for TLS are
described in Section 11 and Appendices D, E, and F of TLS 1.2 described in Section 11 and Appendices D, E, and F of TLS 1.2
[RFC5246]. When run over a connectionless transport such as UDP, [RFC5246]. When run over a connectionless transport such as UDP,
DTLS is more vulnerable to denial of service attacks from spoofed IP DTLS is more vulnerable to denial of service attacks from spoofed IP
skipping to change at page 56, line 42 skipping to change at page 56, line 26
Authenticating and verifying the identity of the (D)TLS server and Authenticating and verifying the identity of the (D)TLS server and
the (D)TLS client for all operations ensures the authenticity of the the (D)TLS client for all operations ensures the authenticity of the
SNMP engine that provides MIB data. SNMP engine that provides MIB data.
The instructions found in the DESCRIPTION clause of the The instructions found in the DESCRIPTION clause of the
snmpTlstmCertToTSNTable object must be followed exactly. It is also snmpTlstmCertToTSNTable object must be followed exactly. It is also
important that the rows of the table be searched in prioritized order important that the rows of the table be searched in prioritized order
starting with the row containing the lowest numbered starting with the row containing the lowest numbered
snmpTlstmCertToTSNID value. snmpTlstmCertToTSNID value.
9.2. Use with SNMPv1/SNMPv2c Messages 9.2. (D)TLS Security Considerations
This section discusses security considerations specific to the usage
of (D)TLS.
9.2.1. TLS Version Requirements
Implementations of TLS typically support multiple versions of the
Transport Layer Security protocol as well as the older Secure Sockets
Layer (SSL) protocol. Because of known security vulnerabilities,
TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0.
See Appendix E.2 of [RFC5246] for further details.
9.2.2. Perfect Forward Secrecy
The use of Perfect Forward Secrecy is RECOMMENDED and can be provided
by (D)TLS with appropriately selected cipher suites, as discussed in
Appendix F of [RFC5246].
9.3. Use with SNMPv1/SNMPv2c Messages
The SNMPv1 and SNMPv2c message processing described in [RFC3584] (BCP The SNMPv1 and SNMPv2c message processing described in [RFC3584] (BCP
74) always selects the SNMPv1 or SNMPv2c Security Models, 74) always selects the SNMPv1 or SNMPv2c Security Models,
respectively. Both of these and the User-based Security Model respectively. Both of these and the User-based Security Model
typically used with SNMPv3 derive the securityName and securityLevel typically used with SNMPv3 derive the securityName and securityLevel
from the SNMP message received, even when the message was received from the SNMP message received, even when the message was received
over a secure transport. Access control decisions are therefore made over a secure transport. Access control decisions are therefore made
based on the contents of the SNMP message, rather than using the based on the contents of the SNMP message, rather than using the
authenticated identity and securityLevel provided by the TLS authenticated identity and securityLevel provided by the TLS
Transport Model. It is RECOMMENDED that only SNMPv3 messages using Transport Model. It is RECOMMENDED that only SNMPv3 messages using
the Transport Security Model (TSM) or another secure-transport aware the Transport Security Model (TSM) or another secure-transport aware
security model be sent over the TLSTM transport. security model be sent over the TLSTM transport.
Using a non-transport-aware Security Model with a secure Transport Using a non-transport-aware Security Model with a secure Transport
Model is NOT RECOMMENDED. See [RFC5590] Section 7.1 for additional Model is NOT RECOMMENDED. See [RFC5590] Section 7.1 for additional
details on the coexistence of security-aware transports and non- details on the coexistence of security-aware transports and non-
transport-aware security models. transport-aware security models.
9.3. MIB Module Security 9.4. MIB Module Security
There are a number of management objects defined in this MIB module There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on environment without proper protection can have a negative effect on
network operations. These are the tables and objects and their network operations. These are the tables and objects and their
sensitivity/vulnerability: sensitivity/vulnerability:
o The snmpTlstmParamsTable can be used to change the outgoing X.509 o The snmpTlstmParamsTable can be used to change the outgoing X.509
skipping to change at page 63, line 19 skipping to change at page 63, line 25
snmpTargetParamsSecurityModel = 4 (TransportSecurityModel) snmpTargetParamsSecurityModel = 4 (TransportSecurityModel)
snmpTargetParamsSecurityName = "Joe Cool" snmpTargetParamsSecurityName = "Joe Cool"
snmpTargetParamsSecurityLevel = 3 (authPriv) snmpTargetParamsSecurityLevel = 3 (authPriv)
snmpTargetParamsStorageType = 3 (nonVolatile) snmpTargetParamsStorageType = 3 (nonVolatile)
snmpTargetParamsRowStatus = 4 (createAndGo0 snmpTargetParamsRowStatus = 4 (createAndGo0
A.2. Configuring TLSTM to Utilize a Simple Derivation of tmSecurityName A.2. Configuring TLSTM to Utilize a Simple Derivation of tmSecurityName
The following row configures the snmpTlstmCertToTSNTable to map a The following row configures the snmpTlstmCertToTSNTable to map a
validated client certificate, referenced by the client's public X.509 validated client certificate, referenced by the client's public X.509
hash fingerprint, to a tmSecurityName using the subjecwAltName hash fingerprint, to a tmSecurityName using the subjectAltName
component of the certificate. component of the certificate.
snmpTlstmCertToTSNID = 1 snmpTlstmCertToTSNID = 1
(chosen by ordering preference) (chosen by ordering preference)
snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint) snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint)
snmpTlstmCertToTSNMapType = snmpTlstmCertSANAny snmpTlstmCertToTSNMapType = snmpTlstmCertSANAny
snmpTlstmCertToTSNData = "" (not used) snmpTlstmCertToTSNData = "" (not used)
snmpTlstmCertToTSNStorageType = 3 (nonVolatile) snmpTlstmCertToTSNStorageType = 3 (nonVolatile)
snmpTlstmCertToTSNRowStatus = 4 (createAndGo) snmpTlstmCertToTSNRowStatus = 4 (createAndGo)
This type of configuration should only be used when the naming This type of configuration should only be used when the naming
conventions of the (possibly multiple) certificate authorities are conventions of the (possibly multiple) certificate authorities are
well understood, so two different principals cannot inadvertently be well understood, so two different principals cannot inadvertently be
identified by the same derived tmSecurityName.. identified by the same derived tmSecurityName.
A.3. Configuring TLSTM to Utilize Table-Driven Certificate Mapping A.3. Configuring TLSTM to Utilize Table-Driven Certificate Mapping
The following row configures the snmpTlstmCertToTSNTable to map a The following row configures the snmpTlstmCertToTSNTable to map a
validated client certificate, referenced by the client's public X.509 validated client certificate, referenced by the client's public X.509
hash fingerprint, to the directly specified tmSecurityName of "Joe hash fingerprint, to the directly specified tmSecurityName of "Joe
Cool". Cool".
snmpTlstmCertToTSNID = 1 snmpTlstmCertToTSNID = 1
(chosen by ordering preference) (chosen by ordering preference)
 End of changes. 30 change blocks. 
71 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/