Subject: Re: Java GSS bindings

From: Michael Smith <[email-masked]>
Date: Sun, 06 Dec 1998 23:01:24 -0500

At 05:42 PM 12/6/98 -0800, Mayank Upadhyay <[email-masked]> wrote:

>My opinion is that the GSS-API bindings should consist of concrete 
>classes.
>
>I look at the GSS-API layer in the following way: An implementation of 
>the GSS-API is a framework provided by one vendor which can allow 
>different security mechanisms from one or more vendors to plug in 
>underneath it.

This is certainly one approach. But it seems to me that if we go this 
route, then it becomes necessary for somebody to define a "provider"
API by which mechanisms (at run-time, presumably) could register themselves
with the "middle layer". It seems to me that this just pushes the same 
problems off to another level. In particular, Mayank writes:

>My understanding is that you would want to use an interface or an 
>abstract class in a Java API when you are expecting to get a concrete
>implementation of it from elsewhere at run-time, which plugs-in 
>underneath, somehow.

Somehow: exactly. That still has to happen, and the "provider API" 
would have to spell out how. 

This seems duplicative to me. -- Although I seem to recall that there
has been some discussion in cat-wg of some such approach at the abstract
level: i.e. GSS as a kind of "broker" API, and dynamically 
registered mechanisms (presumably using a provider API) underneath
them. As far as I know, however, this hasn't really come to much 
yet. I don't think the language-binding level is the place to introduce
it. 

This is, of course, just my view. Jack Kabat, who wrote the Internet-
Draft currently before the WG, takes an approach similar to the 
one Mayank suggests. He avoids the problem of the "provider API" by 
simply mandating that the application programmer know the right 
classes to "include" -- at the source code level -- these being
classes that duplicate the repertoire of methods defined in his 
concrete classes. Alternatively, of course, one could simply write 
one's own classes and give them the same names as those defined 
in the binding spec, then make sure that these classes were made
to be on the CLASSPATH at run time -- "somehow." This seems to me 
like Impersonating An Officer; but perhaps this is excessively 
prudish. -- Nobody wants to be more Catholic than the Pope, and 
after all here I am debating with a guy from Sun. 

For what it's worth, my own thinking was that the GSS-API would be 
defined as a set of interfaces, one of which would be such that its
implementations would define a sort of "master class." Get an instance 
of this, and instances of all the other classes implementing the various 
interfaces of the GSS-API would be obtainable, directly or indirectly,
from the "master class" instance. The "master class" instance, or even just 
its name, or Class object, or whatever, would be obtainable at run time
as.... what? a system property? There's more than one way to skin this 
cat. Or CAT.   

--Michael Smith
  [email-masked]

==========================================================================
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: "michael.eisler" <[email-masked]>
Date: Sun, 6 Dec 1998 22:13:32 -0800 (PST)

> problems off to another level. In particular, Mayank writes:

This is true. On the other hand, it is direction the WG took with
the C-bindings for GSS-API: define the top level veneer, leave the
interface from the veneer to the provider as an exercise for the
implementor. 

How far down the API road should a *protocol* standards group go?

> yet. I don't think the language-binding level is the place to introduce

It hasn't come to much with the WG, but at least one GSS-API implementation
uses dynamically registered plug ins. Lack of a mandated provider API
is thus not a barrier to modularity.

> after all here I am debating with a guy from Sun. 

Not sure what is meant by this last phrase.

	-mre

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Wed, 09 Dec 1998 10:53:15 -0500

[Not speaking ex-cathedra as Security co-AD]

My preference would be for interfaces and providers. I believe it isn't a good idea
to depend on CLASSPATHs having a certain structure at run time.. Remember, at run
time you are dealing with end-users, who may not have much clue! By using a class
registration mechanism you ensure that if things are going to fail, they fail in a
well understood fashion (Class not found, or "No suitable driver") rather then
potentially instantiating a different GSSAPI mechanism then that which would
intended.

It isn't that hard to use Interfaces.

                -Jeff

---

From: "Jack Kabat" <[email-masked]>
Date: Wed, 9 Dec 1998 17:42:48 -0800

When I wrote the JGSS draft it was to implement the features of RFC 2078.
Looking at an existing specification for implementing RFC 2078 in C, I see a
single interface to a set of security services. Neither the C version nor
RFC 2078 define interfaces for implementing yet another level of API which
would be used to plug in mechanisms under the GSS-API.  It does not
constrain one from doing so, as I know of at least one implementation that
has done so, but leaves this issue up the implementor.

I don't think that the GSS-API distinguishes between the mechanism and GSS
layers from the API perspective. If I want to switch to a different vendor's
implementation of C GSS-API I need to either link with their library, or
replace my GSS-API with theirs. This would be equivalent to using the
CLASSPATH to manipulate which class libraries get used.

Now, lets assume that we do provide a set of interfaces instead of concrete
classes. But then are we really eliminating the need for proper classpaths?
The interfaces will still need to know how to instantiate the classes
implementing them. So what is the difference between *registering* a class
with the GSS layer and instantiating the *registered* class?

One advantage I see of using interfaces is what Michael Smith points out -
and that is to have an existing class implement JGSS functionality, thus
more flexibility for the JGSS developer.

Regards,

Jack Kabat

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Michael Smith
> Sent: Sunday, December 06, 1998 8:01 PM
> To: Mayank Upadhyay
> Cc: [email-masked]
> Subject: Re: Java GSS bindings
>
>