RFC 4545, "Definitions of Managed Objects for IP Storage User Identity Authorization", May 2006

Errata ID: 60
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-06-29
Held for Document Update by: Lars Eggert

(1)  typo in Abstract

The Abstract, on page 1 of RFC 4545, contains the sentence:

   [...]
   In particular, it defines objects for managing user identities and
|  the names, addresses, and credentials required manage access control,
   for use with various protocols.  [...]

The text should say (filling in the missing 'to'):

   In particular, it defines objects for managing user identities and
|  the names, addresses, and credentials required to manage access
   control, for use with various protocols.  [...]


(2)  typo in Section 5

The first paragraph of Section 5, on page 4 of RFC 4545, says:

   The User-based Security Model (USM) [RFC3414] also defines the
   concept of a user, defining authentication and privacy protocols and
   their credentials.  The definition of USM includes the SNMP-USER-
|  BASED-SM-MIB module allows configuration of SNMPv3 user credentials
   to protect SNMPv3 messages.  [...]

The text should say (filling in the missing 'that'):

   The User-based Security Model (USM) [RFC3414] also defines the
   concept of a user, defining authentication and privacy protocols and
   their credentials.  The definition of USM includes the SNMP-USER-
|  BASED-SM-MIB module that allows configuration of SNMPv3 user
   credentials to protect SNMPv3 messages.  [...]


(3)  clarification in Section 7

The first paragraph of Section 7, on page 5 of RFC 4545, says:

|  This MIB module structure is intended to allow the configuration of a
   list of user identities, each with a list of names, addresses,
|  credentials, and certificates that, when combined, will distinguish
   that identity.

The wording should be enhanced, and the reference to certificates
should be removed -- these apparently have been excluded from the
MIB in the published version.

Therefore, the text should perhaps better say:

|  This MIB module's structure is intended to allow the configuration of
   a list of user identities, each with a list of names, addresses, and
|  credentials that, when combined, will distinguish that identity.


(4)  improper DESCRIPTION text

The DESCRIPTION clause for the ipsAuthIdentAddrAttributesTable
OBJECT-TYPE, on page 19, says:

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

This text improperly mentions the use of netmasks, which has been
explicitely excluded from the MIB module, as can be seen from the
subsequent IpsAuthIdentAddrAttributesEntry syntax, and as explained
in the last paragraph of Section 7.5, on page 8 of the RFC.

Therefore, this clause should say:

       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 address type indicator, which can specify whether
           the address is IPv4, IPv6, FC-WWPN, or FC-WWNN."


(5)  redundant MIB objects -- serious danger of inconsistency

Conceptually, rows of the ipsAuthCredChap, ipsAuthCredSrp, and
ipsAuthCredKerberos tables are a variant record (union in "C")
contained in the corresponding rows of the ipsAuthCredential table.
The DESCRIPTION clauses make clear, that the 'life' of the former
table rows is directly coupled to the 'life' of the latter rows --
for example, the DESCRIPTION clause of the ipsAuthCredAuthMethod
OBJECT-TYPE says:

           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.

IMHO, it is inconsistent to have the agent delete the row, but
let the management station create the row; the SETting of an
ipsAuthCredAuthMethod object should create the corresponding row.
According to this explanantion and the identical indexing structure
of the four tables, the agent thus is directed to maintain exactly
one of those variant rows, matching the current value of a given
ipsAuthCredAuthMethod instance.

In the published version of the IPS-AUTH-MIB module, the rows
of the basic ipsAuthCredentialAttributesTable contains objects of
RowStatus and StorageType syntax that are used to create/activate/
delete an ipsAuthCredentialAttributesEntry conceptual row, and to
specify the persistence behaviour of that row, respectively.

Therefore, IMHO it makes no sense, and it entails the danger of
fundamental semantic inconsistencies in the MIB module, to also
maintain objects of RowStatus and StorageType syntax in the
variant table rows.
E.g.,
- no `active` row can exist in the ipsAuthCredChapAttributesTable
  without a corresponding `active` row in the
  ipsAuthCredentialAttributesTable;
- no ipsAuthCredChapAttributesEntry can be created by the manager,
  that MUST be done automatically by the agent when the
  ipsAuthCredAuthMethod instance is set to ipsAuthMethodChap;
- the ipsAuthCredentialAttributesEntry should be set inactive,
  if desired, and not the ipsAuthCredChapAttributesEntry;
- the StorageType of both entries MUST be exactly the same.

Therefore, IMHO the objects
  o   ipsAuthCredChapRowStatus,
  o   ipsAuthCredChapStorageType,
  o   ipsAuthCredSrpRowStatus,
  o   ipsAuthCredSrpStorageType,
  o   ipsAuthCredKerbRowStatus,  and
  o   ipsAuthCredKerbStorageType
should be deprecated as soon as possible, and its MAX-ACCESS
changed to read-only, with explanation added to the DESCRIPTION
clauses that the values of these objects (if implemented), are
agent maintained mirrors of the corresponding ipsAuthCredRowStatus
and ipsAuthCredStorageType objects, respectively.

Additionally, it should be specified that a ipsAuthCredRowStatus
instance must not be set to `active` unless the proper credentials
have been set in the appropriate ipsAuthCred* "detail" row.

If it is decided that automatic row creation by the agent should
not be specified for backwards compatibility, at least the
ipsAuthCred*StorageType objects should be deprecated.


(6)  clarification in compliance statement

The DESCRIPTION clause of the ipsAuthComplianceV1 MODULE-COMPLIANCE
says:

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

Similar to item (3) above, the reference to 'Certificate' is
inappropriate and should be deleted; additionally, the plural
form of 'Credential' should be used.

Thus, this clause should say:

       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,
|          Credentials) is also mandatory for any given
           implementation."


(7)  incomplete citations

The following References are incomplete according to RFC-Ed policy;
they should be amended by  "STD 62, "  just before the RFC number.

In Section 11, on page 40, the entry:

   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", RFC 3411, December
              2002.

should say:

   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
              December 2002.

In Section 12, on page 41, the entry:

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

should say:

   [RFC3414]  Blumenthal, U. and B. Wijnen, "User-based Security Model
              (USM) for version 3 of the Simple Network Management
              Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.

Notes:

I make use of change bars ('|' in column 1) to emphasize the
location of textual issues and/or proposed textual changes.
Modified text is re-adjusted according to RFC formatting rules.

The items below are listed (and enumerated) in RFC text sequence.
Item (5) apparently is a serious issue.
All other items are simple errata.

from pending

Report New Errata