Request for Comments: 4545 Cisco Systems
Category: Standards Track J. Muchow
Qlogic Corp.
May 2006
Definitions of Managed Objects for
IP Storage User Identity Authorization
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing user identities and
the names, addresses, and credentials required manage access control,
for use with various protocols. This document was motivated by the
need for the configuration of authorized user identities for the
iSCSI protocol, but has been extended to be useful for other
protocols that have similar requirements. It is important to note
that this MIB module provides only the set of identities to be used
within access lists; it is the responsibility of other MIB modules
making use of this one to tie them to their own access lists or other
authorization control methods.
Table of Contents
1. Introduction ....................................................3
2. Specification of Requirements ...................................3
3. The Internet-Standard Management Framework ......................3
4. Relationship to Other MIB Modules ...............................3
5. Relationship to the USM MIB Module ..............................4
6. Relationship to SNMP Contexts ...................................5
7. Discussion ......................................................5
7.1. Authorization MIB Object Model .............................5
7.2. ipsAuthInstance ............................................6
7.3. ipsAuthIdentity ............................................7
7.4. ipsAuthIdentityName ........................................7
7.5. ipsAuthIdentityAddress .....................................8
7.6. ipsAuthCredential ..........................................8
7.7. IP, Fibre Channel, and Other Addresses .....................9
7.8. Descriptors: Using OIDs in Place of Enumerated Types ......10
7.9. Notifications .............................................10
8. MIB Definitions ................................................11
9. Security Considerations ........................................35
9.1. MIB Security Considerations ...............................35
9.2. Other Security Considerations .............................38
10. IANA Considerations ...........................................40
11. Normative References ..........................................40
12. Informative References ........................................41
13. Acknowledgements ..............................................41
1. Introduction
This MIB module will be used to configure and/or look at the
configuration of user identities and their credential information.
For the purposes of this MIB module, a "user" identity does not need
to be an actual person; a user can also be a host, an application, a
cluster of hosts, or any other identifiable entity that can be
authorized to access a resource.
Most objects in this MIB module have a MAX-ACCESS of read-create;
this module is intended to allow configuration of user identities and
their names, addresses, and credentials. MIN-ACCESS for all objects
is read-only for those implementations that configure through other
means, but require the ability to monitor user identities.
2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. 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].
4. Relationship to Other MIB Modules
The IPS-AUTH-MIB module does not directly address objects within
other modules. The identity address objects contain IPv4, IPv6, or
other address types, and as such they may be indirectly related to
objects within the IP [RFC4293] MIB module.
This MIB module does not provide actual authorization or access
control lists; it provides a means to identify entities that can be
included in other authorization lists. This should generally be done
in MIB modules that reference identities in this one. It also does
not cover login or authentication failure statistics or
notifications, as these are all fairly application specific and are
not generic enough to be included here.
The user identity objects within this module are typically referenced
from other modules by a RowPointer within that module. A module
containing resources for which it requires a list of authorized user
identities may create such a list, with a single RowPointer within
each list element pointing to a user identity within this module.
This is neither required nor restricted by this MIB module.
5. Relationship to the USM MIB Module
The User-based Security Model (USM) [RFC3414] also defines the
concept of a user, defining authentication and privacy protocols and
their credentials. The definition of USM includes the SNMP-USER-
BASED-SM-MIB module allows configuration of SNMPv3 user credentials
to protect SNMPv3 messages. Although USM’s users are not related to
the user identities managed by the IPS-AUTH-MIB module defined in
this document, USM will often be implemented on the same system as
the IPS-AUTH-MIB module, with the SNMP-USER-BASED-SM-MIB module used
to manage the security protecting SNMPv3 messages, including those
that access the IPS-AUTH-MIB module.
The term "user" in this document is distinct from an SNMPv3 user and
is intended to include, but is not limited to, users of IP storage
devices. A "user" in this document is a collection of user names
(unique identifiers), user addresses, and credentials that can be
used together to determine whether an entity should be allowed access
to a resource. Each user can have multiple names, addresses, and
credentials. As a result, this MIB module is particularly suited to
managing users of storage resources, which are typically given access
control lists consisting of potentially multiple identifiers,
addresses, and credentials. This MIB module provides for
authorization lists only and does not include setting of data privacy
parameters.
In contrast, an SNMPv3 user as defined in [RFC3414] has exactly one
user-name, one authentication protocol, and one privacy protocol,
along with their associated information and SNMP-specific
information, such as an engine ID. These objects are defined to
support exactly the information needed for SNMPv3 security.
For the remainder of this document, the term "user" means an IPS-
AUTH-MIB user identity.
6. Relationship to SNMP Contexts
Each non-scalar object in the IPS-AUTH-MIB module is indexed first by
an instance. Each instance is a collection of identities that can be
used to authorize access to a resource. The use of an instance works
well with partitionable or hierarchical devices and fits in logically
with other management schemes. Instances do not replace SNMP
contexts; however, they do provide a very simple way to assign a
collection of identities within a device to one or more SNMP
contexts, without having to do so for each identity’s row.
7. Discussion
This MIB module structure is intended to allow the configuration of a
list of user identities, each with a list of names, addresses,
credentials, and certificates that, when combined, will distinguish
that identity.
The IPS-AUTH-MIB module is structured around two primary "objects",
the authorization instance and the identity, which serve as
containers for the remainder of the objects. This section contains a
brief description of the "object" hierarchy and a description of each
object, followed by a discussion of the actual SNMP table structure
within the objects.
7.1. Authorization MIB Object Model
The top-level object in this structure is the authorization instance,
which "contains" all of the other objects. The indexing hierarchy of
this module looks like:
ipsAuthInstance
-- A distinct authorization entity within the managed system.
-- Most implementations will have just one of these.
ipsAuthIdentity
-- A user identity, consisting of a set of identity names,
-- addresses, and credentials reflected in the following
-- objects:
ipsAuthIdentityName
-- A name for a user identity. A name should be globally
-- unique, and unchanging over time. Some protocols may
-- not require this one.
ipsAuthIdentityAddress
-- An address range, typically but not necessarily an
-- IPv4, IPv6, or Fibre Channel address range, at which
-- the identity is allowed to reside.
ipsAuthCredential
-- A single credential, such as a CHAP username,
-- which can be used to verify the identity.
ipsAuthCredChap
-- CHAP-specific attributes for an ipsAuthCredential
ipsAuthCredSrp
-- SRP-specific attributes
ipsAuthCredKerberos
-- Kerberos-specific attributes
Each identity contains the information necessary to identify a
particular end-point that wishes to access a service, such as iSCSI.
An identity can contain multiple names, addresses, and credentials.
Each of these names, addresses, and credentials exists in its own
row. If multiple rows of one of these three types are present, they
are treated in an "OR" fashion; an entity to be authorized need only
match one of the rows. If rows of different types are present (e.g.,
a name and an address), these are treated in an "AND" fashion; an
entity to be authorized must match at least one row from each
category. If there are no rows present of a category, this category
is ignored.
For example, if an ipsAuthIdentity contains two rows of
ipsAuthIdentityAddress, one row of ipsAuthCredential, and no rows of
ipsAuthIdentityName, an entity must match the Credential row and at
least one of the two Address rows to match the identity.
Index values such as ipsAuthInstIndex and ipsAuthIdentIndex are
referenced in multiple tables, and rows can be added and deleted. An
implementation should therefore attempt to keep all index values
persistent across reboots; index values for rows that have been
deleted must not be reused before a reboot.
7.2. ipsAuthInstance
The ipsAuthInstanceAttributesTable is the primary table of the IPS-
AUTH-MIB module. Every other table entry in this module includes the
index of an ipsAuthInstanceAttributesEntry as its primary index. An
authorization instance is basically a managed set of identities.
Many implementations will include just one authorization instance row
in this table. However, there will be cases where multiple rows in
this table may be used:
- A large system may be "partitioned" into multiple, distinct
virtual systems, perhaps sharing the SNMP agent but not their
lists of identities. Each virtual system would have its own
authorization instance.
- A set of stackable systems, each with its own set of identities,
may be represented by a common SNMP agent. Each individual
system would have its own authorization instance.
- Multiple protocols, each with its own set of identities, may
exist within a single system and be represented by a single SNMP
agent. In this case, each protocol may have its own
authorization instance.
An entry in this table is often referenced by its name
(ipsAuthInstDescr), which should be displayed to the user by the
management station. When an implementation supports only one entry
in this table, the description may be returned as a zero-length
string.
7.3. ipsAuthIdentity
The ipsAuthIdentAttributesTable contains one entry for each
configured user identity. The identity contains only a description
of what the identity is used for; its attributes are all contained in
other tables, since they can each have multiple values.
Other MIB modules containing lists of users authorized to access a
particular resource should generally contain a RowPointer to the
ipsAuthIdentAttributesEntry that will, if authenticated, be allowed
access to the resource.
All other table entries make use of the indices to this table as
their primary indices.
7.4. ipsAuthIdentityName
The ipsAuthIdentNameAttributesTable contains a list of UTF-8 names,
each of which belongs to, and may be used to identify, a particular
identity in the authIdentity table.
Implementations making use of the IPS-AUTH-MIB module may identify
their resources by names, addresses, or both. A name is typically a
unique (within the required scope), unchanging identifier 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
this MIB module does not need to be a URN. Identifiers that
typically change over time should generally be placed into the
ipsAuthIdentityAddress table; names that have no uniqueness
properties should usually be placed into the description attribute
for the identity.
An example of an identity name is the iSCSI Name, defined in
[RFC3720]. Any other MIB module defining names to be used as
ipsAuthIdentityName objects should specify how its names are unique,
and the domain within which they are unique.
If this table contains no entries associated with a particular user
identity, the implementation does not need to check any name
parameters when verifying that identity. If the table contains
multiple entries associated with a particular user identity, the
implementation should consider a match with any one of these entries
to be valid.
7.5. ipsAuthIdentityAddress
The ipsAuthIdentAddrAttributesTable contains a list of addresses at
which the identity may reside. For example, an identity 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.
Each entry contains a starting and ending address. If a single
address is desired in the list, both starting and ending addresses
must be identical.
Each entry contains an AddrType attribute. This attribute contains
an enumeration registered as an IANA Address Family type [IANA-AF].
Although many implementations will use IPv4 or IPv6 address types for
these entries, any IANA-registered type may be used, as long as it
makes sense to the application.
Matching any address within any range within the list associated with
a particular identity is considered a valid match. If no entries are
present in this list for a given identity, its address is
automatically assumed to match the identity.
Netmasks are not supported, since an address range can express the
same thing with more flexibility. An application specifying
addresses using network masks may do so, and convert to and from
address ranges when reading or writing this MIB module.
7.6. ipsAuthCredential
The ipsAuthCredentialAttributesTable contains a list of credentials,
each of which may be used to verify a particular identity.
Each credential contains an authentication method to be used, such as
CHAP [RFC1994], SRP [RFC2945], or Kerberos [RFC4120]. This attribute
contains an object identifier instead of an enumerated type, allowing
other MIB modules to add their own authentication methods, without
modifying this MIB module.
For each entry in this table, there will exist an entry in another
table containing its attributes. The table in which to place the
entry depends on the AuthMethod attribute:
CHAP If the AuthMethod is set to the CHAP OID, an entry using the
same indices as the ipsAuthCredential will exist in the
ipsAuthCredChap table, which contains the CHAP username.
SRP If the AuthMethod is set to the SRP OID, an entry using the
same indices as the ipsAuthCredential will exist in the
ipsAuthCredSrp table, which contains the SRP username.
Kerberos If the AuthMethod is set to the Kerberos OID, an entry using
the same indices as the ipsAuthCredential will exist in the
ipsAuthCredKerberos table, which contains the Kerberos
principal.
Other If the AuthMethod is set to any OID not defined in this
module, an entry using the same indices as the
ipsAuthCredential entry should be placed in the other module
that define whatever attributes are needed for that type of
credential.
An additional credential type can be added to this MIB module by
defining a new OID in the ipsAuthMethodTypes subtree, and defining a
new table specific to that credential type.
7.7. IP, Fibre Channel, and Other Addresses
The IP addresses in this MIB module are represented by two
attributes, one of type AddressFamilyNumbers, and the other of type
AuthAddress. 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 Channel address types.
The type AuthAddress is an octet string. If the address family is
IPv4 or IPv6, the format is taken from the InetAddress specified in
[RFC4001]. If the address family is one of the Fibre Channel types,
the format is identical to the FcNameIdOrZero type defined in
[RFC4044].
7.8. Descriptors: Using OIDs in Place of Enumerated Types
Some attributes, particularly the authentication method attribute,
would normally require an enumerated type. However, implementations
will likely need to add new authentication method types of their own,
without extending this MIB module. To make this work, this module
defines a set of object identities within ipsAuthDescriptors. Each
of these object identities is basically an enumerated type.
Attributes that make use of these object identities have a value that
is an OID instead of an enumerated type. These OIDs can either
indicate the object identities defined in this module, or object
identities defined elsewhere, such as in an enterprise MIB module.
Those implementations that add their own authentication methods
should also define a corresponding object identity for each of these
methods within their own enterprise MIB module, and return its OID
whenever one of these attributes is using that method.
7.9. Notifications
Monitoring of authentication failures and other notification events
are outside the scope of this MIB module, as they are generally
application specific. No notifications are provided or required.
8. MIB Definitions
IPS-AUTH-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Unsigned32,
mib-2
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus, AutonomousType, StorageType
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB -- RFC 3411
AddressFamilyNumbers
FROM IANA-ADDRESS-FAMILY-NUMBERS-MIB
;
ipsAuthMibModule MODULE-IDENTITY
LAST-UPDATED "200605220000Z" -- May 22, 2006
ORGANIZATION "IETF IPS Working Group"
CONTACT-INFO
"
Mark Bakke
Postal: Cisco Systems, Inc
7900 International Drive, Suite 400
Bloomington, MN
USA 55425
E-mail: mbakke@cisco.com
James Muchow
Postal: Qlogic Corp.
6321 Bury Dr.
Eden Prairie, MN
USA 55346
E-Mail: james.muchow@qlogic.com"
DESCRIPTION
"The IP Storage Authorization MIB module.
Copyright (C) The Internet Society (2006). This version of
this MIB module is part of RFC 4545; see the RFC itself for
full legal notices."
REVISION "200605220000Z" -- May 22, 2006
DESCRIPTION
"Initial version of the IP Storage Authentication MIB module,
published as RFC 4545"
::= { mib-2 141 }
ipsAuthNotifications OBJECT IDENTIFIER ::= { ipsAuthMibModule 0 }
ipsAuthObjects OBJECT IDENTIFIER ::= { ipsAuthMibModule 1 }
ipsAuthConformance OBJECT IDENTIFIER ::= { ipsAuthMibModule 2 }
-- Textual Conventions
IpsAuthAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"IP Storage requires the use of address information
that uses not only the InetAddress type defined in the
INET-ADDRESS-MIB, but also Fibre Channel type defined
in the Fibre Channel Management MIB. Although these
address types are recognized in the IANA Address Family
Numbers MIB, the addressing mechanisms have not been
merged into a well-known, common type. This data type,
the IpsAuthAddress, performs the merging for this MIB
module.
The formats of objects of this type are determined by
a corresponding object with syntax AddressFamilyNumbers,
and thus every object defined using this TC must
identify the object with syntax AddressFamilyNumbers
that specifies its type.
The syntax and semantics of this object depend on the
identified AddressFamilyNumbers object as follows:
AddressFamilyNumbers this object
==================== ===========
ipV4(1) restricted to the same syntax and
semantics as the InetAddressIPv4 TC.
ipV6(2) restricted to the same syntax and
semantics as the InetAddressIPv6 TC.