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

[Magnus Nystrom <magnus@xxxxxxxxxxxxxxx>]

Stephen, All,

Well, the arguments given by Bob Morgan and L Greenfield were my
original reason for suggesting SASL (e.g. posted to the list on July,
2nd), and, since I argued for the SASL switch earlier, I can't really
argue against at now, however, and it certainly makes the SACRED work
simpler.

Yet, as David's email points out, relying on SASL creates a
dependency on the underlying transport (and its capabilities). Which
may or may not be good. How about defining use of SASL within the
SACRED protocol then? After this, any transport could potentially be
used. Don't know if it is a good suggestion, but perhaps worthwhile to
discuss.

-- Magnus

> > On Mon, 22 Oct 2001, Stephen Farrell wrote:
> >
> > > 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" <stephen.farrell@xxxxxxxxxxxx>
> > > > To: "David Chizmadia" <dchizmadia@xxxxxxxxxx>
> > > > Cc: "xme" <stephen.farrell@xxxxxxxxxxxx>
> > > > 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" <stephen.farrell@xxxxxxxxxxxx>
> > > > > > To: "Radia Perlman - Boston Center for Networking"
> > > > <Radia.Perlman@xxxxxxx>
> > > > > > Cc: <mrose@xxxxxxxxxxxxxxxx>; <Radia.Perlman@xxxxxxxxxxxx>;
> > > > > > <ckaufman@xxxxxxxx>; <magnus@xxxxxxxxxxxxxxx>; "ietf-sacred"
> > > > > > <ietf-sacred@xxxxxxx>
> > > > > > 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.