diff options
Diffstat (limited to 'doc/rfc/rfc4545.txt')
| -rw-r--r-- | doc/rfc/rfc4545.txt | 2411 |
1 files changed, 2411 insertions, 0 deletions
diff --git a/doc/rfc/rfc4545.txt b/doc/rfc/rfc4545.txt new file mode 100644 index 0000000..a829a3c --- /dev/null +++ b/doc/rfc/rfc4545.txt @@ -0,0 +1,2411 @@ + + + + + + +Network Working Group M. Bakke +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. + + + + + + + + + + + + + + + +Bakke & Muchow Standards Track [Page 1] + +RFC 4545 IPS Authorization MIB May 2006 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + +Bakke & Muchow Standards Track [Page 2] + +RFC 4545 IPS Authorization MIB May 2006 + + +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 + + + +Bakke & Muchow Standards Track [Page 3] + +RFC 4545 IPS Authorization MIB May 2006 + + + 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. + + + + + + + +Bakke & Muchow Standards Track [Page 4] + +RFC 4545 IPS Authorization MIB May 2006 + + +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, + + + +Bakke & Muchow Standards Track [Page 5] + +RFC 4545 IPS Authorization MIB May 2006 + + + -- 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. + + + + +Bakke & Muchow Standards Track [Page 6] + +RFC 4545 IPS Authorization MIB May 2006 + + + - 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. + + + + + +Bakke & Muchow Standards Track [Page 7] + +RFC 4545 IPS Authorization MIB May 2006 + + + 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. + + + + + + + + +Bakke & Muchow Standards Track [Page 8] + +RFC 4545 IPS Authorization MIB May 2006 + + + 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]. + + + + + +Bakke & Muchow Standards Track [Page 9] + +RFC 4545 IPS Authorization MIB May 2006 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bakke & Muchow Standards Track [Page 10] + +RFC 4545 IPS Authorization MIB May 2006 + + +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." + + + +Bakke & Muchow Standards Track [Page 11] + +RFC 4545 IPS Authorization MIB May 2006 + + + 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. + + fibreChannelWWPN (22) + & fibreChannelWWNN(23) restricted to the same syntax and + semantics as the FcNameIdOrZero TC. + + Types other than the above should not be used unless + + + +Bakke & Muchow Standards Track [Page 12] + +RFC 4545 IPS Authorization MIB May 2006 + + + the corresponding format of the IpsAuthAddress object is + further specified (e.g., in a future revision of this TC)." + REFERENCE + "IANA-ADDRESS-FAMILY-NUMBERS-MIB; + INET-ADDRESS-MIB (RFC 4001); + FC-MGMT-MIB (RFC 4044)." + SYNTAX OCTET STRING (SIZE(0..255)) + + --****************************************************************** + + ipsAuthDescriptors OBJECT IDENTIFIER ::= { ipsAuthObjects 1 } + + ipsAuthMethodTypes OBJECT-IDENTITY + STATUS current + DESCRIPTION + "Registration point for Authentication Method Types." + REFERENCE "RFC 3720, iSCSI Protocol Specification." + ::= { ipsAuthDescriptors 1 } + + ipsAuthMethodNone OBJECT-IDENTITY + STATUS current + DESCRIPTION + "The authoritative identifier when no authentication + method is used." + REFERENCE "RFC 3720, iSCSI Protocol Specification." + ::= { ipsAuthMethodTypes 1 } + + ipsAuthMethodSrp OBJECT-IDENTITY + STATUS current + DESCRIPTION + "The authoritative identifier when the authentication + method is SRP." + REFERENCE "RFC 3720, iSCSI Protocol Specification." + ::= { ipsAuthMethodTypes 2 } + + ipsAuthMethodChap OBJECT-IDENTITY + STATUS current + DESCRIPTION + "The authoritative identifier when the authentication + method is CHAP." + REFERENCE "RFC 3720, iSCSI Protocol Specification." + ::= { ipsAuthMethodTypes 3 } + + ipsAuthMethodKerberos OBJECT-IDENTITY + STATUS current + DESCRIPTION + "The authoritative identifier when the authentication + method is Kerberos." + + + +Bakke & Muchow Standards Track [Page 13] + +RFC 4545 IPS Authorization MIB May 2006 + + + REFERENCE "RFC 3720, iSCSI Protocol Specification." + ::= { ipsAuthMethodTypes 4 } + + --****************************************************************** + + ipsAuthInstance OBJECT IDENTIFIER ::= { ipsAuthObjects 2 } + + -- Instance Attributes Table + + ipsAuthInstanceAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpsAuthInstanceAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of Authorization instances present on the system." + ::= { ipsAuthInstance 2 } + + ipsAuthInstanceAttributesEntry OBJECT-TYPE + SYNTAX IpsAuthInstanceAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing management information + applicable to a particular Authorization instance." + INDEX { ipsAuthInstIndex } + ::= { ipsAuthInstanceAttributesTable 1 } + + IpsAuthInstanceAttributesEntry ::= SEQUENCE { + ipsAuthInstIndex Unsigned32, + ipsAuthInstDescr SnmpAdminString, + ipsAuthInstStorageType StorageType + } + + ipsAuthInstIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An arbitrary integer used to uniquely identify a + particular authorization instance. This index value + must not be modified or reused by an agent unless + a reboot has occurred. An agent should attempt to + keep this value persistent across reboots." + ::= { ipsAuthInstanceAttributesEntry 1 } + + ipsAuthInstDescr OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-write + + + +Bakke & Muchow Standards Track [Page 14] + +RFC 4545 IPS Authorization MIB May 2006 + + + STATUS current + DESCRIPTION + "A character string, determined by the implementation to + describe the authorization instance. When only a single + instance is present, this object may be set to the + zero-length string; with multiple authorization + instances, it must be set to a unique value in an + implementation-dependent manner to describe the purpose + of the respective instance. If this is deployed in a + master agent with more than one subagent implementing + this MIB module, the master agent is responsible for + ensuring that this object is unique across all + subagents." + ::= { ipsAuthInstanceAttributesEntry 2 } + + ipsAuthInstStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The storage type for all read-write objects within this + row. Rows in this table are always created via an + external process, and may have a storage type of readOnly + or permanent. Conceptual rows having the value 'permanent' + need not allow write access to any columnar objects in + the row. + + If this object has the value 'volatile', modifications + to read-write objects in this row are not persistent + across reboots. If this object has the value + 'nonVolatile', modifications to objects in this row + are persistent. + + An implementation may choose to allow this object + to be set to either 'nonVolatile' or 'volatile', + allowing the management application to choose this + behavior." + DEFVAL { volatile } + ::= { ipsAuthInstanceAttributesEntry 3 } + + ipsAuthIdentity OBJECT IDENTIFIER ::= { ipsAuthObjects 3 } + + -- User Identity Attributes Table + + ipsAuthIdentAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpsAuthIdentAttributesEntry + MAX-ACCESS not-accessible + STATUS current + + + +Bakke & Muchow Standards Track [Page 15] + +RFC 4545 IPS Authorization MIB May 2006 + + + DESCRIPTION + "A list of user identities, each belonging to a + particular ipsAuthInstance." + ::= { ipsAuthIdentity 1 } + + ipsAuthIdentAttributesEntry OBJECT-TYPE + SYNTAX IpsAuthIdentAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing management information + describing a user identity within an authorization + instance on this node." + INDEX { ipsAuthInstIndex, ipsAuthIdentIndex } + ::= { ipsAuthIdentAttributesTable 1 } + + IpsAuthIdentAttributesEntry ::= SEQUENCE { + ipsAuthIdentIndex Unsigned32, + ipsAuthIdentDescription SnmpAdminString, + ipsAuthIdentRowStatus RowStatus, + ipsAuthIdentStorageType StorageType + } + + ipsAuthIdentIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An arbitrary integer used to uniquely identify a + particular identity instance within an authorization + instance present on the node. This index value + must not be modified or reused by an agent unless + a reboot has occurred. An agent should attempt to + keep this value persistent across reboots." + ::= { ipsAuthIdentAttributesEntry 1 } + + ipsAuthIdentDescription OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A character string describing this particular identity." + ::= { ipsAuthIdentAttributesEntry 2 } + + ipsAuthIdentRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + + + +Bakke & Muchow Standards Track [Page 16] + +RFC 4545 IPS Authorization MIB May 2006 + + + DESCRIPTION + "This field allows entries to be dynamically added and + removed from this table via SNMP. When adding a row to + this table, all non-Index/RowStatus objects must be set. + Rows may be discarded using RowStatus. The value of + ipsAuthIdentDescription may be set while + ipsAuthIdentRowStatus is 'active'." + ::= { ipsAuthIdentAttributesEntry 3 } + + ipsAuthIdentStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The storage type for all read-create objects in this row. + Rows in this table that were created through an external + process may have a storage type of readOnly or permanent. + Conceptual rows having the value 'permanent' need not + allow write access to any columnar objects in the row." + DEFVAL { nonVolatile } + ::= { ipsAuthIdentAttributesEntry 4 } + + ipsAuthIdentityName OBJECT IDENTIFIER ::= { ipsAuthObjects 4 } + + -- User Initiator Name Attributes Table + + ipsAuthIdentNameAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpsAuthIdentNameAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of unique names that can be used to positively + identify a particular user identity." + ::= { ipsAuthIdentityName 1 } + + ipsAuthIdentNameAttributesEntry OBJECT-TYPE + SYNTAX IpsAuthIdentNameAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing management information + applicable to a unique identity name, which can be used + to identify a user identity within a particular + authorization instance." + INDEX { ipsAuthInstIndex, ipsAuthIdentIndex, + ipsAuthIdentNameIndex } + ::= { ipsAuthIdentNameAttributesTable 1 } + + + + +Bakke & Muchow Standards Track [Page 17] + +RFC 4545 IPS Authorization MIB May 2006 + + + IpsAuthIdentNameAttributesEntry ::= SEQUENCE { + ipsAuthIdentNameIndex Unsigned32, + ipsAuthIdentName SnmpAdminString, + ipsAuthIdentNameRowStatus RowStatus, + ipsAuthIdentNameStorageType StorageType + } + + ipsAuthIdentNameIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An arbitrary integer used to uniquely identify a + particular identity name instance within an + ipsAuthIdentity within an authorization instance. + This index value must not be modified or reused by + an agent unless a reboot has occurred. An agent + should attempt to keep this value persistent across + reboots." + ::= { ipsAuthIdentNameAttributesEntry 1 } + + ipsAuthIdentName OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A character string that is the unique name of an + identity that may be used to identify this ipsAuthIdent + entry." + ::= { ipsAuthIdentNameAttributesEntry 2 } + + ipsAuthIdentNameRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This field allows entries to be dynamically added and + removed from this table via SNMP. When adding a row to + this table, all non-Index/RowStatus objects must be set. + Rows may be discarded using RowStatus. The value of + ipsAuthIdentName may be set when this value is 'active'." + ::= { ipsAuthIdentNameAttributesEntry 3 } + + ipsAuthIdentNameStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + + + +Bakke & Muchow Standards Track [Page 18] + +RFC 4545 IPS Authorization MIB May 2006 + + + "The storage type for all read-create objects in this row. + Rows in this table that were created through an external + process may have a storage type of readOnly or permanent. + Conceptual rows having the value 'permanent' need not + allow write access to any columnar objects in the row." + DEFVAL { nonVolatile } + ::= { ipsAuthIdentNameAttributesEntry 4 } + + ipsAuthIdentityAddress OBJECT IDENTIFIER ::= { ipsAuthObjects 5 } + + -- User Initiator Address Attributes Table + + ipsAuthIdentAddrAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpsAuthIdentAddrAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of address ranges that are allowed to serve + as the endpoint addresses of a particular identity. + An address range includes a starting and ending address + and an optional netmask, and an address type indicator, + which can specify whether the address is IPv4, IPv6, + FC-WWPN, or FC-WWNN." + ::= { ipsAuthIdentityAddress 1 } + + ipsAuthIdentAddrAttributesEntry OBJECT-TYPE + SYNTAX IpsAuthIdentAddrAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing management information + applicable to an address range that is used as part + of the authorization of an identity + within an authorization instance on this node." + INDEX { ipsAuthInstIndex, ipsAuthIdentIndex, + ipsAuthIdentAddrIndex } + ::= { ipsAuthIdentAddrAttributesTable 1 } + + IpsAuthIdentAddrAttributesEntry ::= SEQUENCE { + ipsAuthIdentAddrIndex Unsigned32, + ipsAuthIdentAddrType AddressFamilyNumbers, + ipsAuthIdentAddrStart IpsAuthAddress, + ipsAuthIdentAddrEnd IpsAuthAddress, + ipsAuthIdentAddrRowStatus RowStatus, + ipsAuthIdentAddrStorageType StorageType + } + + ipsAuthIdentAddrIndex OBJECT-TYPE + + + +Bakke & Muchow Standards Track [Page 19] + +RFC 4545 IPS Authorization MIB May 2006 + + + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An arbitrary integer used to uniquely identify a + particular ipsAuthIdentAddress instance within an + ipsAuthIdentity within an authorization instance + present on the node. + This index value must not be modified or reused by + an agent unless a reboot has occurred. An agent + should attempt to keep this value persistent across + reboots." + ::= { ipsAuthIdentAddrAttributesEntry 1 } + + ipsAuthIdentAddrType OBJECT-TYPE + SYNTAX AddressFamilyNumbers + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The address types used in the ipsAuthIdentAddrStart + and ipsAuthAddrEnd objects. This type is taken + from the IANA address family types." + ::= { ipsAuthIdentAddrAttributesEntry 2 } + + ipsAuthIdentAddrStart OBJECT-TYPE + SYNTAX IpsAuthAddress + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The starting address of the allowed address range. + The format of this object is determined by + ipsAuthIdentAddrType." + ::= { ipsAuthIdentAddrAttributesEntry 3 } + + ipsAuthIdentAddrEnd OBJECT-TYPE + SYNTAX IpsAuthAddress + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The ending address of the allowed address range. + If the ipsAuthIdentAddrEntry specifies a single + address, this shall match the ipsAuthIdentAddrStart. + The format of this object is determined by + ipsAuthIdentAddrType." + ::= { ipsAuthIdentAddrAttributesEntry 4 } + + ipsAuthIdentAddrRowStatus OBJECT-TYPE + SYNTAX RowStatus + + + +Bakke & Muchow Standards Track [Page 20] + +RFC 4545 IPS Authorization MIB May 2006 + + + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This field allows entries to be dynamically added and + removed from this table via SNMP. When adding a row to + this table, all non-Index/RowStatus objects must be set. + Rows may be discarded using RowStatus. The values of + ipsAuthIdentAddrStart and ipsAuthIdentAddrEnd may be set + when this value is 'active'. The value of + ipsAuthIdentAddrType may not be set when this value is + 'active'." + ::= { ipsAuthIdentAddrAttributesEntry 5 } + + ipsAuthIdentAddrStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The storage type for all read-create objects in this row. + Rows in this table that were created through an external + process may have a storage type of readOnly or permanent. + Conceptual rows having the value 'permanent' need not + allow write access to any columnar objects in the row." + DEFVAL { nonVolatile } + ::= { ipsAuthIdentAddrAttributesEntry 6 } + + ipsAuthCredential OBJECT IDENTIFIER ::= { ipsAuthObjects 6 } + + -- Credential Attributes Table + + ipsAuthCredentialAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpsAuthCredentialAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of credentials related to user identities + that are allowed as valid authenticators of the + particular identity." + ::= { ipsAuthCredential 1 } + + ipsAuthCredentialAttributesEntry OBJECT-TYPE + SYNTAX IpsAuthCredentialAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing management information + applicable to a credential that verifies a user + identity within an authorization instance. + + + +Bakke & Muchow Standards Track [Page 21] + +RFC 4545 IPS Authorization MIB May 2006 + + + To provide complete information in this MIB for a credential, + the management station must not only create the row in this + table but must also create a row in another table, where the + other table is determined by the value of + ipsAuthCredAuthMethod, e.g., if ipsAuthCredAuthMethod has the + value ipsAuthMethodChap, a row must be created in the + ipsAuthCredChapAttributesTable." + INDEX { ipsAuthInstIndex, ipsAuthIdentIndex, ipsAuthCredIndex } + ::= { ipsAuthCredentialAttributesTable 1 } + + IpsAuthCredentialAttributesEntry ::= SEQUENCE { + ipsAuthCredIndex Unsigned32, + ipsAuthCredAuthMethod AutonomousType, + ipsAuthCredRowStatus RowStatus, + ipsAuthCredStorageType StorageType + } + + ipsAuthCredIndex OBJECT-TYPE + SYNTAX Unsigned32 (1..4294967295) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An arbitrary integer used to uniquely identify a + particular Credential instance within an instance + present on the node. + This index value must not be modified or reused by + an agent unless a reboot has occurred. An agent + should attempt to keep this value persistent across + reboots." + ::= { ipsAuthCredentialAttributesEntry 1 } + + ipsAuthCredAuthMethod OBJECT-TYPE + SYNTAX AutonomousType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This object contains an OBJECT IDENTIFIER + that identifies the authentication method + used with this credential. + + When a row is created in this table, a corresponding + row must be created by the management station + in a corresponding table specified by this value. + + When a row is deleted from this table, the corresponding + row must be automatically deleted by the agent in + the corresponding table specified by this value. + + + + +Bakke & Muchow Standards Track [Page 22] + +RFC 4545 IPS Authorization MIB May 2006 + + + If the value of this object is ipsAuthMethodNone, no + corresponding rows are created or deleted from other + tables. + + Some standardized values for this object are defined + within the ipsAuthMethodTypes subtree." + ::= { ipsAuthCredentialAttributesEntry 2 } + + ipsAuthCredRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This field allows entries to be dynamically added and + removed from this table via SNMP. When adding a row to + this table, all non-Index/RowStatus objects must be set. + Rows may be discarded using RowStatus. The value of + ipsAuthCredAuthMethod must not be changed while this row + is 'active'." + ::= { ipsAuthCredentialAttributesEntry 3 } + + ipsAuthCredStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The storage type for all read-create objects in this row. + Rows in this table that were created through an external + process may have a storage type of readOnly or permanent. + Conceptual rows having the value 'permanent' need not + allow write access to any columnar objects in the row." + DEFVAL { nonVolatile } + ::= { ipsAuthCredentialAttributesEntry 4 } + + ipsAuthCredChap OBJECT IDENTIFIER ::= { ipsAuthObjects 7 } + + -- Credential Chap-Specific Attributes Table + + ipsAuthCredChapAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpsAuthCredChapAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of CHAP attributes for credentials that + use ipsAuthMethodChap as their ipsAuthCredAuthMethod. + + A row in this table can only exist when an instance of + the ipsAuthCredAuthMethod object exists (or is created + + + +Bakke & Muchow Standards Track [Page 23] + +RFC 4545 IPS Authorization MIB May 2006 + + + simultaneously) having the same instance identifiers + and a value of 'ipsAuthMethodChap'." + ::= { ipsAuthCredChap 1 } + + ipsAuthCredChapAttributesEntry OBJECT-TYPE + SYNTAX IpsAuthCredChapAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing management information + applicable to a credential that uses + ipsAuthMethodChap as their ipsAuthCredAuthMethod. + + When a row is created in ipsAuthCredentialAttributesTable + with ipsAuthCredAuthMethod = ipsAuthCredChap, the + management station must create a corresponding row + in this table. + + When a row is deleted from ipsAuthCredentialAttributesTable + with ipsAuthCredAuthMethod = ipsAuthCredChap, the + agent must delete the corresponding row (if any) in + this table." + INDEX { ipsAuthInstIndex, ipsAuthIdentIndex, ipsAuthCredIndex } + ::= { ipsAuthCredChapAttributesTable 1 } + + IpsAuthCredChapAttributesEntry ::= SEQUENCE { + ipsAuthCredChapUserName SnmpAdminString, + ipsAuthCredChapRowStatus RowStatus, + ipsAuthCredChapStorageType StorageType + } + + ipsAuthCredChapUserName OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A character string containing the CHAP user name for this + credential." + REFERENCE + "W. Simpson, RFC 1994: PPP Challenge Handshake + Authentication Protocol (CHAP), August 1996" + ::= { ipsAuthCredChapAttributesEntry 1 } + + ipsAuthCredChapRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + + + +Bakke & Muchow Standards Track [Page 24] + +RFC 4545 IPS Authorization MIB May 2006 + + + "This field allows entries to be dynamically added and + removed from this table via SNMP. When adding a row to + this table, all non-Index/RowStatus objects must be set. + Rows may be discarded using RowStatus. The value of + ipsAuthCredChapUserName may be changed while this row + is 'active'." + ::= { ipsAuthCredChapAttributesEntry 2 } + + ipsAuthCredChapStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The storage type for all read-create objects in this row. + Rows in this table that were created through an external + process may have a storage type of readOnly or permanent. + Conceptual rows having the value 'permanent' need not + allow write access to any columnar objects in the row." + DEFVAL { nonVolatile } + ::= { ipsAuthCredChapAttributesEntry 3 } + + ipsAuthCredSrp OBJECT IDENTIFIER ::= { ipsAuthObjects 8 } + + -- Credential Srp-Specific Attributes Table + + ipsAuthCredSrpAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpsAuthCredSrpAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of SRP attributes for credentials that + use ipsAuthMethodSrp as its ipsAuthCredAuthMethod. + + A row in this table can only exist when an instance of + the ipsAuthCredAuthMethod object exists (or is created + simultaneously) having the same instance identifiers + and a value of 'ipsAuthMethodSrp'." + ::= { ipsAuthCredSrp 1 } + + ipsAuthCredSrpAttributesEntry OBJECT-TYPE + SYNTAX IpsAuthCredSrpAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing management information + applicable to a credential that uses + ipsAuthMethodSrp as their ipsAuthCredAuthMethod. + + + + +Bakke & Muchow Standards Track [Page 25] + +RFC 4545 IPS Authorization MIB May 2006 + + + When a row is created in ipsAuthCredentialAttributesTable + with ipsAuthCredAuthMethod = ipsAuthCredSrp, the + management station must create a corresponding row + in this table. + + When a row is deleted from ipsAuthCredentialAttributesTable + with ipsAuthCredAuthMethod = ipsAuthCredSrp, the + agent must delete the corresponding row (if any) in + this table." + INDEX { ipsAuthInstIndex, ipsAuthIdentIndex, ipsAuthCredIndex } + ::= { ipsAuthCredSrpAttributesTable 1 } + + IpsAuthCredSrpAttributesEntry ::= SEQUENCE { + ipsAuthCredSrpUserName SnmpAdminString, + ipsAuthCredSrpRowStatus RowStatus, + ipsAuthCredSrpStorageType StorageType + } + + ipsAuthCredSrpUserName OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A character string containing the SRP user name for this + credential." + REFERENCE + "T. Wu, RFC 2945: The SRP Authentication and Key + Exchange System, September 2000" + ::= { ipsAuthCredSrpAttributesEntry 1 } + + ipsAuthCredSrpRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This field allows entries to be dynamically added and + removed from this table via SNMP. When adding a row to + this table, all non-Index/RowStatus objects must be set. + Rows may be discarded using RowStatus. The value of + ipsAuthCredSrpUserName may be changed while the status + of this row is 'active'." + ::= { ipsAuthCredSrpAttributesEntry 2 } + + ipsAuthCredSrpStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + + + +Bakke & Muchow Standards Track [Page 26] + +RFC 4545 IPS Authorization MIB May 2006 + + + "The storage type for all read-create objects in this row. + Rows in this table that were created through an external + process may have a storage type of readOnly or permanent. + Conceptual rows having the value 'permanent' need not + allow write access to any columnar objects in the row." + DEFVAL { nonVolatile } + ::= { ipsAuthCredSrpAttributesEntry 3 } + + ipsAuthCredKerberos OBJECT IDENTIFIER ::= { ipsAuthObjects 9 } + + -- Credential Kerberos-Specific Attributes Table + + ipsAuthCredKerbAttributesTable OBJECT-TYPE + SYNTAX SEQUENCE OF IpsAuthCredKerbAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A list of Kerberos attributes for credentials that + use ipsAuthMethodKerberos as their ipsAuthCredAuthMethod. + + A row in this table can only exist when an instance of + the ipsAuthCredAuthMethod object exists (or is created + simultaneously) having the same instance identifiers + and a value of 'ipsAuthMethodKerb'." + ::= { ipsAuthCredKerberos 1 } + + ipsAuthCredKerbAttributesEntry OBJECT-TYPE + SYNTAX IpsAuthCredKerbAttributesEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (row) containing management information + applicable to a credential that uses + ipsAuthMethodKerberos as its ipsAuthCredAuthMethod. + + When a row is created in ipsAuthCredentialAttributesTable + with ipsAuthCredAuthMethod = ipsAuthCredKerberos, the + management station must create a corresponding row + in this table. + + When a row is deleted from ipsAuthCredentialAttributesTable + with ipsAuthCredAuthMethod = ipsAuthCredKerberos, the + agent must delete the corresponding row (if any) in + this table." + INDEX { ipsAuthInstIndex, ipsAuthIdentIndex, ipsAuthCredIndex } + ::= { ipsAuthCredKerbAttributesTable 1 } + + IpsAuthCredKerbAttributesEntry ::= SEQUENCE { + + + +Bakke & Muchow Standards Track [Page 27] + +RFC 4545 IPS Authorization MIB May 2006 + + + ipsAuthCredKerbPrincipal SnmpAdminString, + ipsAuthCredKerbRowStatus RowStatus, + ipsAuthCredKerbStorageType StorageType + } + + ipsAuthCredKerbPrincipal OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "A character string containing a Kerberos principal + for this credential." + REFERENCE + "C. Neuman, S. Hartman, and K. Raeburn, RFC 4120: + The Kerberos Network Authentication Service (V5), + July 2005" + ::= { ipsAuthCredKerbAttributesEntry 1 } + + ipsAuthCredKerbRowStatus OBJECT-TYPE + SYNTAX RowStatus + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "This field allows entries to be dynamically added and + removed from this table via SNMP. When adding a row to + this table, all non-Index/RowStatus objects must be set. + Rows may be discarded using RowStatus. The value of + ipsAuthCredKerbPrincipal may be changed while this row + is 'active'." + ::= { ipsAuthCredKerbAttributesEntry 2 } + + ipsAuthCredKerbStorageType OBJECT-TYPE + SYNTAX StorageType + MAX-ACCESS read-create + STATUS current + DESCRIPTION + "The storage type for all read-create objects in this row. + Rows in this table that were created through an external + process may have a storage type of readOnly or permanent. + Conceptual rows having the value 'permanent' need not + allow write access to any columnar objects in the row." + DEFVAL { nonVolatile } + ::= { ipsAuthCredKerbAttributesEntry 3 } + + --****************************************************************** + -- Notifications + + -- There are no notifications necessary in this MIB module. + + + +Bakke & Muchow Standards Track [Page 28] + +RFC 4545 IPS Authorization MIB May 2006 + + + --****************************************************************** + + -- Conformance Statements + + ipsAuthCompliances OBJECT IDENTIFIER ::= { ipsAuthConformance 1 } + ipsAuthGroups OBJECT IDENTIFIER ::= { ipsAuthConformance 2 } + + ipsAuthInstanceAttributesGroup OBJECT-GROUP + OBJECTS { + ipsAuthInstDescr, + ipsAuthInstStorageType + } + STATUS current + DESCRIPTION + "A collection of objects providing information about + authorization instances." + ::= { ipsAuthGroups 1 } + + ipsAuthIdentAttributesGroup OBJECT-GROUP + OBJECTS { + ipsAuthIdentDescription, + ipsAuthIdentRowStatus, + ipsAuthIdentStorageType + } + STATUS current + DESCRIPTION + "A collection of objects providing information about + user identities within an authorization instance." + ::= { ipsAuthGroups 2 } + + ipsAuthIdentNameAttributesGroup OBJECT-GROUP + OBJECTS { + ipsAuthIdentName, + ipsAuthIdentNameRowStatus, + ipsAuthIdentNameStorageType + } + STATUS current + DESCRIPTION + "A collection of objects providing information about + user names within user identities within an authorization + instance." + ::= { ipsAuthGroups 3 } + + ipsAuthIdentAddrAttributesGroup OBJECT-GROUP + OBJECTS { + ipsAuthIdentAddrType, + ipsAuthIdentAddrStart, + ipsAuthIdentAddrEnd, + + + +Bakke & Muchow Standards Track [Page 29] + +RFC 4545 IPS Authorization MIB May 2006 + + + ipsAuthIdentAddrRowStatus, + ipsAuthIdentAddrStorageType + } + STATUS current + DESCRIPTION + "A collection of objects providing information about + address ranges within user identities within an + authorization instance." + ::= { ipsAuthGroups 4 } + + ipsAuthIdentCredAttributesGroup OBJECT-GROUP + OBJECTS { + ipsAuthCredAuthMethod, + ipsAuthCredRowStatus, + ipsAuthCredStorageType + } + STATUS current + DESCRIPTION + "A collection of objects providing information about + credentials within user identities within an authorization + instance." + ::= { ipsAuthGroups 5 } + + ipsAuthIdentChapAttrGroup OBJECT-GROUP + OBJECTS { + ipsAuthCredChapUserName, + ipsAuthCredChapRowStatus, + ipsAuthCredChapStorageType + } + STATUS current + DESCRIPTION + "A collection of objects providing information about + CHAP credentials within user identities within an + authorization instance." + ::= { ipsAuthGroups 6 } + + ipsAuthIdentSrpAttrGroup OBJECT-GROUP + OBJECTS { + ipsAuthCredSrpUserName, + ipsAuthCredSrpRowStatus, + ipsAuthCredSrpStorageType + } + STATUS current + DESCRIPTION + "A collection of objects providing information about + SRP credentials within user identities within an + authorization instance." + ::= { ipsAuthGroups 7 } + + + +Bakke & Muchow Standards Track [Page 30] + +RFC 4545 IPS Authorization MIB May 2006 + + + ipsAuthIdentKerberosAttrGroup OBJECT-GROUP + OBJECTS { + ipsAuthCredKerbPrincipal, + ipsAuthCredKerbRowStatus, + ipsAuthCredKerbStorageType + } + STATUS current + DESCRIPTION + "A collection of objects providing information about + Kerberos credentials within user identities within an + authorization instance." + ::= { ipsAuthGroups 8 } + + --****************************************************************** + + ipsAuthComplianceV1 MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "Initial version of compliance statement based on + initial version of this MIB module. + + The Instance and Identity groups are mandatory; + at least one of the other groups (Name, Address, + Credential, Certificate) is also mandatory for + any given implementation." + MODULE -- this module + MANDATORY-GROUPS { + ipsAuthInstanceAttributesGroup, + ipsAuthIdentAttributesGroup + } + + -- Conditionally mandatory groups to be included with + -- the mandatory groups when necessary. + + GROUP ipsAuthIdentNameAttributesGroup + DESCRIPTION + "This group is mandatory for all implementations + that make use of unique identity names." + + GROUP ipsAuthIdentAddrAttributesGroup + DESCRIPTION + "This group is mandatory for all implementations + that use addresses to help verify identities." + + GROUP ipsAuthIdentCredAttributesGroup + DESCRIPTION + "This group is mandatory for all implementations + that use credentials to help verify identities." + + + +Bakke & Muchow Standards Track [Page 31] + +RFC 4545 IPS Authorization MIB May 2006 + + + GROUP ipsAuthIdentChapAttrGroup + DESCRIPTION + "This group is mandatory for all implementations + that use CHAP to help verify identities. + + The ipsAuthIdentCredAttributesGroup must be + implemented if this group is implemented." + + GROUP ipsAuthIdentSrpAttrGroup + DESCRIPTION + "This group is mandatory for all implementations + that use SRP to help verify identities. + + The ipsAuthIdentCredAttributesGroup must be + implemented if this group is implemented." + + GROUP ipsAuthIdentKerberosAttrGroup + DESCRIPTION + "This group is mandatory for all implementations + that use Kerberos to help verify identities. + + The ipsAuthIdentCredAttributesGroup must be + implemented if this group is implemented." + + OBJECT ipsAuthInstDescr + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT ipsAuthInstStorageType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT ipsAuthIdentDescription + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT ipsAuthIdentRowStatus + SYNTAX INTEGER { active(1) } -- subset of RowStatus + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required, and only one of the + six enumerated values for the RowStatus textual + convention need be supported, specifically: + active(1)." + + + + +Bakke & Muchow Standards Track [Page 32] + +RFC 4545 IPS Authorization MIB May 2006 + + + OBJECT ipsAuthIdentName + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT ipsAuthIdentNameRowStatus + SYNTAX INTEGER { active(1) } -- subset of RowStatus + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required, and only one of the + six enumerated values for the RowStatus textual + convention need be supported, specifically: + active(1)." + + OBJECT ipsAuthIdentAddrType + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT ipsAuthIdentAddrStart + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT ipsAuthIdentAddrEnd + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT ipsAuthIdentAddrRowStatus + SYNTAX INTEGER { active(1) } -- subset of RowStatus + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required, and only one of the + six enumerated values for the RowStatus textual + convention need be supported, specifically: + active(1)." + + OBJECT ipsAuthCredAuthMethod + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT ipsAuthCredRowStatus + SYNTAX INTEGER { active(1) } -- subset of RowStatus + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required, and only one of the + + + +Bakke & Muchow Standards Track [Page 33] + +RFC 4545 IPS Authorization MIB May 2006 + + + six enumerated values for the RowStatus textual + convention need be supported, specifically: + active(1)." + + OBJECT ipsAuthCredChapUserName + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT ipsAuthCredChapRowStatus + SYNTAX INTEGER { active(1) } -- subset of RowStatus + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required, and only one of the + six enumerated values for the RowStatus textual + convention need be supported, specifically: + active(1)." + + OBJECT ipsAuthCredSrpUserName + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT ipsAuthCredSrpRowStatus + SYNTAX INTEGER { active(1) } -- subset of RowStatus + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required, and only one of the + six enumerated values for the RowStatus textual + convention need be supported, specifically: + active(1)." + + OBJECT ipsAuthCredKerbPrincipal + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required." + + OBJECT ipsAuthCredKerbRowStatus + SYNTAX INTEGER { active(1) } -- subset of RowStatus + MIN-ACCESS read-only + DESCRIPTION + "Write access is not required, and only one of the six + enumerated values for the RowStatus textual convention need + be supported, specifically: active(1)." + + ::= { ipsAuthCompliances 1 } + + END + + + +Bakke & Muchow Standards Track [Page 34] + +RFC 4545 IPS Authorization MIB May 2006 + + +9. Security Considerations + +9.1. MIB Security Considerations + + There are a number of management objects defined in this MIB module + with a MAX-ACCESS clause of read-write and/or read-create. Such + objects may be considered sensitive or vulnerable in some network + 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: + + o in the ipsAuthInstanceAttributesTable: + + - ipsAuthInstDescr could be modified to camouflage the existence + of a rogue authorization instance; + + o in the ipsAuthIdentAttributesTable: + + - ipsAuthIdentDescription could be modified to camouflage the + existence of a rogue identity; + + - ipsAuthIdentRowStatus could be modified to add or delete a rogue + identity; + + - ipsAuthIdentStorageType could be modified to make temporary rows + permanent, or permanent rows temporary; + + o in the ipsAuthIdentNameAttributesTable: + + - ipsAuthIdentName could be modified to change the name of an + existing identity; + + - ipsAuthIdentNameRowStatus could be modified to add or delete a + name of an existing identity; + + - ipsAuthIdentNameStorageType could be modified to make temporary + rows permanent, or permanent rows temporary; + + o in the ipsAuthIdentAddrAttributesTable: + + - ipsAuthIdentAddrType could be modified to change the type of + address checking performed; + + - ipsAuthIdentAddrStart could be modified to change the start of + the allowed range; + + + + + +Bakke & Muchow Standards Track [Page 35] + +RFC 4545 IPS Authorization MIB May 2006 + + + - ipsAuthIdentAddrEnd could be modified to change the end of the + allowed range; + + - ipsAuthIdentAddrRowStatus could be modified to add or delete the + checking of an address range; + + - ipsAuthIdentAddrStorageType could be modified to make temporary + rows permanent, or permanent rows temporary; + + o in the ipsAuthCredentialAttributesTable: + + - ipsAuthCredAuthMethod could be modified to change the type of + authentication to be used; + + - ipsAuthCredRowStatus could be modified to add or delete checking + of credentials; + + - ipsAuthCredStorageType could be modified to make temporary rows + permanent, or permanent rows temporary; + + o in the ipsAuthCredChapAttributesTable: + + - ipsAuthCredChapUserName could be modified to change the CHAP + user name for a credential; + + - ipsAuthCredChapRowStatus could be modified to add or delete CHAP + attributes for credentials; + + - ipsAuthCredChapStorageType could be modified to make temporary + rows permanent, or permanent rows temporary; + + o in the ipsAuthCredSrpAttributesTable: + + - ipsAuthCredSrpUserName could be modified to change the SRP user + name for a credential; + + - ipsAuthCredSrpRowStatus could be modified to add or delete SRP + attributes for credentials; + + - ipsAuthCredSrpStorageType could be modified to make temporary + rows permanent, or permanent rows temporary; + + o in the ipsAuthCredKerbAttributesTable: + + - ipsAuthCredKerbPrincipal could be modified to change the + Kerberos principal for a credential; + + + + + +Bakke & Muchow Standards Track [Page 36] + +RFC 4545 IPS Authorization MIB May 2006 + + + - ipsAuthCredKerbRowStatus could be modified to add or delete + Kerberos attributes for credentials; + + - ipsAuthCredKerbStorageType could be modified to make temporary + rows permanent, or permanent rows temporary; + + Note that removal of legitimate credentials can result in either + denial of service or weakening the requirements for access of a + particular service. Note also that some types of credentials, such + as CHAP or SRP, also require passwords or verifiers to be associated + with the credential. These are managed outside this MIB module. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + 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: + + o All tables (specifically: ipsAuthInstanceAttributesTable, + ipsAuthIdentAttributesTable, ipsAuthIdentNameAttributesTable, + ipsAuthIdentAddrAttributesTable, ipsAuthCredentialAttributesTable, + ipsAuthCredChapAttributesTable, ipsAuthCredSrpAttributesTable, and + ipsAuthCredKerbAttributesTable) provide the ability to find out + which names, addresses, and credentials would be required to + access services on the managed system. If these credentials are + easily spoofed (particularly the name or address), read access to + this MIB module must be tightly controlled. When used with + pointers from another MIB module to rows in the + ipsAuthIdentAttributesTable, this MIB module provides information + about which entities are authorized to connect to which entities. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + even then, there is no control as to who on the secure network is + allowed to access and GET/SET (read/change/create/delete) the objects + in this MIB module. + + It is RECOMMENDED that implementors consider the security features as + provided by the SNMPv3 framework (see [RFC3410], section 8), + including full support for the SNMPv3 cryptographic mechanisms (for + authentication and privacy). + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + + + +Bakke & Muchow Standards Track [Page 37] + +RFC 4545 IPS Authorization MIB May 2006 + + + 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. + + In many implementations, the objects in this MIB module can be read + and modified via other mechanisms or protocols in addition to this + MIB module. For the system to be secure, other mechanisms that can + read and modify the contents of this MIB module must also address the + above issues, and handle the threats outlined in [RFC3411], section + 1.4. + + Given the sensitivity of information contained in this MIB module, it + is strongly recommended that encryption (SNMPv3 with a securityLevel + of authPriv [RFC3411]) be used for all access to objects in this MIB + module. + +9.2. Other Security Considerations + + An identity consists of a set of names (e.g., an iSCSI Initiator + Name), addresses (e.g., an IP address or Fibre Channel World Wide + Name (WWN)), and credentials (e.g., a CHAP user name). + + To match an identity, one must match: + + o One of the IdentNames belonging to the IdentIndex, unless there + are no IdentNames for the IdentIndex, and + + o One of the IdentAddrs belonging to the IdentIndex, unless there + are no IdentAddrs for the IdentIndex, and + + o One of the IdentCreds belonging to the IdentIndex, unless there + are no Creds for the IdentIndex. + + Note that if any of the above lists are empty for a given IdentIndex, + any identifier of that type is considered to match the identity. The + non-empty lists will still be checked. For example, if the + IdentAddrs list is empty for the IndentIndex, but there are entries + in IdentNames and IdentCreds, any address will be considered a match, + as long as the offered name and credential match one of the + IdentNames and IdentCreds, respectively. + + This leaves a possible security window while adding and removing + entries from one of these lists. For example, an identity could + consist of no IdentNames, no IdentAddrs, and exactly one IdentCred. + If that IdentCred was to be updated, several methods could be used: + + + + + + +Bakke & Muchow Standards Track [Page 38] + +RFC 4545 IPS Authorization MIB May 2006 + + + o The UserName or Principal could be simply written in the + appropriate table, if the credential's type remained the same + (recommended). + + o The new credential could be added, then the old deleted + (recommended). + + o The new credential could be added, and the old deleted in the same + SNMP request (recommended, but do the add first). + + o The old credential could be deleted, then the new added (Don't + use!). + + Of the above methods, the last leaves a window in which the list is + empty, possibly allowing unconstrained access to the resource making + use of this MIB. This method should never be used for Names, Addrs, + or Creds. + + The use of the third method, adding and deleting within the same + request, should be used with care. It is recommended that within the + request, the add be done first. Otherwise, an implementation may + attempt to perform these operations in order, potentially leaving a + window. + + The first two methods are recommended. + + Care must also be taken when updating the IdentAddrs for an identity. + Each IdentAddr specifies a range of addresses that match the + identity, and has an address type, starting address, and ending + address. Modifying these one at a time can open a temporary window + where a larger range of addresses are allowed. For example, a single + address is specified using IdentAddrType = ipv4, IdentAddrStart = + IdentAddrEnd = 192.0.2.5. We want to update this to specify the + single address 192.0.2.34. If the end address is updated first, we + temporarily allow the range 192.0.2.5 .. 192.0.2.34, which is not + what we want. Similarly, if we change from 192.0.2.34 back to + 192.0.2.5, and we update IdentAddrStart first, we end up with the + range again. To handle this, an application must either: + + o update both IdentAddrStart and IdentAddrEnd in the same SNMP set + request, or + + o add the new IdentAddrStart and IdentAddrEnd with a new + IdentAddrIndex, then delete the old one, using the methods shown + before. + + + + + + +Bakke & Muchow Standards Track [Page 39] + +RFC 4545 IPS Authorization MIB May 2006 + + + Since the value of IdentAddrType specifies the formats of + IdentAddrStart and IdentAddrEnd, modification of IdentAddrType is not + allowed for an existing row. + +10. IANA Considerations + + The IANA has assigned a MIB OID number under the mib-2 branch for the + IPS-AUTH-MIB. + +11. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J. , + Rose, M., and S. Waldbusser, "Structure of Management + Information Version 2 (SMIv2)", STD 58, RFC 2578, April + 1999. + + [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., + Rose, M., and S. Waldbusser, "Textual Conventions for + SMIv2", STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., + Rose, M., and S. Waldbusser, "Conformance Statements for + SMIv2", STD 58, RFC 2580, April 1999. + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", RFC 3411, December + 2002. + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, February 2005. + + [IANA-AF] IANA, "IANA Address Family Numbers MIB", + http://www.iana.org/assignments/ + ianaaddressfamilynumbers-mib. + + [RFC4293] Routhier, S., "Management Information Base for the + Internet Protocol (IP)", RFC 4293, April 2006. + + [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication + Protocol (CHAP)", RFC 1994, August 1996. + + + + + + +Bakke & Muchow Standards Track [Page 40] + +RFC 4545 IPS Authorization MIB May 2006 + + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + July 2005. + + [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", + RFC 2945, September 2000. + +12. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", RFC 3414, December 2002. + + [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., + and E. Zeidner, "Internet Small Computer Systems Interface + (iSCSI)", RFC 3720, March 2004. + + [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for + Uniform Resource Names", RFC 1737, December 1994. + + [RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, + May 2005. + +13. Acknowledgements + + In addition to the authors, several people contributed to the + development of this MIB module through discussions of authentication, + authorization, and access within the iSCSI MIB module and security + teams, including John Hufferd, Marjorie Krueger, Keith McCloghrie, + Tom McSweeney, Steve Senum, and Josh Tseng. Thanks also to Bill + Studenmund (Wasabi Systems) for adding the Kerberos method, and to + Ayman Ghanem for finding and suggesting changes to several problems + found in the MIB module. + + Thanks especially to Keith McCloghrie for serving as advisor for this + MIB module. + + + + + + + + + + + +Bakke & Muchow Standards Track [Page 41] + +RFC 4545 IPS Authorization MIB May 2006 + + +Authors' Addresses + + Mark Bakke + Postal: Cisco Systems, Inc + 7900 International Drive, Suite 400 + Bloomington, MN + USA 55425 + + EMail: mbakke@cisco.com + + + James Muchow + Postal: Qlogic Corp. + 6321 Bury Drive + Eden Prairie, MN + USA 55346 + + EMail: james.muchow@qlogic.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bakke & Muchow Standards Track [Page 42] + +RFC 4545 IPS Authorization MIB May 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Bakke & Muchow Standards Track [Page 43] + |