Re: [Isms] open issues

[<Pasi.Eronen at nokia.com>]

Juergen Schoenwaelder wrote:

> So is the conclusion here that SSH is a dead end? Do we have to
> revisit the discussion of SSH vs. TLS?

I'm not sure if the situation would be considerably simpler even with
TLS... or it would require small extensions to TLS.

Suppose a command responder authenticates connections with TLS and
client certificates. A certificate from trusted CA, containing name
"john.admin at example.com", would give access with that securityName,
and things would probably largely as you'd expect.

However, for the notification originator part, if the same
transportAddress has multiple different notification receivers, the
notification originator, when starting TLS handshake, would need to
tell the receiver "I have stuff to send to john.admin at example.com", 
so that the receiver would know to authenticate with that certificate
(instead of, say, "mgmtpc4.example.com" or "alice.admin at example.com").

Current TLS doesn't support that; you'd need to extend the 
the server_name TLS extension to support other types of identities 
than host names. 

And if a given transportAddress has just one principal behind it, 
we don't really have problems with SSH either, right? 

On the other hand, even if you do have multiple principals, the
software receiving the connection would still have access to both
John's and Alice's private keys. So we're trusting it anyway...

What if the SSHTM also included a security model that didn't
actually do any crypto or anything, but just included the 
securityName in the PDU so that the notification recipient could 
do internal processing (knowing that this notification should
be seen only by John)? Or perhaps there are some easier ways
to achieve this?

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