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

From: "Gareth Richards" <[email-masked]>
Date: Wed, 19 Dec 2001 10:51:40 -0000

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Dec 2001 09:08:50 -0500

> support HTTP as a transport.

this is a misconception.  the fact that HTTP is already supported on
some of the SACRED platforms does not mean that it is easier to use
HTTP than to use another protocol.  HTTP actually gets in the way because
its framing and error reporting are not what you need for SACRED, 
and because HTTP caches and firewalls actually degrade interoperability.  
Put it this way: those same platforms implement TCP, and TCP is a better
fit for what SACRED needs than HTTP.

> the reuse of port 80 or http: scheme).

I'm not sure what you mean by CMC and CMP but IETF has not standardized
another application using port 80, and I suspect they are extremely unlikely
to do so.  AFAIK the only other application IETF has standardized using
HTTP is IPP, and that was a huge mistake - resulting in unnecessary complexity 
and delay in defining IPP with no measureable benefit.
 
Keith

---

From: "Gareth Richards" <[email-masked]>
Date: Wed, 19 Dec 2001 16:24:39 -0000

> fit for what SACRED needs than HTTP.

One of the reasons for using HTTP is that we will be able to re-use the
existing infrastructure etc and not having to invent our own framing which
we would have to do if we went the TCP route.

Can you explain why HTTP's framing is not suitable?

> and delay in defining IPP with no measureable benefit.
CMP - Certificate Management Protocols.
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-06.txt

CMC - Certificate Management Messages over CMS
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-rfc2797-bis-01.txt

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Dec 2001 11:47:41 -0500

> we would have to do if we went the TCP route.

you end up inventing your own framing anyway, but it's more complex if
you have to layer it over HTTP. 

> Can you explain why HTTP's framing is not suitable?

each HTTP transaction is separate.  there is no assurance that multiple
HTTP transactions for the same request-URI share the same TCP connection
or even that they get sent to the same host.  HTTP caches may route them
differently.

The other reason that it is not suitable is that with HTTP you have to 
do extra work - by adding headers - to discourage caches from interfering 
with your payload.  the existing infrastructure for HTTP doesn't help you; 
rather, it gets in your way.

TCP gives you a bidirectional sequence of octets, with order preserved
(without doing stop-and-wait), duplicates suppressed, and clean termination.

HTTP gives you the ability to make requests of a URI, with no assurance
that order will be preserved unless you do stop-and-wait, no duplicate
suppression, and no assurance of clean termination.  HTTP has more overhead
than TCP and is a poorer match for SACRED than TCP.  And unlike IP routers,
HTTP intermediaries are likely to modify the payload in undesirable ways.

Keith

---

From: "Marshall T. Rose" <[email-masked]>
Date: Wed, 19 Dec 2001 12:01:48 -0800

> use of cookies (RFC2964 and RFC2965).

time for a reality check: why don't you flesh out the actual protocol you're
talking about here that you're going to end up layering on top of http.

having gone through this exercise many times before, i think you will find
that you are adding 15-20 pages of spec to deal with administriva that you
get for free with beep and that you'll have to implement over http, thereby
negating much of the value from the 'reuse http' arguments.

if you could count on persistent connections, the problem you seek to solve
would merely be "hard but tractible", by having to manage state across
multiple sessions for the purpose of authentication, it has become
"problematic"...

/mtr