Re: protocol progress...

Stephen,


Stephen Farrell wrote:

> Hi Tom,
>
> Sorry for the slow response.
>
> Tom Wu wrote:
> >
> > Stephen,
> >
> > If uncertainty about the SASL-SRP draft is an issue, why not go with
> > SRP/TLS, or some other strong password solution?
>
> What's the status of the SRP/TLS work?
>
> > Item 2 requires a
> > weakening in the previously agreed-to security requirements, which seems
> > like a Bad Thing.
>
> I'm not sure that a zero-knowledge requirement was inclcuded, but in any
> case I guess we have to either make progress or wait until whatever issues
> bedevil SRP-SASL get solved.

I think the requirement has centered on:

1) mutual authentication (in most cases), and
2) negotiate or derive a session key known only to credential server and
roaming client.

Strong-pw is a very good way to do that.  Don't think we can afford to give
ground on the requirements -- they seem pretty basic for credential exchange.

Other alternatives are:

 - TLS with any other SASL mechanism(s) that provide both 1) and 2).
 - SRP/TLS
 - sTLS with a client password :-(
 - other?

Best Regards,

Dale Gustafson



>
>
> Stephen.
>
> >
> > Tom
> >
> > Stephen Farrell wrote:
> > >
> > > Hi all,
> > >
> > > Well, from reports of the sacred meeting it seems that though
> > > we've managed to bottom out all the previously known issues with
> > > the current draft, we still need to make some more changes to
> > > remove the dependence on SASL-SRP, given the uncertain future
> > > progress of that draft.
> > >
> > > So if we want to progress the sacred protocol, we need to agree
> > > on some approach that doesn't suffer the same uncertainty.
> > >
> > > Here's what appears to be a possible plan:-
> > >
> > > 1. remove srp dependencies from protocol document
> > > 2. make beep over tls mandatory to implement and pick
> > >    a "traditional" password based sasl scheme (hopefully
> > >    with salt, iteration and digest - suggestions on a
> > >    postcard please!)
> > > 3. add/change security considerations to the effect that
> > >    credential servers supporting the "must implement"
> > >    option do get to see a value that allows them to
> > >    mount a dictionary attack
> > >
> > > As long as item 2 isn't controversial, this shouldn't take
> > > very long.
> > >
> > > What do we all think of doing this?
> > >
> > > Sigh,
> > > Stephen.
> > >
> > > PS: I don't see much point in issuing a new protocol draft until
> > > we sort this one out, let me know if you disagree with that.
> > >
> > >
> > >
> >
> > --
> > Tom Wu
> > Principal Software Engineer
> > Arcot Systems
> > (408) 969-6124
> > "The Borg?  Sounds Swedish..."
>
> --
> ____________________________________________________________
> 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