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.