[Isms] mapping here, mapping there, mapping everywhere

[Wes Hardaker <wjhns1 at hardakers.net>]

I know David has expressed multiple times that he thinks we have too
many securityName mapping locations and the current documents have them
all in place even though he's not convinced they're all needed.  Here's
my analysis of the current (complex) state.  I'm including DTLS in the
pipelines below since I think it helps show where two different
transports come together and where the mapping-system merges.  The
"prefix" support (ssh: and dtls:) are what has been discussed recently
in another thread.  The following diagram depicts the *potential* sets
of mapping components that exist in the various modules (it's "potential"
because some are still in the air as far as a decision goes):


  +---------+     +------+     +-----------------+     +----------+       
  |   SSH   |     | SSH  |     |      sshtm      |     |   add    |       
  |  user   |     |  TM  |     |    LCDTable     |     |   ssh:   |       
  |  name   | --> |      | --> |       map       | --> |  prefix  | ------+
  +---------+     +------+     +-----------------+     +----------+       |
                                                                          |
                                                                          |
                                                                          |
                                                                          v
  +---------+     +------+     +-----------------+     +----------+     +---+
  |  DTLS   |     |      |     |     dtlstm      |     |   add    |     |   |
  |  X509   |     | DTLS |     |     CertTo      |     |  dtls:   |     | * |
  | Subject |     |  TM  |     |     SNTable     |     |  prefix  |     |   |
  |  Field  | --> |      | --> |       map       | --> |          | --> |   |
  +---------+     +------+     +-----------------+     +----------+     +---+



  +---------+     +------+     +-----------------+     +----------+
  |         |     |      |     |   snmpTsmLCD    |     |   vacm   |
  |         |     |      |     |   DomainTable   |     | Security |
  |    *    |     | TSM  |     |       and       |     |    To    |
  |         |     |      |     | snmpTsmLCDTable |     |  Group   |
  |         |     |      |     |                 |     |  Table   |
  |         |     |      |     |                 |     |  (Size   |
  |         | --> |      | --> |                 | --> |   1..32) |
  +---------+     +------+     +-----------------+     +----------+



So the steps, starting from the beginning:

1. The transport authentication system passes in "something" that the TM
   has to make use of.  EG, the SSH user name or the X509 Certificate
2. The TM transforms this input into a local tmSecurityName.  For SSH
   this is done through the sshtmLCDTable and for DTLS this is done
   throuh the snmpTsmLCDDomainTable.
   + Some TMs may have binary blobs to identify users by.  They will
     definitely have to provide some sort of to-text-mapping.
   + Some TMs may have strings that are too long to pass to much of the
     SNMP infrastructure
     - SSH may allow longer lengths than 32 for user names?  I couldn't
       find this anyway, but suspect it's true.  It's not, however, true
       in real world practice and deployment at this point though (AFAIK).
     - X509 provides a good example for this: The Subject: field of a
       X509 cert is typically much longer than would be acceptable as an
       identifier by SNMP.
3. The TM prefixes the derived tmSecurityName with a unique identifier
   (eg ssh: or dtls:) to help identify exactly which protocol it came in
   over.  This is one of the current outstanding proposals that appears
   to have reached consensus.
4. The TM passes the final derived and prefixed tmSecurityName to the
   TSM via the tmStateReference.
5. The TSM obtains the tmSecurityName and possibly strips the ssh: or
   dtls: prefix off (the default is to strip it).
6. The TSM transforms the security name, based on the domain it's
   received on (eg ssh or dtls) either:

   a) as a 1:1 mapping if snmpTsmLCDDomainTable points to "default"
   b) as a private mapping if snmpTsmLCDDomainTable points to "private"
   c) drop the message because the mapping is set to "disable"

7. The snmpTsmLCDTable possibly maps an individual tmSecurityName to a
   different securityName.  By default this is populated with the
   results from #6, *but* it is editable so it's assumed that a
   management station could (I'm unclear on this):

   + change the value after a session is up?
   + change the value for future sessions?

   + I'm also not clear when this table is consulted, since it's usage
     not discussed in the EOP.  If it's merely a recording table of what
     has taken place or is live, then why is it read-create?  If it can
     be set up by a manager then when during the EOP is it consulted?
     Order matters since there are 3 multiple mapping systems within the
     TSM itself (one of which is the prefix string dropping).
8.  Finally the VACM itself maps a securityName to a group name in it's
    processing, which is really where the consumer of the information
    gets to make a decision.


So...  did I go wrong anywhere in all of that writeup David?  If so, where?


What I propose, assuming I didn't blow my analysis somewhere, is to:


A)  Drop the snmpTsmLCDTable.  I think the usage of the ssh: and dtls:
    prefixes actually removes the need for the more complex mapping (and
    in fact that was the purpose of the string prefixes: to meet in a
    middle ground for complex mapping vs no mapping).

B)  Drop the sshtmLCDTable mapping support.  The only real reason this
    is needed if we do have a string: prefix would be to map long user
    names to short ones and I don't think it's needed based on current
    usage at least.  We would likely need a counter for
    "userNameTooLong" or something just to provide failure reason
    detection.

    (note: DTLS still needs a mapping table from the longer X509 fields
    to the shorter securityName fields)


I think dropping those tables should make the mapping-haters happier as
well as still allowing simple minimal mapping via the string prefixes
available.


The outgoing case is pretty much a reversal of the above but doesn't
really benefit as much from the mapping in the first place (aside from
selecting a user name and credentials).  The username@ prefix to the
transport address for SSH actually solves much of the need for outgoing
securityName mapping on the SSH side of things.


Hopefully this may help address some of David's concerns about too much
mapping being in existence as well as simplify some of the mib
implementation requirements.

-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms