What, exactly, is the "SACred protocol"? (was Re: sacred again)

{ Continuation of an exchange I started offline because I wasn't sure it
pertained to the immediate question: which it doesn't, but I still have the
question }

Stephen,

    From a CORBA standpoint, I'm not too worried about the exchange of
messages, since I can do that in CORBA as well (especially if the exchange
pattern is request/response). My concern is that the protocol development
appears to be drifting away from defining the abstract exchange of messages
first, followed by binding to specific application protocols. Instead, the
definition of the message exchanges appears to be tightly bound to the SASL
"application protocol". This makes it more difficult for me to create an
alternate binding in terms of CORBA IDL.

    I'm just trying to figure out if I'm missing something or whether this
is indeed where the SACred specifications are going - intentionally.

-DMC

----- Original Message -----
From: "Stephen Farrell" <[email protected]>
To: "David Chizmadia" <[email protected]>
Cc: "xme" <[email protected]>
Sent: Friday, October 19, 2001 1:39 PM
Subject: Re: sacred again


>
> Hi David,
>
> Do raise this on the list - though it is a slightly different
> issue.
>
> I'd guess that SASL itself doesn't tie you to connection-oriented
> applications, but probably SRP does (there's a bunch of messages
> to be exchanged unlike with PDM).
>
> Even so, I'd have thought it would still be possible to forward
> the sasl packets via a beep/iiop gateway (if such a thing existed
> I suppose:-) without loss of security.
>
> If the applications you care about call for fewer exchanges then
> that's a valid reason to criticize SRP. However, given that SRP is
> being incorporated into a bunch of IETF protocols and that it seems
> to meet the hard security problems sacred's tackling (in an apparently
> IPR-clean way too), picking something else might be hard.
>
> Again, I'd encourage you to raise this on the list - I don't think
> anyone has been overloaded reading it lately:-)
>
> Stephen.
>
> David Chizmadia wrote:
> >
> > Stephen,
> >
> >     My apologies for taking this offline if it belongs on the SACred
list,
> > but I'm sufficiently confused that I can't tell - and and don't like
sending
> > spam any more than receiving it! :-)
> >
> >     I've been trying to follow SACred since this past spring. I was
quite
> > excited because it seemed to be offering a useful service - a
> > transport-independent approach by which a server could allow users to
> > centrally store and manage their cryptographic credentials without
having
> > any visibility into those credentials. I come from a CORBA security
> > background and my interest is in developing a CORBA service that would
> > provide the SACred service through a CORBA IDL interface. I see 2 CORBA
use
> > cases:
> >     1. A client bootstrapping mutual authentication by using unprotected
> > IIOP (the CORBA wireline protocol) to retrieve their private PK key and
then
> > installing that key into SSL to allow future secure invocations via
Common
> > Secure Interoperability Version 2 (CSIv2), which would use SSLIOP with
> > mutual authentication between client and server.
> >     2. A client that wishes to protect pub/sub messages using SACred
over
> > IIOP to retrieve the key(s) that they would use for encryption and/or
> > signature of their messages.
> >
> >     My concern is that the SACred protocol that is being defined is
drifting
> > away from the goal (that I originally understood it to have) of being
> > independent of the specific application for which the credentials would
be
> > used. If I interpret radia's comments correctly, they imply that SACred
> > would only apply to connection-oriented applications that use SASL. This
> > seems to eliminate its potential use for any other data protection or
> > electronic signature applications - such as secure email and online
document
> > signature.
> >
> >     Am I misunderstanding what's happening, or is this what you were
asking
> > for opinions on?
> >
> > -DMC
> >
> > ----- Original Message -----
> > From: "Stephen Farrell" <[email protected]>
> > To: "Radia Perlman - Boston Center for Networking"
<[email protected]>
> > Cc: <[email protected]>; <[email protected]>;
> > <[email protected]>; <[email protected]>; "ietf-sacred"
> > <[email protected]>
> > Sent: Friday, October 19, 2001 11:45 AM
> > Subject: Re: sacred again
> >
> > >
> > >
> > > Radia, All,
> > >
> > > I've started drafting the SRP protocol stuff & am including SRP in
> > > the sacred payload, (as opposed to using the SASL SRP mechanism),
> > > similar to how PDM was handled in the previous draft. Radia raises a
> > > point where I'd like some feedback from the list (actually, I'd like
> > > feedback from the list about *anything* at all:-)
> > >
> > > Radia Perlman - Boston Center for Networking wrote:
> > > >
> > > [...]
> > > > I thought that it could be done without
> > > > any work on Sacred's part by just saying "use any SASL mechanism",
> > > > and the most work I thought sacred would have to do is to say that
> > > > the one mandatory SASL mechanism was RFC mumble (which would be
SRP).
> > > > Though maybe SASL-SRP is still just an internet draft, but that
> > > > wouldn't make any difference.
> > > >
> > > > Radia
> > >
> > > You mean that SASL-SRP does mutual auth and key derivation and that
> > > (SRP derived) key is then used to encrypt & integrity-protect all
> > > subsequent BEEP traffic. That'd be nice all right, problem is how
> > > is the SRP-derived key used to do that?
> > >
> > > Be great if BEEP itself took care of this, but AFAIK it doesn't
> > > (Marshall - would that be a general BEEP thing, using a SASL derived
> > > key to protect traffic where the SASL mech derives a suitable key?)
> > >
> > > So, if I'm right, that'd mean that we'd have to define our own payload
> > > encryption and MACing, where needed. It seemed to me that at this
> > > stage we're not getting much from the use of SASL and so I included
> > > the SRP stage in the payload from the start (arguably better from a
> > > layering approach I guess).
> > >
> > > Hence the drift of the current (proto-)draft.
> > >
> > > Stephen.
> > >
> > >
> > >
> > > --
> > > ____________________________________________________________
> > > Stephen Farrell
> > > Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> > > 39 Parkgate Street,                     fax: +353 1 881 7000
> > > Dublin 8.                mailto:[email protected]
> > > Ireland                             http://www.baltimore.com
> > >
>
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.                mailto:[email protected]
> Ireland                             http://www.baltimore.com
>