Subject: BEEP + transparently forwarding proxies

From: Ben Feinstein <[email-masked]>
Date: Mon, 22 Jan 2001 19:54:51 -0800 (PST)

Darren,

Under IAP, proxies are defined to transparently forward data from sensors
onto managers.  This includes transparently forwarding the TLS handshake
procedure used for establishing end-to-end security between sensor /
manager pairs.  We believe it is desirable, if not a requirement, to avoid
hop-by-hop TLS encryption in the transport protocol.  Our current
understanding of BEEP is that a TLS upgrade equates to a new channel being
created (and all others closed), on a hop-by-hop basis (as described for
the BEEP TLS profile).  There does not appear to be a way to transparently
forward the TLS upgrade to the end-recipient, leaving the proxies in the
middle untouched.

The IMXP-core document claims to support end-to-end confidentiality
(section 3.4 of draft-mrose-imxp-core-01.txt) without requiring hop-by-top
encryption, but does not go into detail about the way in which this is
accomplished. Are you familiar with any method (possibly that used by
IMXP) to create end-to-end security that is transparent to the proxies
involved?

Thanks,

Ben Feinstein & Greg Matthews
Harvey Mudd College,
Computer Science, Class of 2001

---

From: Darren New <[email-masked]>
Date: Tue, 23 Jan 2001 09:59:59 -0800

Ben Feinstein wrote:
> the BEEP TLS profile).

This is a correct description of the current TLS profile.

> There does not appear to be a way to transparently

My expectation of how this would be implemented would be philosophically
similar to how IAP implements it. In other words, one would not open a TLS
channel to the proxy, but rather a plaintext "forwarding" channel. This
channel would not use the current TLS profile, but rather a whole new
profile designed specifically for this type of firewall-tunnelling
operation. 

Basically, I would expect it works as follows:

The originator of the connection contacts the proxy and opens a "forward"
channel (call it Alpha). It sends a message on that (alpha) channel, and the
proxy opens a "forward" channel (call it Beta) to the receiver identified,
returning the results (succeed or fail) over the Alpha channel. The
originator can then send a message over the Alpha channel that is forwarded
thru the proxy onto the Beta channel to open yet another channel, building
up link by link through any number of firewalls. Once the appropriate
endpoint (the final disposition for messages) has been reached, the
originator sends over the "alpha" channel a message to start tunnelling. The
eventual endpoint (sorry, I forget the IAP term) receives it, sends back an
OK, which is propagated back, and which serves to put all the intermediate
nodes into "packet forwarding" mode. At this point, the originator issues a
new greeting, the receiving endpoint issues a greeting, and TLS and/or SASL
negotiation proceeds from there, with the intermediate application-gateway
machines just copying octets with no intelligent processing.

This is a little more flexible than what an IAP replacement would need. It
allows for multiple proxies between the originator and receiver, for
example. This is at the cost of a slight bit of extra overhead in terms of
round-trip times. On the other hand, I can envision easily turning the
simple one-hop no-extra-stuff channel creation into a message passed in the
channel-opening <start> element, with the returning <ok> from that starting
the tunnelling, eliminating extra round trips.

I can imagine this being useful for application proxies, as well. For
example, this profile might be useful for tunelling through firewalls in
general, especially if the application proxy watches the second set of
greetings being exchanged and blocks profiles it doesn't want getting onto
the intranet, for example. But that's speculation outside the scope of the
question here.

> IMXP) to create end-to-end security that is transparent to the proxies

IMXP (now called APEX) would work end-to-end confidentiality in the same way
SMTP does. The individual messages would be sent encrypted, with the
recipient knowing the key. Imagine S/MIME over IMXP, for example. 

I don't imagine this is how you would want to work the IAP stuff, but it
might be. (I would expect this has already been hashed to death at the
working group, actually. ;-)

> Thanks,

So, in quick summary, no, there's no existing defined profile to put an
application proxy into the mode that an IAP replacement wants it in.
However, defining such a proxy is not difficult, and I've worked to make
sure that all our toolkits would support such a definition as easily as they
support TLS. Basically, instead of saying "when you get a <proceed> element,
close all channels and start the TLS negotiation code" the implementation
would say "when you get a <proceed> element, close all channels and start
the packet-forwarding code."

Let me know if there's anything else I can help with?  Thanks!

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST).  Cryptokeys on demand.
"It says this wine has syphilis."
               "I think that's pronounced `sulphates'."