Re: SASL, TLS and SSLv3

[patl@phoenix.volant.org]

> On  2 Dec, Jon Parry-McCulloch wrote:
> > 
> > 
> >      Quote from rfc2222 (Simple Authentication and Security Layer):
> > 
> >       During the authentication protocol exchange, the mechanism
> > performs
> >         authentication, transmits an authorization identity
> > (frequently known
> >         as a userid) from the client to server, and negotiates the
> > use of a
> >         mechanism-specific security layer.  If the use of a security
> > layer is
> >         agreed upon, then the mechanism must also define or negotiate
> > the
> >         maximum cipher-text buffer size that each side is able to
> > receive.
> > 
> >      This is still not encryption per se. It is merely negotiating a
> > protocol for the client and server to use between them.
> > 
> >      Jon
> Yep, but SASL compliance would require support for encryption in libs
> and servers and thus make the openldap source a weapon.

It's been a while since I read the RFC; but I don't recall it
specifying that encryption support is manditory.  So it should
be possible to add the basic SASL support, and even support
for certificate-based authentication, without causing ITAR
problems.

Of course, any properly designed implementation would make it
easy to add additional authentication mechanisms at build-time.
And it should support the possibility of re-negotiating the
connection.  But that re-netotiation API should be abstracted
and generalized so that it is not crypto-specific; or even
security-specific.  (E.g., An example extension could be written
which would provide data/protocol compression.)



-Pat