Subject: Re: sacred again

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Oct 2001 16:45:03 +0100

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-masked]
Ireland                             http://www.baltimore.com

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 19 Oct 2001 09:28:15 -0700 (PDT)

> is the SRP-derived key used to do that?

RFC 2222 (SASL) specifies a framework for mechanisms to negotiate the use
of a security layer that provides mechanism-defined protections.  This is
used in production with, eg GSSAPI/Kerberos5 to provide integrity and
confidentiality protection for application protocols such as LDAP and
SMTP.

draft-burdis-cat-srp-sasl-04, in section 5, specifies the security layer
for SRP (the SRP family) as a SASL mechanism.  This layer provides
confidentiality, replay protection, and integrity protection.  The keys
and mechanisms used are those established by the SRP exchange.  I won't
vouch for the correctness of this spec, and I don't know about
implementations of it, but it seems to me to cover the territory you're
asking about.  Doesn't it to you?

This draft is unfortunately expired, I can provide it to this list if
necessary.  I believe the finalizing of this work is intended to be a work
item of the almost-but-not-quite-approved SASL WG (where the WG-creation
delay is, as far as I know, entirely IESG overload, not any WG-related
issue).

> key to protect traffic where the SASL mech derives a suitable key?)

BEEP can use any SASL mechanism, and can use the mechanism-provided
security layer with any protections provided by that layer.  So BEEP does
everything needed here.

> layering approach I guess).

This would be entirely unnecessary, confusing, and counter-productive,
IMHO.

 - RL "Bob"

---

From: Lawrence Greenfield <[email-masked]>
Date: Fri, 19 Oct 2001 13:02:04 -0400

Many SASL mechanisms support security layers.

This is covered in RFC 2222.

If the SRP mechanism doesn't define a security layer, it should be
fixed.  SACRED has no business defining its own security layer.

SASL security layers work today; they're supported by IMAP, SMTP, and
LDAP servers.  (Some of the SASL mechanisms with security layers are
GSSAPI and DIGEST-MD5.)

Larry

   Date: Fri, 19 Oct 2001 16:45:03 +0100
   From: Stephen Farrell <[email-masked]>

   Radia, All,

   Radia Perlman - Boston Center for Networking wrote:
   [...]

   Stephen.

---

From: "David Chizmadia" <[email-masked]>
Date: Fri, 19 Oct 2001 14:04:12 -0400

{ 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-masked]>
To: "David Chizmadia" <[email-masked]>
Cc: "xme" <[email-masked]>
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-masked]>
> > To: "Radia Perlman - Boston Center for Networking"
<[email-masked]>
> > Cc: <[email-masked]>; <[email-masked]>;
> > <[email-masked]>; <[email-masked]>; "ietf-sacred"
> > <[email-masked]>
> > Sent: Friday, October 19, 2001 11:45 AM
> > Subject: Re: sacred again
> >
> > >
> > >
> > > Radia, All,
> > >

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 22 Oct 2001 10:55:41 +0100

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.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 22 Oct 2001 11:00:29 +0100

Lawrence,

Now that I've found the expired SASL SRP draft (I found it at 
http://www.forge.com.au/products/Papers/Secure_Remote_Password.htm),
and re-read rfc2222, I tend to agree with you and Bob. The sasl-srp
draft does include a security layer.

So - in the (probably likely;-) absence of further inputs, I'll try
to draft up a protocol with beep+sasl+sasl-srp+sacred-messages-in-xml
and we can then see whether it meets the requirements in rfc3157.

Regards,
Stephen.

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Mon, 22 Oct 2001 03:51:29 -0700 (PDT)

> draft does include a security layer.

Glad to hear it.

> So - in the (probably likely;-) absence of further inputs, I'll try to
> draft up a protocol with beep+sasl+sasl-srp+sacred-messages-in-xml and
> we can then see whether it meets the requirements in rfc3157.

I would think of this in two parts:

 * how to carry SACRED messages in BEEP

 * a "profile" of the SASL-SRP mechanism with enough defined to make
   interoperability likely for SACRED purposes

 - RL "Bob"