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

Hi David,

I think you're probably correct that we've moved somewhat away from
the idea of defining the abstract messages and then encapsulating 
them into one or more protoocls. IMO this is probably a sensible
change of approach given the lack of discussion about the framework 
document. (The framework draft then becomes more of a document
describing how we worked, rather than an abstraction.)

If folks aren't happy with this, or think that I've misrepresented
the situation (always possible given my limited brain:-), please
do speak up.

Regards,
Stephen.


David Chizmadia wrote:
> 
> { 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
> >

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