Re: SASL/EXTERNAL and CLDAP

["Booker C. Bense" <bbense@networking.stanford.edu>]

On Mon, 5 Jun 2000, Bruce Greenblatt wrote:

> At 11:05 AM 06/05/2000 -0700, Kurt D. Zeilenga wrote:
> >At 12:32 PM 6/5/00 -0500, Mark Wahl wrote:
> > >I would prefer that the SASL EXTERNAL mechanism be used to pick up the
> > >IPSEC credentials to the LDAP level, rather than a new protocol field.
> >
> >I agree that SASL/EXTERNAL can and should be used to pick lower
> >level credentials associated with connection.  Those credentials
> >can be provided by TLS, IPSEC, or other lower layer associated
> >with the connection.
> >
> >However, SASL (including SASL/EXTERNAL) cannot be used with
> >connectionless protocols, you must have a connection to use
> >SASL.  CLDAP should not overload/redefine any existing
> >authentication choice nor any specification of those choices.
> 
> 
> Why couldn't I write a draft titled "Using SASL/EXTERNAL mechanism in 
> connectionless protocols"?  As I read RFC 2222, it only says that it 
> defines how to use SASL over connection oriented protocols.  It doesn't 
> appear to say that there is no way to ever use SASL/EXTERNAL within UDP.
> 
> Bruce

- There are two essential "features" to SASL. The first is a means of
choosing authentication and the second is strictly defining what you
have to do successfully authenticate using that method. Both are
heavily dependent on the underlying notion of a "session" to provide
their security. While it might be possible to design a secure
"application profile" for a connectionless protocol, I can't see how
you could do without essentially duplicating the TCP stack. There are
just far too many assumptions inherent in SASL to just blindly 
apply the methods and assume you have done an adequate job of 
security.

- I certainly believe it is possible to have an authenticated
UDP based protocol, but I think you'd be much better off designing
it from scratch rather than attempting to jam one and only one
SASL method into it. 

- While I can certainly see the advantages of CLDAP, I think that
there needs to be a clearly defined scope of what you can and can't
do via the protocol. The application need as I see it is for searching
on at most a few fields and returning a brief answer. There is also
a need for authentication of some sort to allow access control. 
Data integrity and privacy would be useful, but will be very
complicated to implement. ( How do you build "session keys" in the
absence of a session?) The only model I know of that solves these
problems is the tgt service of kerberos, it does it by very strictly
limiting the kinds of requests you can make and the resulting answers
you will get. 
 
- Any attempt to duplicate the full range of ldap will essentially
require reimplementing TCP. A pointless exercise at best. 

- Booker c. Bense