GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4545

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

  1. - which can be used to verify the identity.

ipsAuthCredChap

  1. - CHAP-specific attributes for an ipsAuthCredential

ipsAuthCredSrp

  1. - SRP-specific attributes

ipsAuthCredKerberos

  1. - 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:
  1. 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

  1. 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.
  1. 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 }
  1. - 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))
  1. - 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 }
  1. - 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 }
  1. - 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 }
  1. - 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 }
  1. - 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 }
  1. - 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 }
  1. - 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 }
  1. - 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 }
  1. - 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 }
  1. - – Notifications – There are no notifications necessary in this MIB module. Bakke & Muchow Standards Track [Page 28] RFC 4545 IPS Authorization MIB May 2006 –
  1. - 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 }
  1. -**
 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
     }
  1. - Conditionally mandatory groups to be included with
  2. - 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:
  1. ipsAuthInstDescr could be modified to camouflage the existence

of a rogue authorization instance;

 o  in the ipsAuthIdentAttributesTable:
  1. ipsAuthIdentDescription could be modified to camouflage the

existence of a rogue identity;

  1. ipsAuthIdentRowStatus could be modified to add or delete a rogue

identity;

  1. ipsAuthIdentStorageType could be modified to make temporary rows

permanent, or permanent rows temporary;

 o  in the ipsAuthIdentNameAttributesTable:
  1. ipsAuthIdentName could be modified to change the name of an

existing identity;

  1. ipsAuthIdentNameRowStatus could be modified to add or delete a

name of an existing identity;

  1. ipsAuthIdentNameStorageType could be modified to make temporary

rows permanent, or permanent rows temporary;

 o  in the ipsAuthIdentAddrAttributesTable:
  1. ipsAuthIdentAddrType could be modified to change the type of

address checking performed;

  1. 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

  1. ipsAuthIdentAddrEnd could be modified to change the end of the

allowed range;

  1. ipsAuthIdentAddrRowStatus could be modified to add or delete the

checking of an address range;

  1. ipsAuthIdentAddrStorageType could be modified to make temporary

rows permanent, or permanent rows temporary;

 o  in the ipsAuthCredentialAttributesTable:
  1. ipsAuthCredAuthMethod could be modified to change the type of

authentication to be used;

  1. ipsAuthCredRowStatus could be modified to add or delete checking

of credentials;

  1. ipsAuthCredStorageType could be modified to make temporary rows

permanent, or permanent rows temporary;

 o  in the ipsAuthCredChapAttributesTable:
  1. ipsAuthCredChapUserName could be modified to change the CHAP

user name for a credential;

  1. ipsAuthCredChapRowStatus could be modified to add or delete CHAP

attributes for credentials;

  1. ipsAuthCredChapStorageType could be modified to make temporary

rows permanent, or permanent rows temporary;

 o  in the ipsAuthCredSrpAttributesTable:
  1. ipsAuthCredSrpUserName could be modified to change the SRP user

name for a credential;

  1. ipsAuthCredSrpRowStatus could be modified to add or delete SRP

attributes for credentials;

  1. ipsAuthCredSrpStorageType could be modified to make temporary

rows permanent, or permanent rows temporary;

 o  in the ipsAuthCredKerbAttributesTable:
  1. 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

  1. ipsAuthCredKerbRowStatus could be modified to add or delete

Kerberos attributes for credentials;

  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4545.txt · Last modified: 2006/05/23 00:05 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki