Re: sasl in beep or payload...

> Around 15 hands were raised in response to the question: "how
> many are likely to implement sacred". Of those, all but one
> agreed with the proposition that we should include the sasl
> PDUs in the sacred payload. So, the concensus at the meeting
> is to add new messages along the lines of the bind request
> and response from Magnus' posting.
>
> If there are enough people unhappy with this, I'll start a
> straw poll on the list in a few days so we can sort it out.

stephen - this analysis simply isn't germane (nor is the sampling
methodology, but that's another issue).

the real issue isn't where the sasl payload goes. the real issue is whether
we want to support http and/or whether we want to support multiple ways of
exchanging sacred pdus.

there was considerable pushback in the meeting from lots of folks that
having two ways of exchanging sacred pdus was bad. earlier posts on the
mailing list pointed this out as well. i'll summarize it: more ways of
exchanging sacred pdus = less interoperability between products.

so, let's do this: let's all agree that we're going to have exactly one way
of exchanging sacred pdus. if the working group reaches concensus that it
should be http, then let's just scrap the beep part and move on. i can
certainly live with that.

with that in mind, i'm going to explain why using http to move sacred pdus
is problematic.

1. carrying sasl payloads in sacred pdus assumes that all of the exchanges
will occur over a single persistent http connection, i.e., open an http
connection, send something, recv something, send something, recv something,
close the http connection.

unfortunately http proxies, caches, and the etc., invalidate this
assumption. the http client can't control this. what this means is that it
is entirely possible to get one send/recv exchange done and then lose the
http connection because of an intermediary.

of course, an easy way to disprove this argument is to point to an existing,
deployed protocol that layers on top of http and carries sasl payloads in
its own pdus, and actually manages to do this. i couldn't find any. (i could
find any. there are two I-Ds talking about using sasl generically in http --
magnus is a co-author of one -- but neither approach is compatible with the
approach of carrying sasl payloads in sacred pdus).

2. exchanging sacred over http/ssl (without sasl) has its own problems,
again due to the fact that the presence of firewalls and proxies are
incompatible with the required end-to-end properties.

for example, transparent man-in-the-middle attacks are possible if there is
"coordination" between the company that runs the firewall, that
supplied/configured the client, and the certificate authority (obviously the
use of "coordination" is a euphemism, but the exploit is fairly well-known).

given the rather significant importance of actually having an end-to-end
encrypted path for the credential transfer, i think this is pretty much a
non-starter.


so, what we're left with is this: when using http to exchange sacred pdus,
you can't use sasl and you can't trust ssl...

of course, if the working group gets concensus that they want to use http,
then let's blow the bolts on the beep stuff, use http and just move on.

/mtr

ps: for guys who implement in small footprints, i will point out the
obvious: if you implement over http, you're going to write your own tiny
http stack, in which you cut lots of corners. the same is going to be true
for beep. since sacred pdus are xml-encoded, you have to do this in either
case. so, the size issue is a red heering.