Re: [Isms] ISMS/SSH and notifications

[<Pasi.Eronen at nokia.com>]

David Harrington wrote:

> > Hi,
> > 
> > Thanks for a good explanation! I think there's a way to slightly
> > refactor Wes's proposal to make it consistent with the
> > architecture (since I'm making only small adjustments
> > to Wes's text, I'm not quoting it all).
> > 
> > When a PDU is sent, SSHTM will get transportAddress and
> > securityName (and other information). If it needs to open a new
> > connection, it will need some local information (which isn't
> > necessarily a MIB table) to do so. This is almost the same as
> > snmpSSHParametersTable in Wes's text, except that we need to index
> > it by (transportAddress, securityName) and not parameter name
> > (which isn't visible in SSHTM, right?).  So the table would look
> > something like this:
> 
> Yes. and we would define this within the SSHTM specification,
> presumably.  If we wanted to develop one that could work for
> multiple transports, with possible support for different
> securitylevels, then we could add transportdomain and securityLevel
> to the index so we could differentiate the different address types,
> and have connections with/without privacy (for example).
> 
> The indexing is definitely SNMP-related. The other columns seem to
> be purely SSH-related. This raises the question, if we were to do a
> MIB, whether the two parts should be modeled separately, with a
> pointer in the SSHTM table to the relevant row (or whatever) in the
> SSH datastore. What we need for ISMS is the SSHTM side of the table,
> to get a mapping to an SSH-specific datastore.
> 
> > 
> > snmpSSHOutgoingTable:
> > 
> >   index:
> >      snmpSSHTransportAddress     192.0.2.1:162 
> >      snmpSSHSecurityName         "Alice"
> >   columns:
> >      snmpSSHUserName             "Adam"   (I say "I'm Adam")
> >      snmpSSHUserCredentialType   1        (1 = userPublicKey,
> >                                            2 = userPassword,
> >                                            3 = hostPublicKey
> >                                            ... enum list)
> >      snmpSSHUserKeyPair          ++++     (the public/private
> >                                            key pair to use if 1)
> >      snmpSSHUserPassword         ++++     (the passphrase to
> >                                            use if 2)
> >      snmpSSHRemoteHostPublicKey  +++      (the public key
> >                                            expected from peer)
> > 
> > Most importantly, this same table would be used when sending PDUs
> > for command generator -- since SSHTM isn't supposed to know what's
> > inside the PDU.
> > 
> > (Although there's one difference in how the table would be
> > typically configured; on management stations, a common
> > configuration would use same string in both snmpSSHSecurityName 
> > and snmpSSHUserName, while on agents, they would be typically
> > different.) 
> 
> You used "management station"; did you mean SSH server? The SNMPv1
> distinction between manager and agent went away with the RFC3411
> architecture. From an RFC3411 architectural perspective, both ends are
> just entities that can include any of the applications. The TM, SM,
> MPM, and dispatcher don't know or care what role the entity is acting
> in, and in the case of a manager-to-manager Inform or agent-to-agent
> Inform, there is no manager/agent pairing.  We need to avoid
> assumptions that TM and SM and MPM processing for manager and agent
> are different; the difference only happens inside the application
> layer. 

I agree that the processing should be the same; by "management station", 
I simply meant an SNMP entity that (in this context) doesn't usually call 
isAccessAllowed(), while the "agent" does that all the time (for both 
commands and notifications).

> I would like to reach consensus on separating the SSHTM table from the
> SSH-specific stuff, with a pointer in the SSHTM table to a row in an
> SSH table. That would allow us to get from the TargetTable to the
> pointer in the SSHTM table. 
> 
> SSHTM table:
> 
>    index:
>       snmpSSHTransportDomain      snmpSSHDomain
>       snmpSSHTransportAddress     192.0.2.1:162 
>       snmpSSHSecurityName         "Alice"
>       snmpSSHSecurityLevel        authPriv
>    columns:
>       snmpTMCredentialsEntry      "27"
> 
> then we narrow the discussion to become purely an SSH client 
> vs server matter.

This would be the table used when SSMTM acts as SSH client.  When it
acts as SSH server, the information needed (and how it's indexed) 
is different -- see more below.

> > The side acting as an SSH server also needs some information 
> > (which might not be a MIB table); this is similar to the 2nd
> > snmpSSHParametersTable in Wes's text, except we index it 
> > by user name:
> > 
> > snmpSSHIncomingTable:
> 
> Remember that requests, responses, and notifications are all outgoing
> messages. (RFC3411 was designed to permit additional applications to
> be added later if desired, possibly using new SNMP protocol versions,
> so we shouldn't preclude the possibility there are other message types
> as well.) What we know in the TM is what is passed via the ASIs.

Right, my choice of terminology was poor; "snmpSSHOutgoingTable"
should have been called "snmpSSHClientTable" and
"snmpSSHIncomingTable" is "snmpSSHServerTable". Even for ordinary
request/response, both are needed, and TM doesn't indeed know what 
the PDU is.

> If we need to use server-auth rather than user-auth for notifications,
> then we need to tell operators they should configure the paramstable
> for notifications with the appropriate host identity. Assume user
> "Alice" is located at host "gandalf". If the admin wants to send traps
> to host gandalf, rather than specifically to Alice, then put an entry
> for gandalf in the target/paramstable configuration.
> 
> To support ACM, add gandalf to the userToGroup table in VACM (or
> suitable table for other ACM). This might be the same or different
> group than Alice belongs to.

Yes, this would work. The admin could also decide that the host
authenticating with certain host key is "authorized representative" 
of Alice, and simply have single Alice entiry in VACM. This would
be purely a configuration issue -- in this case, the tables
could contain something like this:

-- table that's used when SSHTM needs to open a connection in
-- SSH client role
snmpSSHTMClientTable:
   index:
      snmpSSHTransportDomain        snmpSSHDomain
      snmpSSHTransportAddress       192.0.2.1:162 
      snmpSSHSecurityName           "Alice"
      snmpSSHSecurityLevel          authPriv
   columns:
      snmpSSHClientParameters       "27x"

snmpSSHClientParameterTable:
   index:
     snmpSSHClientParameters     "27x"
   columns:
     snmpSSHUserCredentialType   1        (1 = userPublicKey,
                                           2 = userPassword,
                                           3 = hostPublicKey
                                           ... enum list)
     snmpSSHUserKeyPair          ++++     (the public/private
                                           key pair to use if 1)
     snmpSSHUserPassword         ++++     (the passphrase to
                                           use if 2)
     snmpSSHRemoteHostPublicKey  +++      (the public key
                                           expected from peer)

-- table used when SSHTM establishes a connection in SSH server role
snmpSSHServerTable:
   index:
     snmpSSHUserName             "alicek"  (peer says "I'm alicek")
  columns:
     snmpSSHSecurityName         "Alice"   (this is what gets
                                           passed outside SSHTM)
     snmpSSHServerParameters     "99foo"   (how the SSH client is
                                            authenticated)
snmpSSHServerParameterTable:
   index:
     snmpSSHServerParameteres    "99foo"
   columns:
     snmpSSHUserCredentialType   1        (1 = userPublicKey,
                                           2 = userPassword, ...)
     snmpSSHUserPublicKey        +++      (the public key to use if 1)
     snmpSSHUserPassword         +++      (the correct password if 2)

And I agree that of these tables, snmpSSHClientParameterTable and
SNMPSSHServerParameterTable don't have to be MIB tables, but could be
just data structures in the SSH implementation. Since the details
will anyway depend on the implementation (and as Jeffrey pointed
out, get complex for GSS-API and keyboard-interactive), that's 
probably the best solution.

Best regards,
Pasi
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms