Re: [Isms] ISMS/SSH and notifications

["David Harrington" <ietfdbh at comcast.net>]

> -----Original Message-----
> From: Pasi.Eronen at nokia.com [mailto:Pasi.Eronen at nokia.com] 
> Sent: Friday, May 16, 2008 6:41 AM
> To: ietfdbh at comcast.net; isms at ietf.org
> Subject: RE: [Isms] ISMS/SSH and notifications
> 
> 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 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.
> 
> 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.

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.

Then, in the SSHTM table, we have an entry for Alice and one for
gandalf. These point to SSH entries for "adam" and "gandalf". (I
changed the indexing just to show that these values are not
semantically important. Human-redaable tags could still be used to
make it easier for operators in the general case)

When securityname=Alice, such as for get-requests, that will map to
user-auth for "adam". When securityname=gandalf, that will map to
host-auth for gandalf.

> 
>   index:
>      snmpSSHIndex                "27"   
>   columns:

>      snmpSSHCredentialType   1        (1 = userPublicKey,
>                                        2 = userPassword,
                                         3 = hostPublicKey,
                                             ...)
>      snmpSSHuserName          "adam"   (user anme when using
user-auth)

>      snmpSSHcredential        +++      (user public key to use if
type=1)
                                         (user password if type=2)
                                         (host public key if type=3)
> 
> 
>   index:
>      snmpSSHindex                "28"   
>   columns:
>      snmpSSHUserCredentialType   3        (1 = userPublicKey,
>                                            2 = userPassword, 
                                             3 = hostPublicKey,
                                             ...)
>      snmpSSHHostName         "gandalf"   (this is what gets
>                                            passed outside SSHTM)
>      snmpSSHcredential        +++      (user public key to use if
type=1)
                                         (user password if type=2)
                                         (host public key if type=3)
> 

--

This table can be expanded for different types of credentials using
AUGMENTS if necessary. I think the union discriminator we are using is
inappropriate; We need a column for authtype (user/host) and for
authcredentials (public key, password, etc., because user-auth
supports multiple credential types.) 

Ideally, the SSH credential is really only in the SSH confguration,
not in the SNMP configuration. So we might be able to get by with an
SSH table containing only the index value, user- or host- auth flag,
and an (implementation-dependent) index into the associated SSH config
that would contain the "adam" user-auth credentials and the "gandalf"
host-auth credentials. 

OR, if we are really lucky, the index from the SSHTM table points
directly to the SSH config without needing our own SSHTable.


David Harrington
dbharrington at comcast.net
ietfdbh at comcast.net
dharrington at huawei.com
 

_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms