Subject: re: sasl in beep or payload

From: Keith Moore <[email-masked]>
Date: Mon, 17 Dec 2001 13:25:37 -0500

> From: Marshall Rose <[email-masked]>
> To: <[email-masked]>, ietf-sacred <[email-masked]>
> Cc: Marshall Rose <[email-masked]>
> 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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Dec 2001 14:42:40 +0000

> > From: Marshall Rose <[email-masked]>
[...]
> mostly has to do with the coupling of the authentication mechanism and

I agree with Keith and since no-one else seems to be arguing for
sticking with the sasl-in-beep approach, I'll push those up to
the payload in the next version.

Just to be clear - this doesn't at all address the http/beep issue.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Dec 2001 07:15:07 -0800

>the payload in the next version.

I beg your pardon?  It appears that you have been participating in a very 
different discussion than I have.

The one I have been participating in had some vigorous proponents for using 
the sasl mechanism in beep, rather than expending the effort to create its 
integration with sacred.

In fact I seem to recall a presentation that argued for this re-use.

Please note that if the working group takes the very strong AD guidance to 
choose a single "transport" then there is no reason at all to create sasl 
integration into the application, unless the working group chooses a 
"transport" that does not already supply that functionality.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Dec 2001 16:12:08 +0000

Hi Dave,

Dave Crocker wrote:
> I beg your pardon?  

Granted:-)

> It appears that you have been participating in a very

Well, I don't think so. A week ago I posted [1], and only Marshall (and 
now you) seemed to differ from that. If others do, then I'd have hoped 
they'd have spoken up by now. (I'll also note that has been no comment 
at all on the draft minutes [2], which contain similar details of the 
strawpoll we held at the meeting.)

> the sasl mechanism in beep, rather than expending the effort to create its

Actually, most of the vigour has been related to http vs beep, from
my reading of the meeting and subsequent mail.

> In fact I seem to recall a presentation that argued for this re-use.

Yes (and I liked your presentaion btw). There was also another one 
(Magnus') calling for a quite different approach.

> "transport" that does not already supply that functionality.

I have some sympathy for this myself, but judging by the raised
hands, the consensus amongst those who'd implement sacred was to
include the sasl pdus in the payload.

Stephen.

[1] http://www.imc.org/ietf-sacred/mail-archive/msg00362.html
[2] http://www.imc.org/ietf-sacred/mail-archive/msg00363.html

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Dec 2001 08:36:12 -0800

At 04:12 PM 12/19/2001 +0000, Stephen Farrell wrote:
>they'd have spoken up by now.

Stephen,

The principle of having a chair declare a decision and wait for objections 
is well-established in the IETF.  However, to succeed, the use of the 
technique needs to have some basis in the recent history of the working 
group.

For example, it is not reasonable for a chair to literally ignore arguments 
they dislike and declare a decision that they DO like.

That you are both editor and chair, involving a matter of some controversy, 
is a point that needs to concern you a great deal.

As to the lack of response to your declaration, alternative explanations are:

1.  Post-IETF syndrome.

2.  Shock at the arbitrary (and frankly self-serving) declaration, 
resulting is a feeling that it is not worth commenting, since serious 
issues and serious points of view are going to be ignored by the chairs.

I'll also add that the reason I did not post anything earlier was that I 
sent my comments to the ADs, suggesting they fix the rather abherrent 
process that is clearly present in this working group.

>(Magnus') calling for a quite different approach.

You appear to be offering that as an excuse for literally ignoring the 
presentation you did not like.

>include the sasl pdus in the payload.

I commend to you some study in survey research methodology and statistical 
sampling an analysis.

d/

----------

---

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

> include the sasl pdus in the payload.

I think several people were assuming that there would need to be 
multiple substrates for sacred, and this was to some degree 
motivating the push toward putting sasl pdus in the payload.

I think that the assumption that there should be multiple substrates
needs to be a separate discussion topic, because IMHO this will both
degrade interoperability and make the sacred protocol more complex.

Keith

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Dec 2001 17:04:59 +0000

Dave,

Are you reading the text of the messages I send? Seems like
you're not. Well to make it clear, wrt sasl-in-beep, I said:

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

So far, we've two people unhappy, as far as I can tell. Feel
free to send references to other postings that contradict 
this. When & if there's a bunch (particularly if they're from 
people who're interested in what sacred's trying to achieve!)
we'll do the strawpoll on the list.

You seem to think that I support changing the protocol to 
include sasl in the payload and I get the impression that
you've also guessed that I'd prefer to use http. Its 
interesting that you got that so wrong! In fact, I'd be
quite happy with sasl-in-beep, but am following what I 
see as the consensus.

You also seem to think that polling just those who'd 
implement sacred isn't valid. Well, in the case of 
where the sasl pdus are placed, I disagree, but would
of course welcome arguments to the contrary.

Finally, I think the use of terms like "self-serving" is 
entirely inappropriate and unjustified. Luckily (for me),
I'm happy to ignore such verbiage, but in future, I'd 
appreciate it if you'd stick to technical argument.

Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Dec 2001 17:37:31 +0000

Keith,

> motivating the push toward putting sasl pdus in the payload.

Fair point (though it was at the end of a 30-40 minute discussion
where that specific issue was raised at least a few times). 

Any hand-raisers (or others, of course) care to comment/clarify? 

> degrade interoperability and make the sacred protocol more complex.

I tend to agree, though I think I'm less concerned with this for the 
credential server than I guess you are. I also don't think anyone's 
suggested that a sacred client would ever support more than one 
substrate.

So it seems that what's been suggested so far is along the lines of:

1) only define beep
2) only define http
3) define both in one rfc, client picks one, server MUST/SHOULD/MAY do 
   both (if not MUST do both, then one of beep or http has to be 
   mandatory-to-implement)
4) define both in one rfc, client and server pick what they like (yuk!)
5) first do 1) but then do 2) in a separate rfc, re-using as much as possible, 
   and making it as easy as possible for a single server to implement 
   both

Are there other combinations/substrates/ways-to-organise this that people 
would like to suggest before we get into the repsective (de-)merits of 
these? 

Stephen.

---

From: Dale Gustafson <[email-masked]>
Date: Wed, 19 Dec 2001 11:55:08 -0600

Stephen,

I agree wholeheartedly.

The SACRED group have invested a lot of time chasing a new strong-pw authentication
option (PDM) that was being pushed actively by it's proponents.  More recently it
has been suggested we should take on a much larger technical issue -- namely that
http is not suitable for the transfer of SACRED authentication protocols and
credential data.  I'd suggest there are oceans of empirical data that indicate this
conclusion is highly debateable.

Keith Moore, among others, has clearly articulated http-specific technical issues
that should be dealt with by those who would like to create a http-SACRED binding.

Others may want to create a BEEP-SACRED binding or a TCP-SACRED binding.

In "Blown to Bits", Evans and Wurster have said:

"However the shift in standards is not just from proprietary to open.  The Internet,
extranets, and intranets are all variants of the same thing.  They use a set of
lowest common denominator standards.  These trimph because of the principle of good
enough:  at some point in the advance of technology, generic standards become good
enough for their advantages in universal acceptance to outweigh their disadvantages
in any specific application."

I'd suggest "universal acceptance" is an important dynamic specifically with respect
to what SACRED is trying to do.
I also suggest that http, BEEP, TCP can all be made to work well for this very
simple task.

---

From: "David Chizmadia" <[email-masked]>
Date: Wed, 19 Dec 2001 13:11:57 -0500

Stephen,

> would like to suggest before we get into the repsective (de-)merits of

 6) in a distinct RFC, define the normative SACred
    PDU content and format, as well as a set of
    mandatory requirements for the substrate that
    carries those PDUs. Define additional RFCs for
    beep and http. Let other SDUs (like OMG) reuse
    the PDU RFC with our substrate (GIOP/IIOP).

> Stephen.

-DMC

---

