RFC 4545
Definitions of Managed Objects for IP Storage User Identity Authorization
RFC 4545: Definitions of Managed Objects for IP Storage User Identity Authorization 💖
Okay bestie, let's dig into this one. RFC 4545 is a Standards Track document from May 2006 (so it's an official Internet standard in progress 🦋). The authors are M. Bakke at Cisco Systems and J. Muchow at Qlogic Corp. 💅 Its header block doesn't list anything it obsoletes or updates, so it's not replacing or changing any earlier RFC. It's a brand new MIB module, which is so clean 🧚
Here's the Status of This Memo, which is basically the fine print about where this doc sits in the standards world 📜
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 🌸
Okay so this memo defines a chunk of the Management Information Base (MIB) that network management protocols use in TCP/IP-based internets 🌐 It's all about managing user identities, plus the names, addresses, and credentials you need to run access control. It was originally motivated by the need to set up authorized user identities for the iSCSI protocol, but it's been expanded so other protocols with similar needs can use it too 🫶
Now the important part: this MIB module only gives you the set of identities to be used inside access lists. It's the job of other MIB modules that use this one to hook those identities up to their own access lists or other authorization control methods 🔑 It's giving "I provide the people, you decide the door" energy 🚪
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 ..............................................411. Introduction 🦋
This MIB module is used to configure, and/or look at the configuration of, user identities and their credential info 🧾 Here's the tea: a "user" in this module doesn't have to be an actual person! It can be a host, an application, a cluster of hosts, or literally any identifiable entity that can be authorized to access a resource 🤖✨
Most objects in this module have a MAX-ACCESS of read-create, because the whole point is letting you configure user identities and their names, addresses, and credentials 🛠️ MIN-ACCESS is read-only for all objects, which is for implementations that configure things some other way but still need to be able 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]. These are the official BCP 14 vibes, so read them exactly as written 📏
3. The Internet-Standard Management Framework 🌈
If you want a detailed overview of the documents that describe the current Internet-Standard Management Framework, check out section 7 of RFC 3410 [RFC3410] 📖
Managed objects are accessed via a virtual information store called 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 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 🍓
Okay so the IPS-AUTH-MIB module doesn't directly deal with objects in other modules 🙈 But the identity address objects can hold IPv4, IPv6, or other address types, so they can be indirectly related to objects in the IP [RFC4293] MIB module 🌐
This MIB module doesn't give you actual authorization or access control lists. What it does is give you a way to identify entities that can be put into other authorization lists 📋 That work should generally happen in MIB modules that reference the identities in this one. It also doesn't cover login or authentication failure statistics or notifications, since those are super application specific and not generic enough to live here 🚫
The user identity objects in this module are typically referenced from other modules by a RowPointer within that module. A module that needs a list of authorized user identities for its resources can make one, with a single RowPointer in each list element pointing to a user identity in this module. This is neither required nor restricted by this MIB module 🫶
5. Relationship to the USM MIB Module 🔐
Heads up, there are two kinds of "user" floating around! The User-based Security Model (USM) [RFC3414] also has the concept of a user, with authentication and privacy protocols and their credentials. The definition of USM includes the SNMP-USER-BASED-SM-MIB module, which allows configuration of SNMPv3 user credentials to protect SNMPv3 messages 🛡️ USM's users aren't related to the user identities managed by the IPS-AUTH-MIB module in this document. But USM will often run on the same system as the IPS-AUTH-MIB module, and the SNMP-USER-BASED-SM-MIB module is used to manage the security protecting SNMPv3 messages, including the ones that access the IPS-AUTH-MIB module 💜
In this document, "user" is a different thing from an SNMPv3 user! It's meant to include (but not be limited to) users of IP storage devices 💾 A "user" here is a collection of user names (unique identifiers), user addresses, and credentials that can be used together to figure out whether an entity should be allowed access to a resource ✨ Each user can have multiple names, addresses, and credentials, which makes this module especially suited to managing storage resource users. Those usually get access control lists made up of potentially multiple identifiers, addresses, and credentials 🧩 This module only does authorization lists and doesn't set data privacy parameters 🙅♀️
Contrast that with an SNMPv3 user as defined in [RFC3414]. That one has exactly one user-name, one authentication protocol, and one privacy protocol, along with their associated info and SNMP-specific info, like an engine ID 🤓 Those objects exist to support exactly the info needed for SNMPv3 security, and nothing more.
For the rest of this document, the term "user" means an IPS-AUTH-MIB user identity. Just so we're clear 💅
6. Relationship to SNMP Contexts 🦋
Every 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 📦 Instances work really well with partitionable or hierarchical devices and fit in logically with other management schemes 🌳
Instances don't replace SNMP contexts, but they do give you a super simple way to assign a collection of identities within a device to one or more SNMP contexts, without having to do it for each identity's row 🙌 It's a major time saver, iykyk 💖
7. Discussion 👑
This MIB module structure is meant to let you configure a list of user identities. Each one has a list of names, addresses, credentials, and certificates that, when combined, will distinguish that identity 🪪
The IPS-AUTH-MIB module is built around two main "objects": the authorization instance and the identity. These act as containers for the rest of the objects ✨ This section gives a short description of the "object" hierarchy and of each object, then talks through the actual SNMP table structure inside those objects. Bestie, let's go! 🚀
7.1. Authorization MIB Object Model 💅
okay so the main character here is the authorization instance 👑, and it basically "contains" everything else. the indexing hierarchy of this module looks like this 🧚:
ipsAuthInstance
-- A distinct authorization entity within the managed system.
-- Most implementations will have just one of these.
ipsAuthIdentity
-- A user identity, consisting of a set of identity names,
-- addresses, and credentials reflected in the following
-- objects:
ipsAuthIdentityName
-- A name for a user identity. A name should be globally
-- unique, and unchanging over time. Some protocols may
-- not require this one.
ipsAuthIdentityAddress
-- An address range, typically but not necessarily an
-- IPv4, IPv6, or Fibre Channel address range, at which
-- the identity is allowed to reside.
ipsAuthCredential
-- A single credential, such as a CHAP username,
-- which can be used to verify the identity.
ipsAuthCredChap
-- CHAP-specific attributes for an ipsAuthCredential
ipsAuthCredSrp
-- SRP-specific attributes
ipsAuthCredKerberos
-- Kerberos-specific attributeseach identity holds the info needed to identify a particular end-point that wants to access a service, like iSCSI 🦋
an identity can have multiple names, addresses, and credentials, and every one of those lives in its own row 🎀 here's the vibe check on how rows get matched:
- if there are multiple rows of the same type, they work with OR logic. an entity only needs to match one of them 🫶
- if there are rows of different types (like a name and an address), they work with AND logic. the entity has to match at least one row from each category 🔥
- if there are no rows at all in a category, that category just gets ignored 🙈
for example, say an ipsAuthIdentity has two ipsAuthIdentityAddress rows, one ipsAuthCredential row, and no ipsAuthIdentityName rows. then the entity needs to match the credential row and at least one of the two address rows to count as the identity. iykyk 💜
index values like ipsAuthInstIndex and ipsAuthIdentIndex show up in multiple tables, and rows can get added and deleted. so an implementation should try to keep all index values persistent across reboots 🌸 and index values for deleted rows must not be reused before a reboot. no recycling indexes, periodt ✨
7.2. ipsAuthInstance 🧚
the ipsAuthInstanceAttributesTable is the primary table of the IPS-AUTH-MIB module. every other table entry in this module uses the index of an ipsAuthInstanceAttributesEntry as its primary index. basically, an authorization instance is just a managed set of identities 💖
most implementations will only have one authorization instance row in this table. but there are some cases where multiple rows might get used:
- a large system can be "partitioned" into multiple, distinct virtual systems. they might share the SNMP agent but not their lists of identities, and each virtual system gets its own authorization instance 🏰
- a set of stackable systems, each with its own identities, can be represented by one common SNMP agent. each individual system gets its own authorization instance 🌈
- multiple protocols, each with their own identities, can live inside a single system and be represented by one SNMP agent. in that case, each protocol can have its own authorization instance 🦄
an entry in this table is often referred to by its name (ipsAuthInstDescr), which the management station should display to the user 👀 when an implementation supports only one entry in this table, the description may be returned as a zero-length string. no drama needed 🍓
7.3. ipsAuthIdentity 🎀
the ipsAuthIdentAttributesTable has one entry for each configured user identity. the identity only holds a description of what it's used for. all of its actual attributes live in other tables, since each one can have multiple values 💅
other MIB modules that have lists of users allowed to access a particular resource should generally contain a RowPointer to the ipsAuthIdentAttributesEntry that will be allowed access to the resource if it gets authenticated 🫶
all other table entries use the indices of this table as their primary indices ✨
7.4. ipsAuthIdentityName 💜
the ipsAuthIdentNameAttributesTable has a list of UTF-8 names. each one belongs to a particular identity in the authIdentity table and can be used to identify it 🌷
implementations using the IPS-AUTH-MIB module can 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 doesn't have to be a URN 🤓 identifiers that tend to change over time should generally go in the ipsAuthIdentityAddress table. names with no uniqueness properties should usually go into the description attribute for the identity 💭
an example of an identity name is the iSCSI Name, defined in [RFC3720]. any other MIB module that defines names to be used as ipsAuthIdentityName objects should specify how its names are unique, and the domain within which they're unique 🧠
if this table has no entries for a particular user identity, the implementation doesn't need to check any name parameters when verifying that identity. if the table has multiple entries for a particular user identity, the implementation should consider a match with any one of those entries to be valid 🎯
7.5. ipsAuthIdentityAddress 🦋
the ipsAuthIdentAddrAttributesTable has a list of addresses where the identity may reside. for example, an identity might only be allowed access to a resource from a certain IP address, or only if its address falls inside a certain range or set of ranges 🗺️
each entry has a starting and ending address. if you want a single address in the list, the starting and ending addresses must be identical 💖
each entry also has an AddrType attribute. this attribute holds an enumeration registered as an IANA Address Family type [IANA-AF]. many implementations will use IPv4 or IPv6 address types for these entries, but any IANA-registered type can be used, as long as it makes sense to the application 🌍
matching any address within any range in the list for a particular identity counts as a valid match. if there are no entries in this list for a given identity, its address is automatically assumed to match the identity 🫧
netmasks aren't supported, since an address range can say the same thing with more flexibility 🙌 an application that specifies 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 has a list of credentials, and each one can be used to verify a particular identity 🗝️
each credential has an authentication method to use, like CHAP [RFC1994], SRP [RFC2945], or Kerberos [RFC4120]. this attribute holds an object identifier instead of an enumerated type. that lets other MIB modules add their own authentication methods without changing this MIB module 🧩
for each entry in this table, there will be an entry in another table with its attributes. which table that is 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.you can add another credential type 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 be any of the types in the list of address family numbers. the most likely ones are 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 comes from the InetAddress specified in [RFC4001]. if the address family is one of the Fibre Channel types, the format is identical to the FcNameIdOrZero type defined in [RFC4044] 💫
7.8. Descriptors: Using OIDs in Place of Enumerated Types 🧚♀️
some attributes, especially the authentication method attribute, would normally need an enumerated type. but implementations will probably need to add new authentication method types of their own, without extending this MIB module. to make that work, this module defines a set of object identities within ipsAuthDescriptors. each of these object identities is basically an enumerated type 🫶
attributes that use these object identities have a value that's an OID instead of an enumerated type. those OIDs can point to the object identities defined in this module, or to object identities defined somewhere else, like in an enterprise MIB module 🏢 implementations that add their own authentication methods should also define a matching object identity for each of those methods within their own enterprise MIB module, and return its OID whenever an attribute is using that method 🎀
7.9. Notifications 🔔
monitoring authentication failures and other notification events is outside the scope of this MIB module, since they're generally application specific. no notifications are provided or required 🙅♀️
8. MIB Definitions 📜
okay this is the actual MIB module, so it's giving official vibes 💅 here's where it starts:
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.comokay bestie, the MIB definitions keep going and it's giving 🎀✨ Here's the next chunk of the module, untouched so every field and index lines up 💅
James Muchow
Postal: Qlogic Corp.
6321 Bury Dr.
Eden Prairie, MN
USA 55346
E-Mail: james.muchow@qlogic.com"
DESCRIPTION
"The IP Storage Authorization MIB module.
Copyright (C) The Internet Society (2006). This version of
this MIB module is part of RFC 4545; see the RFC itself for
full legal notices."
REVISION "200605220000Z" -- May 22, 2006
DESCRIPTION
"Initial version of the IP Storage Authentication MIB module,
published as RFC 4545"
::= { mib-2 141 }
ipsAuthNotifications OBJECT IDENTIFIER ::= { ipsAuthMibModule 0 }
ipsAuthObjects OBJECT IDENTIFIER ::= { ipsAuthMibModule 1 }
ipsAuthConformance OBJECT IDENTIFIER ::= { ipsAuthMibModule 2 }
-- Textual Conventions
IpsAuthAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"IP Storage requires the use of address information
that uses not only the InetAddress type defined in the
INET-ADDRESS-MIB, but also Fibre Channel type defined
in the Fibre Channel Management MIB. Although these
address types are recognized in the IANA Address Family
Numbers MIB, the addressing mechanisms have not been
merged into a well-known, common type. This data type,
the IpsAuthAddress, performs the merging for this MIB
module.
The formats of objects of this type are determined by
a corresponding object with syntax AddressFamilyNumbers,
and thus every object defined using this TC must
identify the object with syntax AddressFamilyNumbers
that specifies its type.
The syntax and semantics of this object depend on the
identified AddressFamilyNumbers object as follows:
AddressFamilyNumbers this object
==================== ===========
ipV4(1) restricted to the same syntax and
semantics as the InetAddressIPv4 TC.
ipV6(2) restricted to the same syntax and
semantics as the InetAddressIPv6 TC.
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
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."
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
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
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
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 }okay so this is where the identity name table comes in, and it's giving organized 💅🎀 Every row gets its own index trio, and the names have their own RowStatus and StorageType so you can add and remove them over SNMP like it's nothing 🦋
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 }
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
"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
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
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.
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.
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 }the credential bit is where it gets spicy 🌈 the credential row only tells the whole story when you also make a row in the other table that matches its ipsAuthCredAuthMethod, so pair them up or it's incomplete 🫶
Okay bestie, the CHAP, SRP, and Kerberos credential tables are next, and they're giving very similar energy 💅🫶
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
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
"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.
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
"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 {
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.
--******************************************************************
-- 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 }okay so we're still in the MIB Definitions era 🎀 here are the last attribute groups, bestie 💅
ipsAuthIdentAddrAttributesGroup OBJECT-GROUP
OBJECTS {
ipsAuthIdentAddrType,
ipsAuthIdentAddrStart,
ipsAuthIdentAddrEnd,
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 }
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 }
--******************************************************************and then the big compliance statement that spells out which groups you actually need 👑 this part is giving strict bouncer energy 🫶
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."
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)."
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
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 }
END9. Security Considerations ✨
9.1. MIB Security Considerations ✨
Okay bestie, this part is serious, so let's go 🫶. This MIB module has a bunch of management objects with a MAX-ACCESS of read-write and/or read-create. Those can be sensitive or vulnerable in some networks. Doing SET operations in a non-secure environment without proper protection can seriously mess with network operations 💀. Here's the tea on which tables and objects are sensitive or vulnerable:
- in the
ipsAuthInstanceAttributesTable:ipsAuthInstDescrcould be modified to camouflage the existence of a rogue authorization instance;
- in the
ipsAuthIdentAttributesTable:ipsAuthIdentDescriptioncould be modified to camouflage the existence of a rogue identity;ipsAuthIdentRowStatuscould be modified to add or delete a rogue identity;ipsAuthIdentStorageTypecould be modified to make temporary rows permanent, or permanent rows temporary;
- in the
ipsAuthIdentNameAttributesTable:ipsAuthIdentNamecould be modified to change the name of an existing identity;ipsAuthIdentNameRowStatuscould be modified to add or delete a name of an existing identity;ipsAuthIdentNameStorageTypecould be modified to make temporary rows permanent, or permanent rows temporary;
- in the
ipsAuthIdentAddrAttributesTable:ipsAuthIdentAddrTypecould be modified to change the type of address checking performed;ipsAuthIdentAddrStartcould be modified to change the start of the allowed range;ipsAuthIdentAddrEndcould be modified to change the end of the allowed range;ipsAuthIdentAddrRowStatuscould be modified to add or delete the checking of an address range;ipsAuthIdentAddrStorageTypecould be modified to make temporary rows permanent, or permanent rows temporary;
- in the
ipsAuthCredentialAttributesTable:ipsAuthCredAuthMethodcould be modified to change the type of authentication to be used;ipsAuthCredRowStatuscould be modified to add or delete checking of credentials;ipsAuthCredStorageTypecould be modified to make temporary rows permanent, or permanent rows temporary;
- in the
ipsAuthCredChapAttributesTable:ipsAuthCredChapUserNamecould be modified to change the CHAP user name for a credential;ipsAuthCredChapRowStatuscould be modified to add or delete CHAP attributes for credentials;ipsAuthCredChapStorageTypecould be modified to make temporary rows permanent, or permanent rows temporary;
- in the
ipsAuthCredSrpAttributesTable:ipsAuthCredSrpUserNamecould be modified to change the SRP user name for a credential;ipsAuthCredSrpRowStatuscould be modified to add or delete SRP attributes for credentials;ipsAuthCredSrpStorageTypecould be modified to make temporary rows permanent, or permanent rows temporary;
- in the
ipsAuthCredKerbAttributesTable:ipsAuthCredKerbPrincipalcould be modified to change the Kerberos principal for a credential;ipsAuthCredKerbRowStatuscould be modified to add or delete Kerberos attributes for credentials;ipsAuthCredKerbStorageTypecould be modified to make temporary rows permanent, or permanent rows temporary;
Note that removing legit credentials can lead to either denial of service or weakening the access requirements for a particular service 😬. Also, some credential types, like CHAP or SRP, need passwords or verifiers attached to the credential. Those are managed outside this MIB module, so they're not on this list 🔐.
Some of the readable objects in this MIB module (so, objects with a MAX-ACCESS other than not-accessible) may be sensitive or vulnerable in some networks 👀. So it's important to control even GET and/or NOTIFY access to these, and maybe even encrypt their values when they travel over the network via SNMP. Here are the tables and their sensitivity/vulnerability:
- All tables (specifically:
ipsAuthInstanceAttributesTable,ipsAuthIdentAttributesTable,ipsAuthIdentNameAttributesTable,ipsAuthIdentAddrAttributesTable,ipsAuthCredentialAttributesTable,ipsAuthCredChapAttributesTable,ipsAuthCredSrpAttributesTable, andipsAuthCredKerbAttributesTable) let someone find out which names, addresses, and credentials would be needed to access services on the managed system. If these credentials are easy to spoof (especially the name or address), read access to this MIB module has to be locked down tight 🔒. When it's used with pointers from another MIB module to rows in theipsAuthIdentAttributesTable, this MIB module reveals which entities are authorized to connect to which entities.
SNMP versions before SNMPv3 didn't have adequate security 😭. Even if the network itself is secure (for example, by using IPsec), there's still no control over who on that secure network can access and GET/SET (read/change/create/delete) the objects in this MIB module. Not it! 🙅♀️
It is RECOMMENDED that implementors consider the security features provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy) 🛡️.
Also, deploying SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and turn on cryptographic security 🔥. Then it's a customer/operator responsibility to make sure the SNMP entity giving access to an instance of this MIB module is set up properly, so only the principals (users) with legit rights can GET or SET (change/create/delete) those objects 💅.
In lots of implementations, the objects in this MIB module can also be read and modified through other mechanisms or protocols. For the system to be secure, those other mechanisms that can read and modify this MIB module's contents also have to address the issues above and handle the threats outlined in [RFC3411], section 1.4 🧚.
Given how sensitive the information in this MIB module is, 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
Okay, now the identity part 🦋. An identity is made up 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, you have to match all of these:
- One of the IdentNames belonging to the IdentIndex, unless there are no IdentNames for the IdentIndex, and
- One of the IdentAddrs belonging to the IdentIndex, unless there are no IdentAddrs for the IdentIndex, and
- One of the IdentCreds belonging to the IdentIndex, unless there are no Creds for the IdentIndex.
Note that if any of those lists are empty for a given IdentIndex, any identifier of that type counts as a match for the identity 🌈. The non-empty lists still get checked. For example, say the IdentAddrs list is empty for the IndentIndex, but there are entries in IdentNames and IdentCreds. Then any address counts as a match, as long as the offered name and credential match one of the IdentNames and IdentCreds, respectively 🙈.
Heads up, though: this leaves a possible security window while you're adding and removing entries from one of these lists 🚨. For example, an identity could have no IdentNames, no IdentAddrs, and exactly one IdentCred. If that IdentCred gets updated, there are several methods you could use:
- The UserName or Principal could be simply written in the appropriate table, if the credential's type stayed the same (recommended).
- The new credential could be added, then the old one deleted (recommended).
- The new credential could be added, and the old deleted in the same SNMP request (recommended, but do the add first).
- The old credential could be deleted, then the new one added (Don't use!).
Out of these, the last one leaves a window where the list is empty, which could allow unconstrained access to the resource using this MIB. That method should never be used for Names, Addrs, or Creds 😱.
Using the third method, adding and deleting within the same request, should be done with care. It's recommended that within the request, the add happens first. Otherwise, an implementation might perform these operations in order and potentially leave a window open 🪟.
The first two methods are recommended ✨.
Be careful when updating the IdentAddrs for an identity too 🧐. Each IdentAddr specifies a range of addresses that match the identity, and has an address type, a starting address, and an ending address. Changing these one at a time can open a temporary window where a bigger range of addresses is allowed. For example, a single address is specified using IdentAddrType = ipv4, IdentAddrStart = IdentAddrEnd = 192.0.2.5. Say we want to update this to the single address 192.0.2.34. If the end address gets 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 192.0.2.34 back to 192.0.2.5 and update IdentAddrStart first, we end up with the range again. To handle this, an application must either:
- update both IdentAddrStart and IdentAddrEnd in the same SNMP set request, or
- add the new IdentAddrStart and IdentAddrEnd with a new IdentAddrIndex, then delete the old one, using the methods shown before.
Since the value of IdentAddrType specifies the formats of IdentAddrStart and IdentAddrEnd, changing IdentAddrType isn't 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 ✨
okay bestie, these are the docs this spec needs to read first, no skipping 🫶
- [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.
- [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 🌸
these ones are just extra reading, the good background stuff that's nice to know but not required to implement 💜
- [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 🎀
okay the credits part is my favourite, the people who made this happen deserve all the flowers 🌷
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. 👑
Authors' Addresses ✨
the people who wrote it, so you know exactly who to thank (or blame, lol) 💅
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
Full Copyright Statement 💜
the legal bit, but make it cute 🦋
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.
the short version: this doc comes "AS IS", and nobody promises it won't step on anyone's rights or that it's merchantable or fit for a particular purpose. read the fine print before you build on it!
Intellectual Property 🌈
the patents-and-rights section, aka who owns what 🧚
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 🍓
last but not least, the lights-on crew 🌟
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
📦 where this page comes from
- ietf: rfc4545 2006-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms