Subject: Re: SACRED Protocol (long!)

From: Marshall Rose <[email-masked]>
Date: Tue, 11 Dec 2001 03:30 -0000

>Honestly, I don't think that work will be too onerous. C.f. with 
other
   >security-related protocols that runs over http.
 
hi. i think we live in different realities because i can't think of 
any "security-related protocols that runs over http" that were done in 
the ietf or signed-off by the iesg. in my reality, anything involving 
any  "protocol that runs over http" gets to run the brickbat gauntlet 
in the ietf/iesg. and speaking from experience, it's not fun...

   >As I mentioned in an earlier posting, the concern we had about the
   >current draft stemmed from two facts:
   >
   >-it binds SACRED tightly to BEEP; and
   >-there are widely implemented protocols that do not support SASL 
(or
   > other security frameworks), and platforms that SACRED is expected 
to
   > serve support these protocols and not BEEP.

in terms of the 1st requirement, i think dave addressed "the usual 
issues".

i just have to question the wisdom of the 2nd requirement 
because...see my next response...

   >We therefore felt that making SACRED payloads security-aware would
   >alleviate these concerns. And yes, at least one mapping to some
   >existing transport is needed, and given the latter factor above I
   >suggest that the initial mapping shall be to SOAP.

with enough thrust even a truck can achieve orbit, but you have to ask 
if it's worth it by tossing sasl (and to much a lesser extent beep) 
and re-inventing them. in the ietf, i think it's a hard sell. sure, 
it's not as hard a sell as also re-inventing tcp, but there's a big 
cost... 

to make matters worse, it turns out that the ietf's confusion as to 
whether soap is a format or a protocol introduces a huge amount of 
uncertainty as to how high the bar will be for making  sacred/soap 
payloads  security-aware...

/mtr

---

From: Magnus Nystrom <[email-masked]>
Date: Tue, 11 Dec 2001 08:20:48 -0700 (Mountain Standard Time)

Hi Marshall,

> in the ietf/iesg. and speaking from experience, it's not fun...

CMP, OCSP, CMC, S/MIME,...

> it's not as hard a sell as also re-inventing tcp, but there's a big

Once again, we are not tossing SASL, nor are we re-inventing SASL. We
are integrating support for SASL into SACRED payloads. We do this by
means of one new request/response pair - BindRequest and BindResponse.
Same way as SASL integration was done in, e.g., LDAPv3.

-- Magnus