RE: SACRED Protocol (long!)

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 protected]]
> Sent: Monday, December 10, 2001 6:17 PM
> To: Nystrom, Magnus; 'Dave Crocker'; Linn, John
> Cc: [email protected]; Marshall T. Rose
> Subject: Re: SACRED Protocol (long!)
> 
> 
>    From: "Linn, John" <[email protected]>
>    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
>