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
9. Security Considerations
9.1. MIB Security Considerations
There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations. These are the tables and objects and their
sensitivity/vulnerability:
o in the ipsAuthInstanceAttributesTable:
- ipsAuthInstDescr could be modified to camouflage the existence
of a rogue authorization instance;
o in the ipsAuthIdentAttributesTable:
- ipsAuthIdentDescription could be modified to camouflage the
existence of a rogue identity;
- ipsAuthIdentRowStatus could be modified to add or delete a rogue
identity;
- ipsAuthIdentStorageType could be modified to make temporary rows
permanent, or permanent rows temporary;
o in the ipsAuthIdentNameAttributesTable:
- ipsAuthIdentName could be modified to change the name of an
existing identity;
- ipsAuthIdentNameRowStatus could be modified to add or delete a
name of an existing identity;
- ipsAuthIdentNameStorageType could be modified to make temporary
rows permanent, or permanent rows temporary;
o in the ipsAuthIdentAddrAttributesTable:
- ipsAuthIdentAddrType could be modified to change the type of
address checking performed;
- ipsAuthIdentAddrStart could be modified to change the start of
the allowed range;
- ipsAuthIdentAddrEnd could be modified to change the end of the
allowed range;
- ipsAuthIdentAddrRowStatus could be modified to add or delete the
checking of an address range;
- ipsAuthIdentAddrStorageType could be modified to make temporary
rows permanent, or permanent rows temporary;
o in the ipsAuthCredentialAttributesTable:
- ipsAuthCredAuthMethod could be modified to change the type of
authentication to be used;
- ipsAuthCredRowStatus could be modified to add or delete checking
of credentials;
- ipsAuthCredStorageType could be modified to make temporary rows
permanent, or permanent rows temporary;
o in the ipsAuthCredChapAttributesTable:
- ipsAuthCredChapUserName could be modified to change the CHAP
user name for a credential;
- ipsAuthCredChapRowStatus could be modified to add or delete CHAP
attributes for credentials;
- ipsAuthCredChapStorageType could be modified to make temporary
rows permanent, or permanent rows temporary;
o in the ipsAuthCredSrpAttributesTable:
- ipsAuthCredSrpUserName could be modified to change the SRP user
name for a credential;
- ipsAuthCredSrpRowStatus could be modified to add or delete SRP
attributes for credentials;
- ipsAuthCredSrpStorageType could be modified to make temporary
rows permanent, or permanent rows temporary;
o in the ipsAuthCredKerbAttributesTable:
- ipsAuthCredKerbPrincipal could be modified to change the
Kerberos principal for a credential;
- ipsAuthCredKerbRowStatus could be modified to add or delete
Kerberos attributes for credentials;
- ipsAuthCredKerbStorageType could be modified to make temporary
rows permanent, or permanent rows temporary;
Note that removal of legitimate credentials can result in either
denial of service or weakening the requirements for access of a
particular service. Note also that some types of credentials, such
as CHAP or SRP, also require passwords or verifiers to be associated
with the credential. These are managed outside this MIB module.
Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability:
o All tables (specifically: ipsAuthInstanceAttributesTable,
ipsAuthIdentAttributesTable, ipsAuthIdentNameAttributesTable,
ipsAuthIdentAddrAttributesTable, ipsAuthCredentialAttributesTable,
ipsAuthCredChapAttributesTable, ipsAuthCredSrpAttributesTable, and
ipsAuthCredKerbAttributesTable) provide the ability to find out
which names, addresses, and credentials would be required to
access services on the managed system. If these credentials are
easily spoofed (particularly the name or address), read access to
this MIB module must be tightly controlled. When used with
pointers from another MIB module to rows in the
ipsAuthIdentAttributesTable, this MIB module provides information
about which entities are authorized to connect to which entities.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPsec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.
It is RECOMMENDED that implementors consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
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:
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.
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.
[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.
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
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).