The management and local datastore information definitions for the AAA-Enabled View-based Access Control Model for SNMP.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info).
This version of this MIB module is part of RFC 6065; see the RFC itself for full legal notices.
This table provides a listing of all currently active sessions for which a mapping of the combination of SnmpSecurityModel and securityName into the name of a VACM group has been provided by an AAA service. The group name (in VACM) in turn identifies an access control policy to be used for the corresponding principals. Reference: RFC 3411, Section 3.2.2, defines securityName.
vacmAaaSecurityModel
1.3.6.1.2.1.199.1.1.1.1
SnmpSecurityModelAn identifier that uniquely identifies a Security Model of the Security Subsystem within this SNMP Management Architecture.
The values for securityModel are allocated as follows:
- The zero value does not identify any particular security model.
- Values between 1 and 255, inclusive, are reserved for standards-track Security Models and are managed by the Internet Assigned Numbers Authority (IANA). - Values greater than 255 are allocated to enterprise-specific Security Models. An enterprise-specific securityModel value is defined to be:
enterpriseID * 256 + security model within enterprise
For example, the fourth Security Model defined by the enterprise whose enterpriseID is 1 would be 259.
This scheme for allocation of securityModel values allows for a maximum of 255 standards- based Security Models, and for a maximum of 256 Security Models per enterprise.
It is believed that the assignment of new securityModel values will be rare in practice because the larger the number of simultaneously utilized Security Models, the larger the chance that interoperability will suffer. Consequently, it is believed that such a range will be sufficient. In the unlikely event that the standards committee finds this number to be insufficient over time, an enterprise number can be allocated to obtain an additional 256 possible values.
Note that the most significant bit must be zero; hence, there are 23 bits allocated for various organizations to design and define non-standard securityModels. This limits the ability to define new proprietary implementations of Security Models to the first 8,388,608 enterprises.
It is worthwhile to note that, in its encoded form, the securityModel value will normally require only a single byte since, in practice, the leftmost bits will be zero for most messages and sign extension is suppressed by the encoding rules.
As of this writing, there are several values of securityModel defined for use with SNMP or reserved for use with supporting MIB objects. They are as follows:
0 reserved for 'any'
1 reserved for SNMPv1
2 reserved for SNMPv2c
3 User-Based Security Model (USM) (1..2147483647) · Integer32
The security model associated with the AAA binding represented by this entry.
This object cannot take the 'any' (0) value.
vacmAaaSecurityName
1.3.6.1.2.1.199.1.1.1.2
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..32) · OCTET STRING · hint 255t
The securityName of the principal associated with the AAA binding represented by this entry. In RADIUS environments, this corresponds to the User-Name Attribute. Reference: RFC 3411, Section 3.2.2, defines securityName, and RFC 2865, Section 5.1, defines User-Name.
vacmAaaSessionID
1.3.6.1.2.1.199.1.1.1.3
Unsigned32
An implementation-dependent identifier of the session.
This value MUST be unique among all currently open sessions of all of this SNMP engine's transport models. The value has no particular significance other than to distinguish sessions.
Implementations in which tmSessionID has a compatible syntax and is unique across all transport models MAY use that value. Reference: The Abstract Service Interface parameter tmSessionID is defined in RFC 5590, Section 5.2.4.
vacmAaaGroupName
1.3.6.1.2.1.199.1.1.1.4
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..32) · OCTET STRING · hint 255t
The name of the group to which this entry is to belong. In RADIUS environments, this comes from the RADIUS Management-Policy-Id Attribute.
When the appropriate conditions are met, the value of this object is applied the vacmGroupName in the corresponding vacmSecurityToGroupEntry. Reference: RFC 3415