SACRED over HTTP (was: RE: sasl in beep or payload)

> > 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.
>
> Agree with having exactly one way of exchanging PDUs.
>
> However, HTTP is *not* a viable candidate for one of those ways.
> So it's either BEEP or something else.
>

I believe that the argument in favour of HTTP is not that it is a protocol
ideally suited to the requirements of SACRED but a pragmatic one.  Many
SACRED platforms already support HTTP and since it can be used for our
needs then if SACRED is to be widely accepted it will probably need to
support HTTP as a transport.

> > 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.
>
> entirely true.  I'd also argue that expecting a persistent
> connection violates
> the HTTP standard.
>
> If you want to exchange multiple PDUs per transaction in HTTP, you
> essentially have to have each request (except the first) PDU contain a
> state identifier which was provided in the last response PDU received.
>

I don't see why carrying the sasl payload assumes a persistent connection
since, as Keith points out, we cannot assume this.  Part of the HTTP
binding document would be a definition of how state is maintained.  I would
expect that this would probably be done by adding an extra wrapping layer
to the PDU (which seems to be what Keith is suggesting) rather than by the
use of cookies (RFC2964 and RFC2965).

> but there are other problems with HTTP.  it's completely unacceptable to
> reuse port 80 or http: URIs for a new application, and bypassing site
> security policy (e.g. firewalls) is NOT a legitimate goal.

I can see that SACRED would be a new service and so should use a new port
etc but it can't be the only protocol considering using http in this way
(CMC and CMP have documented HTTP as a binding and do not seem to tackle
the reuse of port 80 or http: scheme).

> 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).

The current I-D proposes to use SSL for the account creation and so
wouldn't it be susceptible to this attack?  This does not seem to be
specific to HTTP but to any system using SSL.  Our proposal would have the
same exposure through its use of SPKM-3 but in both cases this would only
be for account creation which should therefore only be implemented by
clients in more controlled environments.