Re: SACRED Protocol (long!)

Hi Marshall,

On Tue, 11 Dec 2001, Marshall Rose wrote:

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

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

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

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