From: "Marshall T. Rose" <[email-masked]>
Date: Wed, 19 Dec 2001 11:58:07 -0800

> Just to be clear - this doesn't at all address the http/beep issue.

err, wrong answer...

if you want to put sasl exchanges in the sacred pdus, that's fine. you just
can't use those pdus with beep because it's not how beep works.

the beep spec is very clear that there are two kinds of profiles: tuning and
exchange. tuning profiles do things like sasl and tls. they affect the
global state of the session because they deal with authentication and
privacy, both of which are per-session, not per-channel.

of course, it's perfectly fine to define a set of sacred pdus that don't do
sasl, and then to define a superset that includes some extra pdus that do
sasl. that way you can say that the sacred beep profile includes only the
core set.

however, the fundamental issue is whether we do multiple transports or one.

if the answer is one, which i think it has to be, then the issue is moot. if
the working group picks beep, then you don't need the extra pdus. if the
working group picks http, then you don't need a core set and a superset.

so, we again return to the "the http/beep issue". you can't make it go away
in the fashion you suggest.

/mtr

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Dec 2001 08:58:22 -0800

>quite happy with sasl-in-beep, but am following what I

1.      I should never sent strong notes before finishing my morning 
coffee, and would greatly appreciate everyone pretending that I had not 
made the egregious error of including personal content in my posting.

         Working groups CAN have a chair also be an editor of a working 
group document, but only when there is essentially no controversy in the 
work.  As a very strong rule, it appears to be essential that working 
groups doing anything with complexity and/or controversy separate the two 
functions into two (or more) different people.  It is essential that the 
chairs focus on constructive and timely process, and in these cases that 
requires not being affiliated with any side of a controversial topic.

2.      The IETF principle of rough consensus contains subtleties and 
complexities that we all often miss.  A working group can reach rough 
consensus that there will be world peace tomorrow.  It won't be turned into 
a standard.  A working group can reach rough consensus that a new 
application it is specifying requires that the Internet infrastructure be 
changed to provide consistent inter-packet spacing.  It won't be turned 
into a standard.

         The pure democracy of rough consensus has some balancing 
requirements and filters.  Rational choice is one of them.  There has been 
some pointed commentary, from ADs and others, about this working group's 
need to make choices that do not add unnecessary complexity and to be 
careful about a number of very serious problems with using HTTP.  Hence, if 
the working group decides to persist with the complexity in question and/or 
persist with a focus on using HTTP, it needs to respond to the specific 
technical concerns that have been raised.  So far, that response is missing.

>of course welcome arguments to the contrary.

In a sufficiently narrow context, polling them is just fine.  Using such a 
polling as the prima facie basis for making a major working group decision 
is in fact not valid, no.

There is nothing that has demonstrated that that very limited sample -- 
sacred programmers who happen to be in the wg meeting at the time of the 
polling -- is expert about Internet protocol DESIGN choices.  Of course 
they are important.  They are full participants in the process.  Giving 
them exclusive choice, however, is not valid, no.

A working group chair making a default choice, absent objections, is a 
valid mechanism, as long as the choice has sufficient basis.  The risk of 
making the default choice without sufficient basis is that it stifles 
actual participation, at a minimum due to frustration.

d/
----------

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Dec 2001 12:29:24 +0000

Ok - we've got 6 options. Magnus and I plan to run a strawpoll on these
six, starting jan 7th, running to Friday 11th. So if you've a 7th option, 
or comments on this list, please post to the list before the 7th.

Stephen.

---

From: Dale Gustafson <[email-masked]>
Date: Fri, 21 Dec 2001 13:44:11 -0600

Dear All,

I'd like to repudiate my last message to the list.

Was sent accidentally while attempting to do a "save-as-draft" (hurrying to leave for
lunch).  I did a quick reread later in the afternoon and thought (rationalized actually)
that it was ok as is, but upon rereading again today, realize that it is most
unsatisfactory as list material. My apologies.

Have a merry Christmas!

--dg

> I agree wholeheartedly.

[ ... ]