draft-ietf-ips-auth-mib-03.txt   draft-ietf-ips-auth-mib-04.txt 
Internet Draft Mark Bakke Internet Draft Mark Bakke
<draft-ietf-ips-auth-mib-03.txt> Jim Muchow <draft-ietf-ips-auth-mib-04.txt> Jim Muchow
Expires May 2003 Cisco Systems Expires September 2003 Cisco Systems
November 2002 March 2003
Definitions of Managed Objects for User Identity Authentication Definitions of Managed Objects for User Identity Authentication
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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.html. http://www.ietf.org/ietf/1id-abstracts.html.
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.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This memo defines a portion of the Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP based internets. for use with network management protocols in TCP/IP based internets.
In particular it defines objects for managing user identities and the In particular it defines objects for managing user identities and the
names, addresses, and credentials required to authenticate them, for names, addresses, and credentials required to authenticate them, for
use with various protocols. This draft was motivated by the need for use with various protocols. This draft was motivated by the need for
the configuration of authenticated user identities for the iSCSI the configuration of authenticated user identities for the iSCSI
protocol, but has been extended to be useful for other protocols that protocol, but has been extended to be useful for other protocols that
skipping to change at page 2, line 12 skipping to change at page 2, line 12
them; it is the responsibility of other MIBs making use of this one them; it is the responsibility of other MIBs making use of this one
to tie them to authorization lists. to tie them to authorization lists.
Acknowledgments Acknowledgments
In addition to the authors, several people contributed to the In addition to the authors, several people contributed to the
development of this MIB through discussions of authentication, development of this MIB through discussions of authentication,
authorization, and access within the iSCSI MIB and security teams, authorization, and access within the iSCSI MIB and security teams,
including John Hufferd, Marjorie Krueger, Keith McCloghrie, Tom including John Hufferd, Marjorie Krueger, Keith McCloghrie, Tom
McSweeney, Steve Senum, and Josh Tseng. Thanks also to Bill McSweeney, Steve Senum, and Josh Tseng. Thanks also to Bill
Studenmund (Wasabi Systems) for adding the Kerberos method. Studenmund (Wasabi Systems) for adding the Kerberos method, and to
Ayman Ghanem for finding and suggesting changes to several problems
found in the MIB.
Thanks especially to Keith McCloghrie for serving as advisor for this Thanks especially to Keith McCloghrie for serving as advisor for this
MIB. MIB.
Table of Contents Table of Contents
1. The SNMP Management Framework.............................2 1. Introduction..............................................2
2. Relationship to Other MIBs................................4 2. The Internet-Standard Management Framework................3
3. Discussion................................................4 3. Relationship to Other MIBs................................3
3.1. Authentication MIB Object Model.........................4 4. Discussion................................................3
3.2. ipsAuthInstance.........................................5 4.1. Authentication MIB Object Model.........................4
3.3. ipsAuthIdentity.........................................6 4.2. ipsAuthInstance.........................................5
3.4. ipsAuthIdentityName.....................................6 4.3. ipsAuthIdentity.........................................5
3.5. ipsAuthIdentityAddress..................................6 4.4. ipsAuthIdentityName.....................................5
3.6. ipsAuthCredential.......................................7 4.5. ipsAuthIdentityAddress..................................6
3.7. IP, Fibre Channel, and Other Addresses..................8 4.6. ipsAuthCredential.......................................7
3.8. Descriptors: Using OIDs in Place of Enumerated Types....8 4.7. IP, Fibre Channel, and Other Addresses..................7
3.9. Notifications...........................................8 4.8. Descriptors: Using OIDs in Place of Enumerated Types....8
4. MIB Definitions...........................................9 4.9. Notifications...........................................8
5. Security Considerations..................................27 5. MIB Definitions...........................................9
6. Normative References.....................................28 6. Security Considerations..................................28
7. Informative References...................................29 7. Normative References.....................................29
8. Authors' Addresses.......................................31 8. Informative References...................................29
9. Full Copyright Notice....................................31 9. Authors' Addresses.......................................30
10. IPR Notice..............................................30
1. The SNMP Management Framework 11. Full Copyright Notice...................................31
The SNMP Management Framework presently consists of five major
components:
o An overall architecture, described in RFC 2571 [RFC2571].
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in
STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
1215 [RFC1215]. The second version, called SMIv2, is described
in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and
STD 58, RFC 2580 [RFC2580].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [RFC1157]. A second version of
the SNMP message protocol, which is not an Internet standards
track protocol, is called SNMPv2c and described in RFC 1901
[RFC1901] and RFC 1906 [RFC1906]. The third version of the
message protocol is called SNMPv3 and described in RFC 1906
[RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [RFC1157]. A second set of
protocol operations and associated PDU formats is described in
RFC 1905 [RFC1905].
o A set of fundamental applications described in RFC 2573
[RFC2573] and the view-based access control mechanism described
in RFC 2575 [RFC2575].
A more detailed introduction to the current SNMP Management Framework
can be found in RFC 2570 [RFC2570].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI.
This memo specifies a MIB module that is compliant to the SMIv2. A 1. Introduction
MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no
translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the
MIB.
This MIB will be used to configure and/or look at the configuration This MIB will be used to configure and/or look at the configuration
of user identities and their authentication information. For the of user identities and their authentication information. For the
purposes of this MIB, a "user" identity does not need to be an actual purposes of this MIB, a "user" identity does not need to be an actual
person; a user can also be a host, an application, a cluster of person; a user can also be a host, an application, a cluster of
hosts, or any other identifiable entity that can be authenticated and hosts, or any other identifiable entity that can be authenticated and
granted access to a resource. granted access to a resource.
Most objects in this MIB have a MAX-ACCESS of read-create; the MIB is Most objects in this MIB have a MAX-ACCESS of read-create; the MIB is
intended to allow configuration of user identities and their names, intended to allow configuration of user identities and their names,
addresses, and credentials. MIN-ACCESS for all objects is read-only addresses, and credentials. MIN-ACCESS for all objects is read-only
for those implementations that configure through other means, but for those implementations that configure through other means, but
require the ability to monitor user identities. require the ability to monitor user identities.
2. Relationship to Other MIBs 2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580].
3. Relationship to Other MIBs
The identity authentication MIB does not directly address objects The identity authentication MIB does not directly address objects
within other MIBs. The identity address objects contain IPv4, IPv6, within other MIBs. The identity address objects contain IPv4, IPv6,
or other address types, and as such may be indirectly related to or other address types, and as such may be indirectly related to
objects within the IPv4 MIB [RFC1213] [RFC2011] or IPv6 [RFC2465] objects within the IPv4 MIB [RFC1213] [RFC2011] or IPv6 [RFC2465]
MIB. MIB.
This MIB does not cover authorization. This should generally be done This MIB does not cover authorization. This should generally be done
in MIBs that reference identities in this one. It also does not in MIBs that reference identities in this one. It also does not
cover login or authentication failure statistics or notifications, as cover login or authentication failure statistics or notifications, as
these are all fairly application-specific, and not generic enough to these are all fairly application-specific, and not generic enough to
include here. include here.
The user identity objects within this MIB are typically referenced The user identity objects within this MIB are typically referenced
from other MIBs by a RowPointer within that MIB. A MIB containing from other MIBs by a RowPointer within that MIB. A MIB containing
resources for which it requires a list of authorized user identities resources for which it requires a list of authorized user identities
may create such a list, with a single RowPointer within each list may create such a list, with a single RowPointer within each list
element pointing to a user identity within this MIB. This is neither element pointing to a user identity within this MIB. This is neither
required nor restricted by this MIB. required nor restricted by this MIB.
3. Discussion 4. Discussion
This MIB structure is intended to allow the configuration of a list This MIB structure is intended to allow the configuration of a list
of user identities, each with a list of names, addresses, of user identities, each with a list of names, addresses,
credentials, and certificates which when combined will authenticate credentials, and certificates which when combined will authenticate
that identity. that identity.
The authentication MIB is structured around two primary "objects", The authentication MIB is structured around two primary "objects",
the authentication instance, and the identity, which serve as the authentication instance, and the identity, which serve as
containers for the remainder of the objects. This section contains a containers for the remainder of the objects. This section contains a
brief description of the "object" hierarchy and a description of each brief description of the "object" hierarchy and a description of each
object, followed by a discussion of the actual SNMP table structure object, followed by a discussion of the actual SNMP table structure
within the objects. within the objects.
3.1. Authentication MIB Object Model 4.1. Authentication MIB Object Model
The top-level object in this structure is the authentication The top-level object in this structure is the authentication
instance, which "contains" all of the other objects. The indexing instance, which "contains" all of the other objects. The indexing
hierarchy of this MIB looks like: hierarchy of this MIB looks like:
ipsAuthInstance ipsAuthInstance
-- A distinct authentication entity within the managed system. -- A distinct authentication entity within the managed system.
-- Most implementations will have just one of these. -- Most implementations will have just one of these.
ipsAuthIdentity ipsAuthIdentity
-- A user identity, consisting of a set of identity names, -- A user identity, consisting of a set of identity names,
skipping to change at page 5, line 28 skipping to change at page 5, line 5
ipsAuthCredSrp ipsAuthCredSrp
-- SRP-specific attributes -- SRP-specific attributes
ipsAuthCredKerberos ipsAuthCredKerberos
-- Kerberos-specific attributes -- Kerberos-specific attributes
Each identity contains the information necessary to authenticate a Each identity contains the information necessary to authenticate a
particular end-point that wishes to access a service, such as iSCSI. particular end-point that wishes to access a service, such as iSCSI.
An identity can contain multiple names, addresses, and credentials. An identity can contain multiple names, addresses, and credentials.
3.2. ipsAuthInstance 4.2. ipsAuthInstance
The ipsAuthInstanceAttributesTable is the primary table of the The ipsAuthInstanceAttributesTable is the primary table of the
authentication MIB. Every other table entry in this MIB includes the authentication MIB. Every other table entry in this MIB includes the
index of an ipsAuthInstanceAttributesEntry as its primary index. An index of an ipsAuthInstanceAttributesEntry as its primary index. An
authentication instance is basically a managed set of identities. authentication instance is basically a managed set of identities.
Many implementations will include just one authentication instance Many implementations will include just one authentication instance
row in this table. However, there will be cases where multiple rows row in this table. However, there will be cases where multiple rows
in this table may be used: in this table may be used:
skipping to change at page 6, line 5 skipping to change at page 5, line 30
- A set of stackable systems, each with their own set of identities, - A set of stackable systems, each with their own set of identities,
may be managed by a common SNMP agent. Each individual system may be managed by a common SNMP agent. Each individual system
would have its own authentication instance. would have its own authentication instance.
- Multiple protocols, each with their own set of identities, may - Multiple protocols, each with their own set of identities, may
exist within a single system and be managed by a single SNMP agent. exist within a single system and be managed by a single SNMP agent.
In this case, each protocol may have its own authentication In this case, each protocol may have its own authentication
instance. instance.
3.3. ipsAuthIdentity 4.3. ipsAuthIdentity
The ipsAuthIdentAttributesTable contains one entry for each The ipsAuthIdentAttributesTable contains one entry for each
configured user identity. The identity contains only a description configured user identity. The identity contains only a description
of what the identity is used for; its attributes are all contained in of what the identity is used for; its attributes are all contained in
other tables, since they can have multiple values. other tables, since they can have multiple values.
Other MIBs containing lists of users authorized to access a Other MIBs containing lists of users authorized to access a
particular resource should generally contain a RowPointer to the particular resource should generally contain a RowPointer to the
ipsAuthIdentAttributesEntry which will, if authenticated, be allowed ipsAuthIdentAttributesEntry which will, if authenticated, be allowed
access. access.
All other table entries make use of the indices to this table as All other table entries make use of the indices to this table as
their primary indices. their primary indices.
3.4. ipsAuthIdentityName 4.4. ipsAuthIdentityName
The ipsAuthIdentNameAttributesTable contains a list of UTF-8 names, The ipsAuthIdentNameAttributesTable contains a list of UTF-8 names,
each of which belong to, and may be used to identify, a particular each of which belong to, and may be used to identify, a particular
identity in the authIdentity table. identity in the authIdentity table.
Implementations making use of the authentication MIB may identify Implementations making use of the authentication MIB may identify
their resources by names, addresses, or both. A name is typically a their resources by names, addresses, or both. A name is typically a
unique (within the required scope), unchanging identifier for a unique (within the required scope), unchanging identifier for a
resource. It will normally meet some or all of the requirements for a resource. It will normally meet some or all of the requirements for a
Uniform Resource Name [RFC1737], although a name in the context of Uniform Resource Name [RFC1737], although a name in the context of
skipping to change at page 6, line 46 skipping to change at page 6, line 23
An example of an identity name is the iSCSI Name, defined in [ISCSI]. An example of an identity name is the iSCSI Name, defined in [ISCSI].
If this table contains no entries associated with a particular user If this table contains no entries associated with a particular user
identity, the implementation does not need to check any name identity, the implementation does not need to check any name
parameters when authenticating that identity. If the table contains parameters when authenticating that identity. If the table contains
multiple entries associated with a particular user identity, the multiple entries associated with a particular user identity, the
implementation should consider a match with any one of these entries implementation should consider a match with any one of these entries
to be valid. to be valid.
3.5. ipsAuthIdentityAddress 4.5. ipsAuthIdentityAddress
The ipsAuthIdentAddrAttributesTable contains a list of addresses at The ipsAuthIdentAddrAttributesTable contains a list of addresses at
which the identity may be authenticated. For example, an identity which the identity may be authenticated. For example, an identity
may be allowed access to a resource only from a certain IP address, may be allowed access to a resource only from a certain IP address,
or only if its address is in a certain range or set of ranges. or only if its address is in a certain range or set of ranges.
Each entry contains a starting and ending address. If a single Each entry contains a starting and ending address. If a single
address is desired in the list, both starting and ending addresses address is desired in the list, both starting and ending addresses
must be identical. must be identical.
skipping to change at page 7, line 25 skipping to change at page 7, line 5
Matching any address within any range within the list associated with Matching any address within any range within the list associated with
a particular identity is considered to be a valid match. If no a particular identity is considered to be a valid match. If no
entries are present in this list for a given identity, its address is entries are present in this list for a given identity, its address is
not checked during authentication. not checked during authentication.
Netmasks are not supported, since an address range can express the Netmasks are not supported, since an address range can express the
same thing with more flexibility. An application specifying same thing with more flexibility. An application specifying
addresses using network masks may do so, and convert to and from addresses using network masks may do so, and convert to and from
address ranges when reading or writing this MIB. address ranges when reading or writing this MIB.
3.6. ipsAuthCredential 4.6. ipsAuthCredential
The ipsAuthCredentialAttributesTable contains a list of credentials, The ipsAuthCredentialAttributesTable contains a list of credentials,
each of which may authenticate a particular identity. each of which may authenticate a particular identity.
Each credential contains an authentication method to be used, such as Each credential contains an authentication method to be used, such as
CHAP [RFC1994], SRP [RFC2945], or Kerberos [RFC1510]. This attribute CHAP [RFC1994], SRP [RFC2945], or Kerberos [RFC1510]. This attribute
contains an object identifier instead of an enumerated type, allowing contains an object identifier instead of an enumerated type, allowing
other MIBs to add their own authentication methods, without modifying other MIBs to add their own authentication methods, without modifying
this MIB. this MIB.
skipping to change at page 8, line 10 skipping to change at page 7, line 38
Kerberos If the AuthMethod is set to the Kerberos OID, an entry using Kerberos If the AuthMethod is set to the Kerberos OID, an entry using
the same indices as the ipsAuthCredential will exist in the the same indices as the ipsAuthCredential will exist in the
ipsAuthCredKerberos table, which contains the Kerberos ipsAuthCredKerberos table, which contains the Kerberos
principal. principal.
Other If the AuthMethod is set to any OID not defined in this MIB, Other If the AuthMethod is set to any OID not defined in this MIB,
an entry using the same indices as the ipsAuthCredential an entry using the same indices as the ipsAuthCredential
entry should be placed in the other MIB that define whatever entry should be placed in the other MIB that define whatever
attributes are needed for that type of credential. attributes are needed for that type of credential.
3.7. IP, Fibre Channel, and Other Addresses 4.7. IP, Fibre Channel, and Other Addresses
The IP addresses in this MIB are represented by two attributes, one The IP addresses in this MIB are represented by two attributes, one
of type AddressFamilyNumbers, and the other of type AuthAddress. of type AddressFamilyNumbers, and the other of type AuthAddress.
Each address can take on any of the types within the list of address Each address can take on any of the types within the list of address
family numbers; the most likely being IPv4, IPv6, or one of the Fibre family numbers; the most likely being IPv4, IPv6, or one of the Fibre
Channel address types. Channel address types.
The type AuthAddress is an octet string. If the address family is The type AuthAddress is an octet string. If the address family is
IPv4 or IPv6, the format is taken from the InetAddress specified in IPv4 or IPv6, the format is taken from the InetAddress specified in
[RFC3291]. If the address family is one of the Fibre Channel types, [RFC3291]. If the address family is one of the Fibre Channel types,
the format is identical to the FcNameIdOrZero type defined in the format is identical to the FcNameIdOrZero type defined in
[FCMGMT]. [FCMGMT].
3.8. Descriptors: Using OIDs in Place of Enumerated Types 4.8. Descriptors: Using OIDs in Place of Enumerated Types
Some attributes, particularly the authentication method attribute, Some attributes, particularly the authentication method attribute,
would normally require an enumerated type. However, implementations would normally require an enumerated type. However, implementations
will likely need to add new authentication method types of their own, will likely need to add new authentication method types of their own,
without extending this MIB. To make this work, the MIB defines a set without extending this MIB. To make this work, the MIB defines a set
of object identities within ipsAuthDescriptors. Each of these object of object identities within ipsAuthDescriptors. Each of these object
identities is basically an enumerated type. identities is basically an enumerated type.
Attributes that make use of these object identities have a value Attributes that make use of these object identities have a value
which is an OID instead of an enumerated type. These OIDs can either which is an OID instead of an enumerated type. These OIDs can either
indicate the object identities defined in this MIB, or object indicate the object identities defined in this MIB, or object
identities defined elsewhere, such as in an enterprise MIB. Those identities defined elsewhere, such as in an enterprise MIB. Those
implementations that add their own authentication methods should also implementations that add their own authentication methods should also
define a corresponding object identity for each of these methods define a corresponding object identity for each of these methods
within their own enterprise MIB, and return its OID whenever one of within their own enterprise MIB, and return its OID whenever one of
these attributes is using that method. these attributes is using that method.
3.9. Notifications 4.9. Notifications
Monitoring of authentication failures and other notification events Monitoring of authentication failures and other notification events
are outside the scope of this MIB, as they are generally application- are outside the scope of this MIB, as they are generally application-
specific. No notifications are provided or required. specific. No notifications are provided or required.
4. MIB Definitions 5. MIB Definitions
IPS-AUTH-MIB DEFINITIONS ::= BEGIN IPS-AUTH-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Unsigned32, MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Unsigned32,
experimental experimental
FROM SNMPv2-SMI FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus, AutonomousType TEXTUAL-CONVENTION, RowStatus, AutonomousType
FROM SNMPv2-TC FROM SNMPv2-TC
skipping to change at page 27, line 44 skipping to change at page 28, line 5
DESCRIPTION DESCRIPTION
"Write access is not required, and only one of the "Write access is not required, and only one of the
six enumerated values for the RowStatus textual six enumerated values for the RowStatus textual
convention need be supported, specifically: convention need be supported, specifically:
active(1)." active(1)."
::= { ipsAuthCompliances 1 } ::= { ipsAuthCompliances 1 }
END END
5. Security Considerations 6. Security Considerations
SNMPv1 by itself is not a secure environment. Even if the network There are a number of management objects defined in this MIB module
itself is secure (for example by using IPsec), even then, there is no with a MAX-ACCESS clause of read-write and/or read-create. Such
control as to who on the secure network is allowed to access and objects may be considered sensitive or vulnerable in some network
GET/SET (read/change/create/delete) the objects in this MIB. environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations. These are the tables and objects and their
sensitivity/vulnerability:
It is recommended that the implementors consider the security All tables provide the ability to set up which credentials may be
features as provided by the SNMPv3 framework. Specifically, the use used to access services on the managed system, to remove
of the User-based Security Model RFC 2574 [RFC2574] and the View- legitimate credentials (a denial of service), or to remove
based Access Control Model RFC 2575 [RFC2575] is recommended. individual credentials to weaken the requirements for access of a
particular service. In addition, write access may be used to
change CHAP or SRP passwords to a known value. Write access must
always be tightly controlled.
It is then a customer/user responsibility to ensure that the SNMP Some of the readable objects in this MIB module (i.e., objects with a
entity giving access to an instance of this MIB, is properly MAX-ACCESS other than not-accessible) may be considered sensitive or
configured to give access to the objects only to those principals vulnerable in some network environments. It is thus important to
(users) that have legitimate rights to indeed GET or SET control even GET and/or NOTIFY access to these objects and possibly
(change/create/delete) them. to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability:
Read access to this MIB provides the ability to find out which names, All tables provide the ability to find out which names, addresses,
addresses, and credentials would be required to access services on and credentials would be required to access services on the
the managed system. If these credentials are easily spoofed managed system. If these credentials are easily spoofed
(particularly the name or address), read access to the MIB must be (particularly the name or address), read access to the MIB must be
tightly controlled. tightly controlled.
Write access to the MIB provides the ability to set up which SNMP versions prior to SNMPv3 did not include adequate security.
credentials may be used to access services on the managed system, to Even if the network itself is secure (for example by using IPsec),
remove legitimate credentials (a denial of service), or to remove even then, there is no control as to who on the secure network is
individual credentials to weaken the requirements for access of a allowed to access and GET/SET (read/change/create/delete) the objects
particular service. In addition, write access may be used to change in this MIB module.
CHAP or SRP passwords to a known value. Write access must always be
tightly controlled.
6. Normative References
[RFC2571] D. Harrington, R. Presuhn, and B. Wijnen, "An Architecture It is RECOMMENDED that implementors consider the security features as
for Describing SNMP Management Frameworks", RFC 2571, April provided by the SNMPv3 framework (see [RFC3410], section 8),
1999. including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
[RFC1155] M. Rose and K. McCloghrie, "Structure and Identification of Further, deployment of SNMP versions prior to SNMPv3 is NOT
Management Information for TCP/IP-based Internets", STD 16, RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
RFC 1155, May 1990. enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
[RFC1212] M. Rose and K. McCloghrie, "Concise MIB Definitions", STD 7. Normative References
16, RFC 1212, March 1991.
[RFC2578] K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M. [RFC2578] K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M.
Rose, and S. Waldbusser, "Structure of Management Rose, and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999. 1999.
[RFC1215] M. Rose, "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.
[RFC2579] K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M. [RFC2579] K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M.
Rose, and S. Waldbusser, "Textual Conventions for SMIv2", Rose, and S. Waldbusser, "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999. STD 58, RFC 2579, April 1999.
[RFC2580] K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M. [RFC2580] K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, M.
Rose, and S. Waldbusser, "Conformance Statements for SMIv2", Rose, and S. Waldbusser, "Conformance Statements for SMIv2",
STD 58, RFC 2580, April 1999. STD 58, RFC 2580, April 1999.
[RFC1157] J. Case, M. Fedor, M. Schoffstall, and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, May 1990.
[RFC3291] M. Daniele, et. al., "Textual Conventions for Internet [RFC3291] M. Daniele, et. al., "Textual Conventions for Internet
Network Addresses", RFC 3291, May 2002. Network Addresses", RFC 3291, May 2002.
[IANA-AF] IANA, "IANA Address Family Numbers MIB", [IANA-AF] IANA, "IANA Address Family Numbers MIB",
http://www.iana.org/assignments/ianaaddressfamilynumbers-mib http://www.iana.org/assignments/ianaaddressfamilynumbers-mib
[RFC1213] K. McCloghrie, M. Rose, "Management Information Base for [RFC1213] K. McCloghrie, M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets:MIB-II", March Network Management of TCP/IP-based internets:MIB-II", March
1991. 1991.
[RFC2011] K. McCloghrie, "SNMPv2 Management Information Base for the [RFC2011] K. McCloghrie, "SNMPv2 Management Information Base for the
Internet Protocol using SMIv2", November 1996. Internet Protocol using SMIv2", November 1996.
[RFC2465] D. Haskin, S. Onishi, "Management Information Base for IP [RFC2465] D. Haskin, S. Onishi, "Management Information Base for IP
Version 6: Textual Conventions and General Group", December Version 6: Textual Conventions and General Group", December
1998. 1998.
7. Informative References 8. Informative References
[RFC1901] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, January
1996.
[RFC1906] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser,
"Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1906, January 1996.
[RFC2572] J. Case, D. Harrington, R. Presuhn, and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, April 1999.
[RFC2574] U. Blumenthal, and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2574, April 1999.
[RFC1905] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser,
"Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC2573] D. Levi, P. Meyer, and B. Stewart, "SNMPv3 Applications",
RFC 2573, April 1999.
[RFC2575] B. Wijnen, R. Presuhn, and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management
Protocol (SNMP)", RFC 2575, April 1999.
[RFC2570] J. Case, R. Mundy, D. Partain, and B. Stewart, "Introduction
to Version 3 of the Internet-standard Network Management
Framework", RFC 2570, April 1999.
[RFC2012] K. McCloghrie, "SNMPv2 Management Information Base for the [RFC3410] J. Case, R. Mundy, D. Partain, and B. Stewart, "Introduction
Transmission Control Protocol using SMIv2", RFC 2012, and Applicability Statements for Internet-Standard
November 1996. Management Framework", RFC 3410, December 2002.
[ISCSI] Satran, J., et. al., "iSCSI", draft-ietf-ips-iSCSI-17, [ISCSI] Satran, J., et. al., "iSCSI", Work in Progress, draft-ietf-
September 2002. ips-iscsi-20, January 2003.
[RFC1737] K. Sollins, L. Masinter, "Functional Requirements for [RFC1737] K. Sollins, L. Masinter, "Functional Requirements for
Uniform Resource Names", December 1994. Uniform Resource Names", December 1994.
[RFC1994] W. Simpson, "PPP Challenge Handshake Authentication Protocol [RFC1994] W. Simpson, "PPP Challenge Handshake Authentication Protocol
(CHAP)", August 1996. (CHAP)", August 1996.
[RFC1510] J. Kohl, C. Neuman, "The Kerberos Network Authentication [RFC1510] J. Kohl, C. Neuman, "The Kerberos Network Authentication
Service (V5)", September 1993. Service (V5)", September 1993.
[RFC2945] T. Wu, "The SRP Authentication and Key Exchange System", [RFC2945] T. Wu, "The SRP Authentication and Key Exchange System",
September 2000. September 2000.
[FCMGMT] K. McCloghrie, "Fibre Channel Management MIB", draft-ietf- [FCMGMT] K. McCloghrie, "Fibre Channel Management MIB", Work in
ips-fcmgmt-mib-01, February 2002. Progress, draft-ietf-ips-fcmgmt-mib-03, October 2002.
[X.509] ITU-T Recommendation X.509 (1997 E), "Information Technology
- Open Systems Interconnection - The Directory:
Authentication Framework", June 1997.
8. Authors' Addresses 9. Authors' Addresses
Mark Bakke Mark Bakke
Postal: Cisco Systems, Inc Postal: Cisco Systems, Inc
6450 Wedgwood Road, Suite 130 6450 Wedgwood Road, Suite 130
Maple Grove, MN Maple Grove, MN
USA 55311 USA 55311
Tel: +1 763-398-1000 Tel: +1 763-398-1000
Fax: +1 763-398-1001 Fax: +1 763-398-1001
skipping to change at page 31, line 27 skipping to change at page 30, line 39
Jim Muchow Jim Muchow
Postal: Cisco Systems, Inc Postal: Cisco Systems, Inc
6450 Wedgwood Road, Suite 130 6450 Wedgwood Road, Suite 130
Maple Grove, MN Maple Grove, MN
USA 55311 USA 55311
Tel: +1 763-398-1000 Tel: +1 763-398-1000
Fax: +1 763-398-1001 Fax: +1 763-398-1001
E-mail: jmuchow@cisco.com" E-mail: jamesdmuchow@yahoo.com"
9. Full Copyright Notice 10. IPR Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made
available for publication and any assurances of licenses to be made
available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
11. Full Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/