re: sasl in beep or payload

> From: Marshall Rose <[email protected]>
> To: <[email protected]>, ietf-sacred <[email protected]>
> Cc: Marshall Rose <[email protected]>
> Subject: Re: sasl in beep or payload...
> Date: Thu, 13 Dec 2001 17:26:09 -0800
> 
> 
> > 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.

these are separate issues.  the issue of where the sasl payload goes
mostly has to do with the coupling of the authentication mechanism and 
the application.  

having the authentication happen at the application layer rather than 
the session layer means that the application is responsible for doing 
authentication, rather than asking a lower layer to do it.  having this
done at the same layer potentially makes it easier for the application 
to specify exactly which authentication credentials are valid and what 
permissions should be granted to each principal.  it also potentially
makes the application code more portable.

(it might also allow the use of the application protocol over multiple
transports, but since running an application over multiple transports 
degrades interoperability and is likely to harm security, I don't 
consider that a justification.)

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

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

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.  the HTTP 
application infrastructure is unreliable and unpredictable - there are 
several firewalls and filters in place that alter HTTP traffic. by the 
time you get HTTP to do what you need it takes more work - and more 
total code - to layer over HTTP than TCP.

reusing HTTP is a false economy, especially in the long run.

Keith