Re: [Isms] ISMS/SSH and notifications
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Isms] ISMS/SSH and notifications



Wes Hardaker wrote:

> The following is based on the message I sent out in January in 2007
> and then later modified in July of 2007.  I've now modified it for a
> third time to fix some errors I found in it and have lengthened some
> of the sections to talk more about the issues recently discussed
> here.

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

Couple of minor comments/questions:

<snip>
> 2.1.1.1 Changes to the TARGET-MIB configuration
<snip>
> snmpSSHParametersTable:
> 
> index:
>    snmpSSHParameterName            sshParams  (matches 
>                                                2nd * above)
> 
> columns:
>    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)

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

>    snmpSSHNGUserPass               ++++       (the passphrase to use if 2)
>    snmpSSHNRHostKey                +++        (the public key             
>                                                expected from the
>                                                expected NR)
> 
>  +++  = potential issue with config via SNMP/UDP since these are
>       potentially larger than SNMP/UDP would like.
>  ++++ = a GET should return "" at all times?
> 
> With all of this in place it is possible for a NG to open a
> connection to a NR and authenticate itself and verify the other end
> is the expected end.  Note that we still haven't discussed user
> names; be patient!
> 
> 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).

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

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

Can't we use snmpTargetParamsSecurityName for this? 

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



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.