[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: SASL, TLS and SSLv3
> 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