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:
> I would argue that for a symmetric cryptography using SM like USM
> we'd expect them to be the same. I don't necessarily think that's
> true for an asymmetric system like any public/private key system.
> What we use to identify ourselves as the "client" will be
> differently named than what we use to identify the remote side.
> Naming wise, no, I don't think they need to be the same (since it
> doesn't buy you anything). As a client I may be configured to be
> "wes" but I'm not expecting to talk to "wes" at the other end. I'm
> expecting to talk to "bob".
>
> Most importantly, I'm expecting to talk to another transport end
> that meets my security requirements for proof of identity
> requirements. SSH proves that sufficiently for me to trust it.
> Thus I can choose to call the remote side "bob" (or "wes" too if you
> really wanted to) as long as the more important aspect is still
> true: they've cryptographically shown me I've connected to the right
> place given the message I want to send. I honestly don't care about
> the name; I care about the cryptography.
I agree; if the Notification Originator side (probably either SSHTM or
SSH module) has information mapping the local securityName (given the
the NO application, and used locally for VACM checks) to the public
host key that the SSH server must authenticate with, then we seem to
have sufficient proof for sending the notification.
The fact that there could be multiple local securityNames (possibly
having different access rights in VACM) mapping to the same SSH server
host public key doesn't make this proof insufficient.
(I.e., if configured so, notifications with securityNames "alice" and "bob"
could be sent to the same transport endpoint (SSH server), authenticating
with a single host key.)
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.