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:

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

Is there any precedent for this, e.g. other MIBs that manage
public keys in some way? Or generate new keys?

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

Or to make it more admin-friendly, maybe just pass a name/token of
some kind; the SSH stash would be responsible for handling both 
public and private parts of the key?

(I guess on the SSH server side, we anyway won't have detailed
MIBs for configuring things.)

> > 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
> PE> the securityName value passed to the notification receiver
> PE> application.
> 
> For a user-server connection the security name could be pulled from
> the normal SSH connection.  That's already taken care of.  

Well... the SSH user name seen by the notification receiver (SSH
server) really identifies the notification generator, so it's not 
the same as the securityName given by the notification generator
application. If we want to preserve this property, we need something
else...

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.