Subject: RE: SACRED Protocol (long!)

From: "Linn, John" <[email-masked]>
Date: Tue, 11 Dec 2001 08:18:58 -0500

Just to clarify, I wasn't disputing the value of representing SRP as a SASL
and/or GSS mechanism.  Either of these alternatives would help to simplify
integration of SRP with applications wishing to use it, and could avoid
unnecessary duplication of SRP code.  Rather, my thought was that the set of
candidate mechanisms that has characteristics suitable for use by SACRED is
small and specialized (primarily, SRP and a few others based on the
cryptographic "password amplifier" protocol families). Many other mechanisms
are inapplicable for use by SACRED because they're unable to operate until
SACRED has completed its operations and thereby made credentials available.
SACRED use of SASL or GSS could ease portability of SACRED between SRP and
other mechanisms that don't need pre-existing credentials, which seems like
a good goal, but wouldn't make SACRED portable to mechanisms outside that
category.

--jl

> -----Original Message-----
> From: Lawrence Greenfield [mailto:[email-masked]]
> Sent: Monday, December 10, 2001 6:17 PM
> To: Nystrom, Magnus; 'Dave Crocker'; Linn, John
> Cc: [email-masked]; Marshall T. Rose
> Subject: Re: SACRED Protocol (long!)
> 
> 
>    From: "Linn, John" <[email-masked]>
>    Date: Mon, 10 Dec 2001 11:37:41 -0500
> 
>    I'd like to observe a point that hasn't been too visible 
> in this discussion,
>    but which seems significant. Relative to most 
> applications, SACRED is quite
>    a special case. As far as security (its reason for 
> existence) is concerned,
>    SACRED is a bootstrap protocol; by necessity, many of the 
> prerequisites that
>    many underlying security mechanism candidates need in 
> order to provide
>    protection won't be in place until after the SACRED 
> exchange is completed.
>    To protect the SACRED exchange itself, only a restricted 
> set of mechanisms
>    can be applicable; SACRED's requirements are sufficiently 
> special that the
>    mechanisms it needs and uses may not be used for any other 
> purposes.  As
>    such, there'll be limited independence in practice between 
> the SACRED
>    application and its underlying mechanism.  
> 
> I disagree.  The current SACRED draft makes use of SRP.  SRP is an
> interesting SASL mechanism that might be used by other applications,
> and defining it as a SASL mechanism or GSS mechanism will prevent
> people from redefining it and allow reuse of code.
> 
> Further, having SACRED leverage SASL allows individual sites to decide
> on exact security policies (if a new great SASL mechanism comes out,
> the protocol doesn't need to be changed for a site to make use of it).
> 
> Larry
>

---

From: "David Chizmadia" <[email-masked]>
Date: Tue, 11 Dec 2001 09:16:48 -0500

> a good goal, but wouldn't make SACRED portable to mechanisms outside that

I'm normally a lurker because crypto-protocols aren't my forte, but as a
user of an alternate transport (CORBA -> GIOP -> IIOP), I'm following SACred
because I'm interested in eventually using SACred to bootstrap the SSL that
is used in most ORBs. I was actaully glad to see Magnus' proposal, since it
fits well with current CORBA wrappers of GSSAPI. But reading the continuing
discussion, I suspect that it would be most effective if the operational
problems of SACred are worked out in the context of BEEP. Masochists like
myself can then use that specification to develop the state and interaction
models that are at the core of the protocol and map them to CORBA IDL
interfaces.

From a CORBA perspective, treating SACred as a GSSAPI or SASL mechanism
would be optimal, since CORBA already has ways to access those interfaces
and is consistent with my understanding of SACred's nature, which is
essentially as the first authentication mechanism that would be used by
roaming users or devices that will then use the credentials retrieved with
SACred to perform the "real" authentication to various systems.

-DMC
David Chizmadia
Senior Software Security Architect
Promia, Inc
[email-masked]