Re: [Isms] ISMS/SSH and notifications

[Wes Hardaker <wjhns1 at hardakers.net>]

PE> I think this looks pretty good! (Although there are really two
PE> quite different solutions, depending on which of the parties
PE> opens the SSH connection.)

Yep.  It's still up for debate if we want to allow the manager to open
the connection.  A few years ago it was looking like we should do it.  I
think desire has fallen a bit since then.  I'm not really sure it's
necessary and worth the complexity increase, but I'm not opposed to it
either.

>    snmpSSHUserName                 Adam       (the NG says "I'm Adam")
>    snmpSSHUserCredentialType       1          (1 = userPublicKey,
>                                                2 = userPassword,
>                                                3 = hostPublicKey
>                                                ... enum list)
>    snmpSSHNGUserKey                +++        (the expected NG Key if 1)

PE> Should this be "++++ (the NG public/private key pair if 1)"?

Yep.  Good point.

(though a GET could return the public half)

And it would probably be better to have 2 columns, one for the public
key and one for the private.  Or a button to generate a new key pair and
that column would just return the public half of the generated pair and
thus the private never has to traverse the network (but then we get into
key generation parameters etc).  Though we could also just opt-out of
the whole configuration pile and say "use this public key; you'd better
have the private somewhere in your ssh stash" (and a SET of an unknown
public key would then fail with an error). 

> It is implementation dependent how the NR decides whether to
> accept notifications given the authentication provided by the NG.
> This is already true for SNMPv3/USM NR engines today (there is no
> NR authorization model in the SNMPv3 STDs).

PE> I guess one detail that still needs to be described is what's the
PE> securityName value passed to the notification receiver application.

For a user-server connection the security name could be pulled from the
normal SSH connection.  That's already taken care of.  For a host based
authentication you're right...  maybe we should require the NR to accept
the host based authentication name for the NR to use as a securityName.
I haven't checked what the legal lengths of a host-based SSH
authentication name can always fit within a securityName field (which is
only 32 octets long).

<snip>
> 3. VACM Authorization
> 
> Here's where the important note discussed above comes into play: the
> VACM doesn't care how the securityName passed to it was derived and
> authenticated.  It's not the job of the VACM to do that.  It trusts
> the CR and NG engines to have done the right thing security wise.
> 
> A lot of discussion has surrounded this point.  What does the VACM
> use when doing authorization lookups?  The NR/SSH server doesn't
> have a "user name" in the traditional sense of the word.  It has
> proven that it has an adequate host key, however.
> 
> Choices:
> 
> 1) The local configuration has already dictated a user name to use
>    via the snmpSSHUserName setting discussed above (assuming the
>    text in this document is followed).  This is the value that
>    should be given to the VACM (along with an appropriate 
>    model and level settings based on the connection).  It doesn't 
>    matter that the remote host didn't specify this value in the 
>    connection; the local configuration says this is the value that 
>    should be used and the remote side *has* proven that it can 
>    authenticate the NR host key that was expected.
> 
> But, this doesn't allow for dual-user name support, which brings
> us to option 2:
> 
> 2) If there is desire to have the NG/SSH-Client use one user name to
> authenticate itself to the remote NR/SSH-Server and another to
> consider the remote NR/SSH-Server to be for purposes of VACM
> authorization then another column in the snmpSSHParametersTable
> would be needed that might have something like:
> 
>        snmpSSHRemoteUser                   "Jack"
>
> Again, it does not matter that the remote side didn't technically
> specify itself as "Jack".  It's already proven that it has the
> configure remote host key.

PE> Can't we use snmpTargetParamsSecurityName for this? 

Yes.  Somehow I forgot about that column.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms