Subject: RE: [Isms] Discussion: Architecture direction for ISMS

From: "Martin Soukup" <[email-masked]>
Date: Wed, 13 Apr 2005 08:28:22 -0400

Why does the reverse communication require any different configuration, or
are you just concerned because you have to configure both ends of the
communication (which we need to do anyways in USM)?

Martin.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Robert Story
> Sent: April 13, 2005 8:14 AM
> To: Sam Hartman
> Cc: [email-masked]
> Subject: Re: [Isms] Discussion: Architecture direction for ISMS
> 
> 
> On Tue, 12 Apr 2005 16:22:24 -0400 Sam wrote:
> SH> Why is this true?  If all engines have credentials they 
> can use, why 
> SH> can't you open a session if you need one?
> 
> My concern was was with regards to fitting into an existing 
> infrastructure where unsolicited communication was not the 
> norm. I use ssh as an example, because I am not familiar with 
> TLS. While a ssh session does establish a key for the peer 
> host, additional configuration would be needed to allow that 
> peer to autonomously establish connections back to the 
> originator's host.
> 
> With one of the goals of ISMS being re-use of existing 
> infrastructure, I was just thinking that for some 
> infrastructures (eg ssh), get and set would easily fit, but 
> notifications would require more thinking.
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms
> 
> 
_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Robert Story <[email-masked]>
Date: Wed, 13 Apr 2005 09:17:44 -0400

On Wed, 13 Apr 2005 08:28:22 -0400 Martin wrote:
MS> Why does the reverse communication require any different configuration,

Again, I'm using the specific example of ssh in its current form. To
communicate with a peer:

1) generate my private/public keys
2) configure peer with my public key
3) connect to host (and peer host key is save for future reference)

This is the existing infrastructure that I am referring to. Note that while I
do have a key for the host, it is only used to verify that I'm talking to the
same host the next time I connect.

To allow the host to connect back to my machine autonomously, I would have to:

4) generate a private/public key on the peer (possibly could re-use host key)
5) configure my host with the peer's public key
6) install/configure/run ssh server

The point is that these steps are extra, and not part of the configuration of
the existing infrastructure.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Apr 2005 06:30:54 -0700

> the existing infrastructure.

In SSL, at least, this problem has already been attacked in the
context of FTP, which involves callbacks on the data channel.
Basically, you do session resumption but the party that does
the active open (what one would think of as a TCP client)
acts as the SSL server. See draft-murray-auth-ftp-ssl-16.txt
(though the text isn't as clear as it could be).

Note that this assumes you want to tear down the TCP
connection. If you don't, then there's no problem, of course.
Incidentally, with DTLS you can just leave the DTLS association
up.

-Ekr