< draft-ietf-isms-transport-security-model-13.txt   draft-ietf-isms-transport-security-model-14.txt >
Network Working Group D. Harrington Network Working Group D. Harrington
Internet-Draft Huawei Technologies (USA) Internet-Draft Huawei Technologies (USA)
Intended status: Standards Track W. Hardaker Intended status: Standards Track W. Hardaker
Expires: October 29, 2009 Sparta, Inc. Expires: November 7, 2009 Sparta, Inc.
April 27, 2009 May 6, 2009
Transport Security Model for SNMP Transport Security Model for SNMP
draft-ietf-isms-transport-security-model-13 draft-ietf-isms-transport-security-model-14
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 October 29, 2009. This Internet-Draft will expire on November 7, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 20 skipping to change at page 3, line 20
1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 6
2. How the Transport Security Model Fits in the Architecture . . 6 2. How the Transport Security Model Fits in the Architecture . . 6
2.1. Security Capabilities of this Model . . . . . . . . . . . 7 2.1. Security Capabilities of this Model . . . . . . . . . . . 7
2.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.1. Threats . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2. Security Levels . . . . . . . . . . . . . . . . . . . 7 2.1.2. Security Levels . . . . . . . . . . . . . . . . . . . 7
2.2. Transport Sessions . . . . . . . . . . . . . . . . . . . . 8 2.2. Transport Sessions . . . . . . . . . . . . . . . . . . . . 8
2.3. Coexistence . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Coexistence . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1. Coexistence with Message Processing Models . . . . . . 8 2.3.1. Coexistence with Message Processing Models . . . . . . 8
2.3.2. Coexistence with Other Security Models . . . . . . . . 8 2.3.2. Coexistence with Other Security Models . . . . . . . . 9
2.3.3. Coexistence with Transport Models . . . . . . . . . . 9 2.3.3. Coexistence with Transport Models . . . . . . . . . . 9
3. Cached Information and References . . . . . . . . . . . . . . 9 3. Cached Information and References . . . . . . . . . . . . . . 9
3.1. Transport Security Model Cached Information . . . . . . . 9 3.1. Transport Security Model Cached Information . . . . . . . 9
3.1.1. securityStateReference . . . . . . . . . . . . . . . . 9 3.1.1. securityStateReference . . . . . . . . . . . . . . . . 9
3.1.2. tmStateReference . . . . . . . . . . . . . . . . . . . 9 3.1.2. tmStateReference . . . . . . . . . . . . . . . . . . . 10
3.1.3. Prefixes and securityNames . . . . . . . . . . . . . . 10 3.1.3. Prefixes and securityNames . . . . . . . . . . . . . . 10
4. Processing an Outgoing Message . . . . . . . . . . . . . . . . 10 4. Processing an Outgoing Message . . . . . . . . . . . . . . . . 10
4.1. Security Processing for an Outgoing Message . . . . . . . 10 4.1. Security Processing for an Outgoing Message . . . . . . . 11
4.2. Elements of Procedure for Outgoing Messages . . . . . . . 11 4.2. Elements of Procedure for Outgoing Messages . . . . . . . 12
5. Processing an Incoming SNMP Message . . . . . . . . . . . . . 12 5. Processing an Incoming SNMP Message . . . . . . . . . . . . . 13
5.1. Security Processing for an Incoming Message . . . . . . . 13 5.1. Security Processing for an Incoming Message . . . . . . . 13
5.2. Elements of Procedure for Incoming Messages . . . . . . . 13 5.2. Elements of Procedure for Incoming Messages . . . . . . . 14
6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 14 6. MIB Module Overview . . . . . . . . . . . . . . . . . . . . . 15
6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 14 6.1. Structure of the MIB Module . . . . . . . . . . . . . . . 15
6.1.1. The snmpTsmStats Subtree . . . . . . . . . . . . . . . 15 6.1.1. The snmpTsmStats Subtree . . . . . . . . . . . . . . . 15
6.1.2. The snmpTsmConfiguration Subtree . . . . . . . . . . . 15 6.1.2. The snmpTsmConfiguration Subtree . . . . . . . . . . . 15
6.2. Relationship to Other MIB Modules . . . . . . . . . . . . 15 6.2. Relationship to Other MIB Modules . . . . . . . . . . . . 16
6.2.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 15 6.2.1. MIB Modules Required for IMPORTS . . . . . . . . . . . 16
7. MIB module definition . . . . . . . . . . . . . . . . . . . . 15 7. MIB module definition . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.1. MIB module security . . . . . . . . . . . . . . . . . . . 21 8.1. MIB module security . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Notification Tables Configuration . . . . . . . . . . 24 Appendix A. Notification Tables Configuration . . . . . . . . . . 25
A.1. Transport Security Model Processing for Notifications . . 26 A.1. Transport Security Model Processing for Notifications . . 27
Appendix B. Processing Differences between USM and Secure Appendix B. Processing Differences between USM and Secure
Transport . . . . . . . . . . . . . . . . . . . . . . 26 Transport . . . . . . . . . . . . . . . . . . . . . . 27
B.1. USM and the RFC3411 Architecture . . . . . . . . . . . . . 27 B.1. USM and the RFC3411 Architecture . . . . . . . . . . . . . 28
B.2. Transport Subsystem and the RFC3411 Architecture . . . . . 27 B.2. Transport Subsystem and the RFC3411 Architecture . . . . . 28
1. Introduction 1. Introduction
This memo describes a Transport Security Model for the Simple Network This memo describes a Transport Security Model for the Simple Network
Management Protocol, for use with secure Transport Models in the Management Protocol, for use with secure Transport Models in the
Transport Subsystem [I-D.ietf-isms-tmsm]. Transport Subsystem [I-D.ietf-isms-tmsm].
This memo also defines a portion of the Management Information Base This memo also defines a portion of the Management Information Base
(MIB) for monitoring and managing the Transport Security Model for (MIB) for monitoring and managing the Transport Security Model for
SNMP. SNMP.
skipping to change at page 5, line 7 skipping to change at page 5, line 7
SNMPv3 was advanced to Full Standard. SNMPv3 was advanced to Full Standard.
Authentication in this document typically refers to the English Authentication in this document typically refers to the English
meaning of "serving to prove the authenticity of" the message, not meaning of "serving to prove the authenticity of" the message, not
data source authentication or peer identity authentication. data source authentication or peer identity authentication.
The terms "manager" and "agent" are not used in this document, The terms "manager" and "agent" are not used in this document,
because in the RFC 3411 architecture, all SNMP entities have the because in the RFC 3411 architecture, all SNMP entities have the
capability of acting as either manager or agent or both depending on capability of acting as either manager or agent or both depending on
the SNMP applications included in the engine. Where distinction is the SNMP applications included in the engine. Where distinction is
required, the application names of Command Generator, Command needed, the application names of Command Generator, Command
Responder, Notification Originator, Notification Receiver, and Proxy Responder, Notification Originator, Notification Receiver, and Proxy
Forwarder are used. See "SNMP Applications" [RFC3413] for further Forwarder are used. See "SNMP Applications" [RFC3413] for further
information. information.
While security protocols frequently refer to a user, the terminology While security protocols frequently refer to a user, the terminology
used in RFC3411 [RFC3411] and in this memo is "principal". A used in RFC3411 [RFC3411] and in this memo is "principal". A
principal is the "who" on whose behalf services are provided or principal is the "who" on whose behalf services are provided or
processing takes place. A principal can be, among other things, an processing takes place. A principal can be, among other things, an
individual acting in a particular role; a set of individuals, with individual acting in a particular role; a set of individuals, with
each acting in a particular role; an application or a set of each acting in a particular role; an application or a set of
applications, or a combination of these within an administrative applications, or a combination of these within an administrative
domain. domain.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Non uppercased versions of the keywords should be read as in normal
English. They will usually, but not always, be used in a context
relating to compatibility with the RFC3411 architecture or the
subsystem defined here, but which might have no impact on on-the-wire
compatibility. These terms are used as guidance for designers of
proposed IETF models to make the designs compatible with RFC3411
subsystems and Abstract Service Interfaces (ASIs) (see section 3.2).
Implementers are free to implement differently. Some usages of these
lowercase terms are simply normal English usage.
1.3. Modularity 1.3. Modularity
The reader is expected to have read and understood the description of The reader is expected to have read and understood the description of
the SNMP architecture, as defined in [RFC3411], and the architecture the SNMP architecture, as defined in [RFC3411], and the architecture
extension specified in "Transport Subsystem for the Simple Network extension specified in "Transport Subsystem for the Simple Network
Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of Management Protocol" [I-D.ietf-isms-tmsm], which enables the use of
external "lower layer transport" protocols to provide message external "lower layer transport" protocols to provide message
security, tied into the SNMP architecture through the Transport security, tied into the SNMP architecture through the Transport
Subsystem. The Transport Security Model is designed to work with Subsystem. The Transport Security Model is designed to work with
such lower-layer secure Transport Models. such lower-layer secure Transport Models.
skipping to change at page 6, line 30 skipping to change at page 6, line 36
1. In times of network stress, the security protocol and its 1. In times of network stress, the security protocol and its
underlying security mechanisms SHOULD NOT depend solely upon the underlying security mechanisms SHOULD NOT depend solely upon the
ready availability of other network services (e.g., Network Time ready availability of other network services (e.g., Network Time
Protocol (NTP) or Authentication, Authorization, and Accounting Protocol (NTP) or Authentication, Authorization, and Accounting
(AAA) protocols). (AAA) protocols).
2. When the network is not under stress, the Security Model and its 2. When the network is not under stress, the Security Model and its
underlying security mechanisms MAY depend upon the ready underlying security mechanisms MAY depend upon the ready
availability of other network services. availability of other network services.
3. It may not be possible for the Security Model to determine when 3. It might not be possible for the Security Model to determine when
the network is under stress. the network is under stress.
4. A Security Model should require no changes to the SNMP 4. A Security Model SHOULD NOT require changes to the SNMP
architecture. architecture.
5. A Security Model should require no changes to the underlying 5. A Security Model SHOULD NOT require changes to the underlying
security protocol. security protocol.
2. How the Transport Security Model Fits in the Architecture 2. How the Transport Security Model Fits in the Architecture
The Transport Security Model is designed to fit into the RFC3411 The Transport Security Model is designed to fit into the RFC3411
architecture as a Security Model in the Security Subsystem, and to architecture as a Security Model in the Security Subsystem, and to
utilize the services of a secure Transport Model. utilize the services of a secure Transport Model.
For incoming messages, a secure Transport Model will pass a For incoming messages, a secure Transport Model will pass a
tmStateReference cache, described later. To maintain RFC3411 tmStateReference cache, described later. To maintain RFC3411
skipping to change at page 7, line 4 skipping to change at page 7, line 11
utilize the services of a secure Transport Model. utilize the services of a secure Transport Model.
For incoming messages, a secure Transport Model will pass a For incoming messages, a secure Transport Model will pass a
tmStateReference cache, described later. To maintain RFC3411 tmStateReference cache, described later. To maintain RFC3411
modularity, the Transport Model will not know which securityModel modularity, the Transport Model will not know which securityModel
will process the incoming message; the Message Processing Model will will process the incoming message; the Message Processing Model will
determine this. If the Transport Security Model is used with a non- determine this. If the Transport Security Model is used with a non-
secure Transport Model, then the cache will not exist or not be secure Transport Model, then the cache will not exist or not be
populated with security parameters, which will cause the Transport populated with security parameters, which will cause the Transport
Security Model to return an error (see section 5.2) Security Model to return an error (see section 5.2)
The Transport Security Model will create the securityName and The Transport Security Model will create the securityName and
securityLevel to be passed to applications, and verify that the securityLevel to be passed to applications, and verify that the
tmTransportSecurityLevel reported by the Transport Model is at least tmTransportSecurityLevel reported by the Transport Model is at least
as strong as the securityLevel requested by the Message Processing as strong as the securityLevel requested by the Message Processing
Model. Model.
For outgoing messages, the Transport Security Model will create a For outgoing messages, the Transport Security Model will create a
tmStateReference cache (or use an existing one), and pass the tmStateReference cache (or use an existing one), and pass the
tmStateReference to the specified Transport Model. tmStateReference to the specified Transport Model.
2.1. Security Capabilities of this Model 2.1. Security Capabilities of this Model
2.1.1. Threats 2.1.1. Threats
The Transport Security Model is compatible with the RFC3411 The Transport Security Model is compatible with the RFC3411
architecture, and provides protection against the threats identified architecture, and provides protection against the threats identified
by the RFC 3411 architecture. However, the Transport Security Model by the RFC 3411 architecture. However, the Transport Security Model
does not provide security mechanisms such as authentication and does not provide security mechanisms such as authentication and
encryption itself, so it SHOULD always be used with a Transport Model encryption itself. Which threats are addressed and how they are
that provides appropriate security. Which threats are addressed and mitigated depends on the Transport Model used. To avoid creating
how they are mitigated depends on the Transport Model. potential security vulnerabilities, operators should configure their
system so this Security Model is always used with a Transport Model
that provides appropriate security, where "appropriate" for a
particular deployment is an administrative decision.
2.1.2. Security Levels 2.1.2. Security Levels
The RFC 3411 architecture recognizes three levels of security: The RFC 3411 architecture recognizes three levels of security:
- without authentication and without privacy (noAuthNoPriv) - without authentication and without privacy (noAuthNoPriv)
- with authentication but without privacy (authNoPriv) - with authentication but without privacy (authNoPriv)
- with authentication and with privacy (authPriv) - with authentication and with privacy (authPriv)
The model-independent securityLevel parameter is used to request The model-independent securityLevel parameter is used to request
specific levels of security for outgoing messages, and to assert that specific levels of security for outgoing messages, and to assert that
specific levels of security were applied during the transport and specific levels of security were applied during the transport and
processing of incoming messages. processing of incoming messages.
The transport layer algorithms used to provide security SHOULD NOT be The transport layer algorithms used to provide security should not be
exposed to the Transport Security Model, as the Transport Security exposed to the Transport Security Model, as the Transport Security
Model has no mechanisms by which it can test whether an assertion Model has no mechanisms by which it can test whether an assertion
made by a Transport Model is accurate. made by a Transport Model is accurate.
The Transport Security Model trusts that the underlying secure The Transport Security Model trusts that the underlying secure
transport connection has been properly configured to support security transport connection has been properly configured to support security
characteristics at least as strong as reported in characteristics at least as strong as reported in
tmTransportSecurityLevel. tmTransportSecurityLevel.
2.2. Transport Sessions 2.2. Transport Sessions
skipping to change at page 8, line 17 skipping to change at page 8, line 27
The Transport Security Model does not work with transport sessions The Transport Security Model does not work with transport sessions
directly. Instead the transport-related state is associated with a directly. Instead the transport-related state is associated with a
unique combination of transportDomain, transportAddress, securityName unique combination of transportDomain, transportAddress, securityName
and securityLevel, and referenced via the tmStateReference parameter. and securityLevel, and referenced via the tmStateReference parameter.
How and if this is mapped to a particular transport or channel is the How and if this is mapped to a particular transport or channel is the
responsibility of the Transport Subsystem. responsibility of the Transport Subsystem.
2.3. Coexistence 2.3. Coexistence
In the RFC3411 architecture, a Message Processing Model determines In the RFC3411 architecture, a Message Processing Model determines
which Security Model should be called. As of this writing, IANA has which Security Model SHALL be called. As of this writing, IANA has
registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/ registered four Message Processing Models (SNMPv1, SNMPv2c, SNMPv2u/
SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1, SNMPv2*, and SNMPv3) and three other Security Models (SNMPv1,
SNMPv2c, and the User-based Security Model). SNMPv2c, and the User-based Security Model).
2.3.1. Coexistence with Message Processing Models 2.3.1. Coexistence with Message Processing Models
The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP The SNMPv1 and SNMPv2c message processing described in RFC3584 (BCP
74) [RFC3584] always selects the SNMPv1(1) and SNMPv2c(2) Security 74) [RFC3584] always selects the SNMPv1(1) and SNMPv2c(2) Security
Models. Since there is no mechanism defined in RFC3584 to select an Models. Since there is no mechanism defined in RFC3584 to select an
alternative Security Model, SNMPv1 and SNMPv2c messages cannot use alternative Security Model, SNMPv1 and SNMPv2c messages cannot use
the Transport Security Model. Such messages can still be conveyed the Transport Security Model. Messages might still be able to be
over a secure transport protocol, but the Transport Security Model conveyed over a secure transport protocol, but the Transport Security
will not be invoked. Model will not be invoked.
The SNMPv2u/SNMPv2* Message Processing Model is a historic artifact The SNMPv2u/SNMPv2* Message Processing Model is a historic artifact
for which there is no existing IETF specification. for which there is no existing IETF specification.
The SNMPv3 message processing defined in RFC3412 [RFC3412], extracts The SNMPv3 message processing defined in RFC3412 [RFC3412], extracts
the securityModel from the msgSecurityModel field of an incoming the securityModel from the msgSecurityModel field of an incoming
SNMPv3Message. When this value is transportSecurityModel(YY), SNMPv3Message. When this value is transportSecurityModel(YY),
security processing is directed to the Transport Security Model. For security processing is directed to the Transport Security Model. For
an outgoing message to be secured using the Transport Security Model, an outgoing message to be secured using the Transport Security Model,
the application should specify a securityModel parameter value of the application MUST specify a securityModel parameter value of
transportSecurityModel(YY) in the sendPdu ASI. transportSecurityModel(YY) in the sendPdu Application Service
Interface (ASI).
[-- NOTE to RFC editor: replace YY with actual IANA-assigned number, [-- NOTE to RFC editor: replace YY with actual IANA-assigned number,
and remove this note. ] and remove this note. ]
2.3.2. Coexistence with Other Security Models 2.3.2. Coexistence with Other Security Models
The Transport Security Model uses its own MIB module for processing The Transport Security Model uses its own MIB module for processing
to maintain independence from other Security Models. This allows the to maintain independence from other Security Models. This allows the
Transport Security Model to coexist with other Security Models, such Transport Security Model to coexist with other Security Models, such
as the User-based Security Model [RFC3414]. as the User-based Security Model [RFC3414].
2.3.3. Coexistence with Transport Models 2.3.3. Coexistence with Transport Models
The Transport Security Model may work with multiple Transport Models, The Transport Security Model MAY work with multiple Transport Models,
but the RFC3411 application service interfaces (ASIs) do not carry a but the RFC3411 application service interfaces (ASIs) do not carry a
value for the Transport Model. The MIB module defined in this memo value for the Transport Model. The MIB module defined in this memo
allows an administrator to configure whether or not TSM prepends a allows an administrator to configure whether or not TSM prepends a
transport model prefix to the securityName. This will allow SNMP transport model prefix to the securityName. This will allow SNMP
applications to consider transport model as a factor when making applications to consider transport model as a factor when making
decisions, such as access control, notification generation, and proxy decisions, such as access control, notification generation, and proxy
forwarding. forwarding.
To have SNMP properly utilize the security services coordinated by
the Transport Security Model, this Security Model MUST only be used
with Transport Models that know how to process a tmStateReference,
such as the Secure Shell Transport Model [I-D.ietf-isms-secshell].
3. Cached Information and References 3. Cached Information and References
When performing SNMP processing, there are two levels of state When performing SNMP processing, there are two levels of state
information that may need to be retained: the immediate state linking information that might need to be retained: the immediate state
a request-response pair, and potentially longer-term state relating linking a request-response pair, and potentially longer-term state
to transport and security. "Transport Subsystem for the Simple relating to transport and security. "Transport Subsystem for the
Network Management Protocol" [I-D.ietf-isms-tmsm] defines general Simple Network Management Protocol" [I-D.ietf-isms-tmsm] defines
requirements for caches and references. general requirements for caches and references.
This document defines additional cache requirements related to the This document defines additional cache requirements related to the
Transport Security Model. Transport Security Model.
3.1. Transport Security Model Cached Information 3.1. Transport Security Model Cached Information
The Transport Security Model has specific responsibilities regarding The Transport Security Model has specific responsibilities regarding
the cached information. the cached information.
3.1.1. securityStateReference 3.1.1. securityStateReference
skipping to change at page 9, line 46 skipping to change at page 10, line 12
the processIncomingMsg ASI to the securityStateReference. This the processIncomingMsg ASI to the securityStateReference. This
tmStateReference can then be retrieved during the generateResponseMsg tmStateReference can then be retrieved during the generateResponseMsg
ASI, so that it can be passed back to the Transport Model. ASI, so that it can be passed back to the Transport Model.
3.1.2. tmStateReference 3.1.2. tmStateReference
For outgoing messages, the Transport Security Model uses parameters For outgoing messages, the Transport Security Model uses parameters
provided by the SNMP application to lookup or create a provided by the SNMP application to lookup or create a
tmStateReference. tmStateReference.
The Transport Security Model REQUIRES that the security parameters For the Transport Security Model, the security parameters used for a
used for a response are the same as those used for the corresponding response MUST be the same as those used for the corresponding
request. This security model uses the tmStateReference stored as request. This security model uses the tmStateReference stored as
part of the securityStateReference when appropriate. For responses part of the securityStateReference when appropriate. For responses
and reports, this security model sets the tmSameSecurity flag to true and reports, this security model sets the tmSameSecurity flag to true
in the tmStateReference before passing it to a transport model. in the tmStateReference before passing it to a transport model.
For incoming messages, the Transport Security Model uses parameters For incoming messages, the Transport Security Model uses parameters
provided in the tmStateReference cache to establish a securityName, provided in the tmStateReference cache to establish a securityName,
and to verify adequate security levels. and to verify adequate security levels.
3.1.3. Prefixes and securityNames 3.1.3. Prefixes and securityNames
The SNMP-VIEW-BASED-ACM-MIB [RFC3415], the SNMP-TARGET-MIB module The SNMP-VIEW-BASED-ACM-MIB [RFC3415], the SNMP-TARGET-MIB module
[RFC3413], and other MIB modules contain objects to configure [RFC3413], and other MIB modules contain objects to configure
security parameters for use by applications such as access control, security parameters for use by applications such as access control,
notification generation, and proxy forwarding. notification generation, and proxy forwarding.
IANA maintains a registry for transport domains and the corresponding Transport domains and their corresponding prefixes are coordinated
prefix. via the IANA registry "SNMP Transport Domains".
If snmpTsmConfigurationUsePrefix is set to true then all If snmpTsmConfigurationUsePrefix is set to true then all
securityNames provided by, or provided to, the Transport Security securityNames provided by, or provided to, the Transport Security
Model MUST include a valid transport domain prefix. Model MUST include a valid transport domain prefix.
If snmpTsmConfigurationUsePrefix is set to false then all If snmpTsmConfigurationUsePrefix is set to false then all
securityNames provided by, or provided to, the Transport Security securityNames provided by, or provided to, the Transport Security
Model MUST NOT include a transport domain prefix. Model MUST NOT include a transport domain prefix.
The tmSecurityName in the tmStateReference stored as part of the The tmSecurityName in the tmStateReference stored as part of the
securityStateReference does not contain a prefix. securityStateReference does not contain a prefix.
4. Processing an Outgoing Message 4. Processing an Outgoing Message
An error indication may return an OID and value for an incremented An error indication might return an OID and value for an incremented
counter and a value for securityLevel, and values for contextEngineID counter and a value for securityLevel, and values for contextEngineID
and contextName for the counter, and the securityStateReference if and contextName for the counter, and the securityStateReference if
the information is available at the point where the error is the information is available at the point where the error is
detected. detected.
4.1. Security Processing for an Outgoing Message 4.1. Security Processing for an Outgoing Message
This section describes the procedure followed by the Transport This section describes the procedure followed by the Transport
Security Model. Security Model.
skipping to change at page 12, line 31 skipping to change at page 13, line 12
a prefix, the prefix stripping step only occurs when we are not using a prefix, the prefix stripping step only occurs when we are not using
the securityStateReference). the securityStateReference).
If the prefix lookup fails for any reason, then the If the prefix lookup fails for any reason, then the
snmpTsmUnknownPrefixes counter is incremented, an error indication snmpTsmUnknownPrefixes counter is incremented, an error indication
is returned to the calling module, and message processing stops. is returned to the calling module, and message processing stops.
If the lookup succeeds, but there is no prefix in the If the lookup succeeds, but there is no prefix in the
securityName, or the prefix returned does not match the prefix in securityName, or the prefix returned does not match the prefix in
the securityName, or the length of the prefix is less than 1 or the securityName, or the length of the prefix is less than 1 or
greater than four ASCII characters, then the greater than four US-ASCII alpha-numeric characters, then the
snmpTsmInvalidPrefixes counter is incremented, an error indication snmpTsmInvalidPrefixes counter is incremented, an error indication
is returned to the calling module, and message processing stops. is returned to the calling module, and message processing stops.
Strip the transport-specific prefix and trailing ':' character Strip the transport-specific prefix and trailing ':' character
(ASCII 0x3a) from the securityName. Set tmSecurityName to the (US-ASCII 0x3a) from the securityName. Set tmSecurityName to the
value of securityName. value of securityName.
3) Set securityParameters to a zero-length OCTET STRING ('0400'). 3) Set securityParameters to a zero-length OCTET STRING ('0400').
4) Combine the message parts into a wholeMsg and calculate 4) Combine the message parts into a wholeMsg and calculate
wholeMsgLength. wholeMsgLength.
5) The wholeMsg, wholeMsgLength, securityParameters and 5) The wholeMsg, wholeMsgLength, securityParameters and
tmStateReference are returned to the calling Message Processing Model tmStateReference are returned to the calling Message Processing Model
with the statusInformation set to success. with the statusInformation set to success.
5. Processing an Incoming SNMP Message 5. Processing an Incoming SNMP Message
An error indication may return an OID and value for an incremented An error indication might return an OID and value for an incremented
counter and a value for securityLevel, and values for contextEngineID counter and a value for securityLevel, and values for contextEngineID
and contextName for the counter, and the securityStateReference if and contextName for the counter, and the securityStateReference if
the information is available at the point where the error is the information is available at the point where the error is
detected. detected.
5.1. Security Processing for an Incoming Message 5.1. Security Processing for an Incoming Message
This section describes the procedure followed by the Transport This section describes the procedure followed by the Transport
Security Model whenever it receives an incoming message from a Security Model whenever it receives an incoming message from a
Message Processing Model. The ASI from a Message Processing Model to Message Processing Model. The ASI from a Message Processing Model to
skipping to change at page 14, line 11 skipping to change at page 14, line 48
If the prefix lookup fails for any reason, then the If the prefix lookup fails for any reason, then the
snmpTsmUnknownPrefixes counter is incremented, an error indication snmpTsmUnknownPrefixes counter is incremented, an error indication
is returned to the calling module, and message processing stops. is returned to the calling module, and message processing stops.
If the lookup succeeds, but the prefix length is less than one or If the lookup succeeds, but the prefix length is less than one or
greater than four octets, then the snmpTsmInvalidPrefixes counter greater than four octets, then the snmpTsmInvalidPrefixes counter
is incremented, an error indication is returned to the calling is incremented, an error indication is returned to the calling
module, and message processing stops. module, and message processing stops.
Set the securityName to be the concatenation of the prefix, a ':' Set the securityName to be the concatenation of the prefix, a ':'
character (ASCII 0x3a) and the tmSecurityName. character (US-ASCII 0x3a) and the tmSecurityName.
4) Compare the value of tmTransportSecurityLevel in the 4) Compare the value of tmTransportSecurityLevel in the
tmStateReference cache to the value of the securityLevel parameter tmStateReference cache to the value of the securityLevel parameter
passed in the processIncomingMsg ASI. If securityLevel specifies passed in the processIncomingMsg ASI. If securityLevel specifies
privacy (Priv), and tmTransportSecurityLevel specifies no privacy privacy (Priv), and tmTransportSecurityLevel specifies no privacy
(noPriv), or securityLevel specifies authentication (auth) and (noPriv), or securityLevel specifies authentication (auth) and
tmTransportSecurityLevel specifies no authentication (noAuth) was tmTransportSecurityLevel specifies no authentication (noAuth) was
provided by the Transport Model, then the provided by the Transport Model, then the
snmpTsmInadequateSecurityLevels counter is incremented, an error snmpTsmInadequateSecurityLevels counter is incremented, an error
indication (unsupportedSecurityLevel) together with the OID and value indication (unsupportedSecurityLevel) together with the OID and value
skipping to change at page 15, line 38 skipping to change at page 16, line 27
The following MIB module imports items from [RFC2578], [RFC2579], and The following MIB module imports items from [RFC2578], [RFC2579], and
[RFC2580]. [RFC2580].
7. MIB module definition 7. MIB module definition
SNMP-TSM-MIB DEFINITIONS ::= BEGIN SNMP-TSM-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, MODULE-IDENTITY, OBJECT-TYPE,
mib-2, Counter32 mib-2, Counter32
FROM SNMPv2-SMI FROM SNMPv2-SMI -- RFC2578
MODULE-COMPLIANCE, OBJECT-GROUP MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF FROM SNMPv2-CONF -- RFC2580
TruthValue TruthValue
FROM SNMPv2-TC FROM SNMPv2-TC -- RFC2579
; ;
snmpTsmMIB MODULE-IDENTITY snmpTsmMIB MODULE-IDENTITY
LAST-UPDATED "200903090000Z" LAST-UPDATED "200903090000Z"
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 Quittek Juergen Quittek
NEC Europe Ltd. NEC Europe Ltd.
Network Laboratories Network Laboratories
Kurfuersten-Anlage 36 Kurfuersten-Anlage 36
69115 Heidelberg 69115 Heidelberg
Germany Germany
+49 6221 90511-15 +49 6221 90511-15
quittek@netlab.nec.de quittek@netlab.nec.de
Juergen Schoenwaelder Juergen Schoenwaelder
skipping to change at page 16, line 48 skipping to change at page 17, line 36
" "
DESCRIPTION "The Transport Security Model MIB DESCRIPTION "The Transport Security Model MIB
In keeping with the RFC 3411 design decisions In keeping with the RFC 3411 design decisions
to use self-contained documents, the RFC which to use self-contained documents, the RFC which
contains the definition of this MIB module also contains the definition of this MIB module also
includes the elements of procedure which are includes the elements of procedure which are
needed for processing the Transport Security needed for processing the Transport Security
Model for SNMP. These MIB objects Model for SNMP. These MIB objects
SHOULD NOT be modified via other subsystems SHOULD NOT be modified via other subsystems
or models defined in other document.. or models defined in other documents.
This allows the Transport Security Model This allows the Transport Security Model
for SNMP to be designed and documented as for SNMP to be designed and documented as
independent and self- contained, having no independent and self- contained, having no
direct impact on other modules, and this direct impact on other modules, and this
allows this module to be upgraded and allows this module to be upgraded and
supplemented as the need arises, and to supplemented as the need arises, and to
move along the standards track on different move along the standards track on different
time-lines from other modules. time-lines from other modules.
Copyright (c) 2009 IETF Trust and the persons identified as Copyright (c) 2009 IETF Trust and the persons identified as
skipping to change at page 23, line 9 skipping to change at page 23, line 44
insights, and Dave Shield for an outstanding job wordsmithing the insights, and Dave Shield for an outstanding job wordsmithing the
existing document to improve organization and clarity. existing document to improve organization and clarity.
Additionally, helpful document reviews were received from: Juergen Additionally, helpful document reviews were received from: Juergen
Schoenwaelder. Schoenwaelder.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119, Indicate Requirement Levels", BCP 14,
March 1997. RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and
Schoenwaelder, Ed., "Structure of Management J. Schoenwaelder, Ed., "Structure of
Information Version 2 (SMIv2)", STD 58, Management Information Version 2 (SMIv2)",
RFC 2578, April 1999. STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and
Schoenwaelder, Ed., "Textual Conventions for J. Schoenwaelder, Ed., "Textual Conventions
SMIv2", STD 58, RFC 2579, April 1999. for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. [RFC2580] McCloghrie, K., Perkins, D., and J.
Schoenwaelder, "Conformance Statements for Schoenwaelder, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999. SMIv2", STD 58, RFC 2580, April 1999.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen,
Architecture for Describing Simple Network "An Architecture for Describing Simple
Management Protocol (SNMP) Management Network Management Protocol (SNMP)
Frameworks", STD 62, RFC 3411, December 2002. Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3412] Case, J., Harrington, D., Presuhn, R., and B. [RFC3412] Case, J., Harrington, D., Presuhn, R., and
Wijnen, "Message Processing and Dispatching for B. Wijnen, "Message Processing and
the Simple Network Management Protocol (SNMP)", Dispatching for the Simple Network
STD 62, RFC 3412, December 2002. Management Protocol (SNMP)", STD 62,
RFC 3412, December 2002.
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple [RFC3413] Levi, D., Meyer, P., and B. Stewart,
Network Management Protocol (SNMP) "Simple Network Management Protocol (SNMP)
Applications", STD 62, RFC 3413, December 2002. Applications", STD 62, RFC 3413,
December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based [RFC3414] Blumenthal, U. and B. Wijnen, "User-based
Security Model (USM) for version 3 of the Security Model (USM) for version 3 of the
Simple Network Management Protocol (SNMPv3)", Simple Network Management Protocol
STD 62, RFC 3414, December 2002. (SNMPv3)", STD 62, RFC 3414, December 2002.
[I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder, "Transport [I-D.ietf-isms-tmsm] Harrington, D. and J. Schoenwaelder,
Subsystem for the Simple Network Management "Transport Subsystem for the Simple Network
Protocol (SNMP)", draft-ietf-isms-tmsm-16 (work Management Protocol (SNMP)",
in progress), February 2009. draft-ietf-isms-tmsm-17 (work in progress),
April 2009.
11.2. Informative References 11.2. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D., and B. [RFC3410] Case, J., Mundy, R., Partain, D., and B.
Stewart, "Introduction and Applicability Stewart, "Introduction and Applicability
Statements for Internet-Standard Management Statements for Internet-Standard Management
Framework", RFC 3410, December 2002. Framework", RFC 3410, December 2002.
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie,
"View-based Access Control Model (VACM) for the "View-based Access Control Model (VACM) for
Simple Network Management Protocol (SNMP)", the Simple Network Management Protocol
STD 62, RFC 3415, December 2002. (SNMP)", STD 62, RFC 3415, December 2002.
[RFC3418] Presuhn, R., "Management Information Base (MIB) [RFC3418] Presuhn, R., "Management Information Base
for the Simple Network Management Protocol (MIB) for the Simple Network Management
(SNMP)", STD 62, RFC 3418, December 2002. Protocol (SNMP)", STD 62, RFC 3418,
December 2002.
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. [RFC3584] Frye, R., Levi, D., Routhier, S., and B.
Wijnen, "Coexistence between Version 1, Version Wijnen, "Coexistence between Version 1,
2, and Version 3 of the Internet-standard Version 2, and Version 3 of the Internet-
Network Management Framework", BCP 74, standard Network Management Framework",
RFC 3584, August 2003. BCP 74, RFC 3584, August 2003.
[I-D.ietf-isms-secshell] Harrington, D., Salowey, J., and W.
Hardaker, "Secure Shell Transport Model for
SNMP", draft-ietf-isms-secshell-16 (work in
progress), April 2009.
Appendix A. Notification Tables Configuration Appendix A. Notification Tables Configuration
The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB [RFC3413] are used to
configure notification originators with the destinations to which configure notification originators with the destinations to which
notifications should be sent. notifications should be sent.
Most of the configuration is security-model-independent and Most of the configuration is security-model-independent and
transport-model-independent. transport-model-independent.
skipping to change at page 25, line 4 skipping to change at page 25, line 46
securityModel = Transport Security Model securityModel = Transport Security Model
securityName = alice securityName = alice
securityLevel = authPriv securityLevel = authPriv
[-- NOTE to RFC editor: replace PPP above with actual IANA-assigned [-- NOTE to RFC editor: replace PPP above with actual IANA-assigned
port number for SNMP notifications over SSH, from port number for SNMP notifications over SSH, from
draft-ietf-isms-secshell, and remove this note. ] draft-ietf-isms-secshell, and remove this note. ]
The following example will configure the Notification Originator to The following example will configure the Notification Originator to
send informs to a Notification Receiver at 192.0.2.1:PPP using the send informs to a Notification Receiver at 192.0.2.1:PPP using the
securityName "alice". "alice" is the name for the recipient from the securityName "alice". "alice" is the name for the recipient from the
standpoint of the notification originator, and is used for processing standpoint of the notification originator, and is used for processing
access controls before sending a notification. access controls before sending a notification.
[-- NOTE to RFC editor: replace PPP above with actual IANA-assigned [-- NOTE to RFC editor: replace PPP above with actual IANA-assigned
port number for SNMP notifications over SSH, and remove this note. ] port number for SNMP notifications over SSH, and remove this note. ]
The columns marked with a "*" are the items that are Security Model The columns marked with a "*" are the items that are Security Model
or Transport Model specific. or Transport Model specific.
The configuration for the "alice" settings in the SNMP-VIEW-BASED- The configuration for the "alice" settings in the SNMP-VIEW-BASED-
ACM-MIB objects are not shown here for brevity. First we configure ACM-MIB objects are not shown here for brevity. First we configure
which type of notification should be sent for this taglist (toCRTag). which type of notification will be sent for this taglist (toCRTag).
In this example, we choose to send an Inform. In this example, we choose to send an Inform.
snmpNotifyTable row: snmpNotifyTable row:
snmpNotifyName CRNotif snmpNotifyName CRNotif
snmpNotifyTag toCRTag snmpNotifyTag toCRTag
snmpNotifyType inform snmpNotifyType inform
snmpNotifyStorageType nonVolatile snmpNotifyStorageType nonVolatile
snmpNotifyColumnStatus createAndGo snmpNotifyColumnStatus createAndGo
Then we configure a transport address to which notifications Then we configure a transport address to which notifications
associated with this taglist should be sent, and we specify which associated with this taglist will be sent, and we specify which
snmpTargetParamsEntry should be used (toCR) when sending to this snmpTargetParamsEntry will be used (toCR) when sending to this
transport address. transport address.
snmpTargetAddrTable row: snmpTargetAddrTable row:
snmpTargetAddrName toCRAddr snmpTargetAddrName toCRAddr
* snmpTargetAddrTDomain snmpSSHDomain * snmpTargetAddrTDomain snmpSSHDomain
* snmpTargetAddrTAddress 192.0.2.1:PPP * snmpTargetAddrTAddress 192.0.2.1:PPP
snmpTargetAddrTimeout 1500 snmpTargetAddrTimeout 1500
snmpTargetAddrRetryCount 3 snmpTargetAddrRetryCount 3
snmpTargetAddrTagList toCRTag snmpTargetAddrTagList toCRTag
snmpTargetAddrParams toCR (must match below) snmpTargetAddrParams toCR (MUST match below)
snmpTargetAddrStorageType nonVolatile snmpTargetAddrStorageType nonVolatile
snmpTargetAddrColumnStatus createAndGo snmpTargetAddrColumnStatus createAndGo
[-- NOTE to RFC editor: replace PPP above with actual IANA-assigned [-- NOTE to RFC editor: replace PPP above with actual IANA-assigned
port number for SNMP notifications over SSH, and remove this note. ] port number for SNMP notifications over SSH, and remove this note. ]
Then we configure which principal at the host should receive the Then we configure which principal at the host will receive the
notifications associated with this taglist. Here we choose "alice", notifications associated with this taglist. Here we choose "alice",
who uses the Transport Security Model. who uses the Transport Security Model.
snmpTargetParamsTable row: snmpTargetParamsTable row:
snmpTargetParamsName toCR snmpTargetParamsName toCR
snmpTargetParamsMPModel SNMPv3 snmpTargetParamsMPModel SNMPv3
* snmpTargetParamsSecurityModel TransportSecurityModel * snmpTargetParamsSecurityModel TransportSecurityModel
snmpTargetParamsSecurityName "alice" snmpTargetParamsSecurityName "alice"
snmpTargetParamsSecurityLevel authPriv snmpTargetParamsSecurityLevel authPriv
snmpTargetParamsStorageType nonVolatile snmpTargetParamsStorageType nonVolatile
snmpTargetParamsRowStatus createAndGo snmpTargetParamsRowStatus createAndGo
A.1. Transport Security Model Processing for Notifications A.1. Transport Security Model Processing for Notifications
skipping to change at page 26, line 48 skipping to change at page 27, line 39
on the snmpTargetAddrTDomain. The selected Transport Model will on the snmpTargetAddrTDomain. The selected Transport Model will
select the appropriate transport connection using the select the appropriate transport connection using the
tmStateReference cache created from the values of tmStateReference cache created from the values of
snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and snmpTargetAddrTAddress, snmpTargetParamsSecurityName, and
snmpTargetParamsSecurityLevel. snmpTargetParamsSecurityLevel.
Appendix B. Processing Differences between USM and Secure Transport Appendix B. Processing Differences between USM and Secure Transport
USM and secure transports differ in the processing order and USM and secure transports differ in the processing order and
responsibilities within the RFC3411 architecture. While the steps responsibilities within the RFC3411 architecture. While the steps
are the same, they occur in a different order, and may be done by are the same, they occur in a different order, and might be done by
different subsystems. The following lists illustrate the difference different subsystems. The following lists illustrate the difference
in the flow and the responsibility for different processing steps for in the flow and the responsibility for different processing steps for
incoming messages when using USM and when using a secure transport. incoming messages when using USM and when using a secure transport.
(These lists are simplified for illustrative purposes, and do not (These lists are simplified for illustrative purposes, and do not
represent all details of processing. Transport Models must provide represent all details of processing. Transport Models MUST provide
the detailed elements of procedure.) the detailed elements of procedure.)
With USM, SNMPv1, and SNMPv2c Security Models, security processing With USM, SNMPv1, and SNMPv2c Security Models, security processing
starts when the Message Processing Model decodes portions of the starts when the Message Processing Model decodes portions of the
ASN.1 message to extract header fields that are used to determine ASN.1 message to extract header fields that are used to determine
which Security Model should process the message to perform which Security Model will process the message to perform
authentication, decryption, timeliness checking, integrity checking, authentication, decryption, timeliness checking, integrity checking,
and translation of parameters to model-independent parameters. By and translation of parameters to model-independent parameters. By
comparison, a secure transport performs those security functions on comparison, a secure transport performs those security functions on
the message, before the ASN.1 is decoded. the message, before the ASN.1 is decoded.
Step 6 cannot occur until after decryption occurs. Step 6 and beyond Step 6 cannot occur until after decryption occurs. Step 6 and beyond
are the same for USM and a secure transport. are the same for USM and a secure transport.
B.1. USM and the RFC3411 Architecture B.1. USM and the RFC3411 Architecture
skipping to change at page 28, line 4 skipping to change at page 28, line 39
B.2. Transport Subsystem and the RFC3411 Architecture B.2. Transport Subsystem and the RFC3411 Architecture
1) authenticate the principal, check integrity and timeliness of the 1) authenticate the principal, check integrity and timeliness of the
message, and decrypt the message. [Transport Model] message, and decrypt the message. [Transport Model]
2) translate parameters to model-independent parameters (Transport 2) translate parameters to model-independent parameters (Transport
Model) Model)
3) decode the ASN.1 header (Message Processing Model) 3) decode the ASN.1 header (Message Processing Model)
4) determine the SNMP Security Model and parameters (Message 4) determine the SNMP Security Model and parameters (Message
Processing Model) Processing Model)
5) verify securityLevel [Security Model] 5) verify securityLevel [Security Model]
6) determine the pduType in the decrypted portions (Message 6) determine the pduType in the decrypted portions (Message
Processing Model), and Processing Model), and
7) pass on the decrypted portions with model-independent security 7) pass on the decrypted portions with model-independent security
parameters parameters
If a message is secured using a secure transport layer, then the If a message is secured using a secure transport layer, then the
Transport Model should provide the translation from the authenticated Transport Model will provide the translation from the authenticated
identity (e.g., an SSH user name) to a human-friendly identifier identity (e.g., an SSH user name) to a human-friendly identifier
(tmSecurityName) in step 2. The security model will provide a (tmSecurityName) in step 2. The security model will provide a
mapping from that identifier to a model-independent securityName. mapping from that identifier to a model-independent securityName.
Authors' Addresses Authors' Addresses
David Harrington David Harrington
Huawei Technologies (USA) Huawei Technologies (USA)
1700 Alma Dr. Suite 100 1700 Alma Dr. Suite 100
Plano, TX 75075 Plano, TX 75075
 End of changes. 61 change blocks. 
117 lines changed or deleted 146 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/