Subject: Re: I-D ACTION:draft-ietf-cat-sasl-gssapi-05.txt

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 12 Jun 2001 11:08:19 -0500

Cat-ietf'ers,
We have a GSSAPI implementation called GSI, which we are adding under SASL. We are
at the point where we are looking at the choice of a SASL mechanisum name. 
So our discussion fits right in with the discusion on the  cat-ietf list. 
I would call your attention to the last few paragraph for comments.

Mei-Hui Su wrote:
> 
> In openldap, it gets a list of modules to be loaded from the conf file and
> then load them all in during startup,
> 
> In Sasl,  When they got started, it checks with all the possible plugin
> shared libraries in the specified plugin-dir and tries to dlopen them one
> by one and there is an internal table associate with each plugin
> library.

So it is extensible, by the fact that there is a library in the directory?

> That table contains what to call during handshaking etc. and then
> the server/client keep tracks of 'valid' mechanism name if the plugin was
> successfully dlopened and saves a link to it.

So it sounds like a plugin can return multiple mechanisum names? 

> And when a request comes for a
> 'particular' mechanism, server/client would base on the name and follow the
> link to the right plugin code. So the changes I did was to force another
> mechanism name into gssapi's plugin's shared libraries. It looks like they
> thought about multiple mechanism name associates with a mechanism type but
> there is no easy way to add it but to hacking new one in to the source.

Did you only have to change the plugin? 

> But
> like you said, the problem still exists when there really should be multiple
> plugin libraries for different favors of GSSAPI because the 'libgssapiv2.la'
> that brings in dependency would differ for krb5 and GSI ones.

Yes and no. Since GSS API is designed to allow multiple mechanisms to be
accessed via the single API, there could be a single gssapi plugin, which
loaded all the available gssapi libs, then returned their SASL names. 
The mechglue code from Sun, and distributed with the MIT Kerberos code
for example could be used in the SASL gssapi plugin. 

The problem is that SASL is trying to negotiate a mechanism name,
but GSSAPI uses mechanism OIDs. And one plugin or GSS lib can have multiple
mechanisms. So the use of the GSI-base32name may not be as bad as it looks,
if the plugin can generate the name from the mechanism OIDs on the fly and 
return the list to the SASL library. In this way the client and server will 
both have a a list of names which maps to all the possible GSSAPI mechanism 
OIDs they support. So the reverse mapping from SASL mechanism name to OID is 
not needed, and the SASL mechanism name does not need to be readable.

If all this holds true for other implementations of SASL, then the  
draft is not as objectionable as I had first thought. 

> mei

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 18 Jun 2001 14:48:50 -0700

"Douglas E. Engert" wrote:
> Since GSS API is designed to allow multiple mechanisms to be
> [...] if the plugin can generate the name from the mechanism OIDs on the fly and

The draft was designed to permit this type of implementation. 
Specifically, it took the constraint that it should be possible for SASL
implementations to be written against the GSS API, exposing GSS
mechanisms without needing any information about those mechanisms other
than can be obtained through the GSS API.