Subject: Re: Proposed changes to draft-ietf-cat-gssv2-javabind-01.t (fwd)

From: Mayank Upadhyay <[email-masked]>
Date: Fri, 28 May 1999 17:07:16 -0700 (PDT)

Thanks to Joe for his feedback on the proposed changes. I like the
distinction he has drawn between a "system wide provider" and a "stand
alone provider". My comments are embedded below. 

On Wed, 26 May 1999 [email-masked] wrote:

> First, I prefer the IGSS* naming convention over GSS*Int.  It seems 
> more standard, but then I may have lived in C++ (and Microsoft) land 
> far too long. 

Either approach is fine with me. We can change it to IGSS* and also CGSS*
as Dave Arnold suggested in his mail. Therefore, there would be an
IGSSName and a CGSSName, an IGSSCredential and a CGSSCredential, and so
forth. 

> I'm worried that we cannot meet both the applet and applications needs 
> with one method of instantiating classes. We need to draw a line 
> between "stand alone" GSSAPI implementations and "system" GSSAPI 
> implementations.  I use "stand alone" to refer to a GSSAPI provider 
> that provides a complete implementation for a mechanism(s) based on 
> the interfaces provided (typically done within an applet).  A "system" 
> provider sits under a system wide GSSAPI implementation that provides 
> access to multiple mechanisms (typically within in application or 
> server).   Currently the GSSManager concrete class instantiates both 
> types.  I am against this for the following reasons.
> 
> -  An applet may not be able to set the necessary system provider 
> properties. 

True, unless the client side explicitly gives your applet permission to
install providers. I'm just curious about whether most applets that need
the GSS-API will be able to do anything useful in the Java sandbox when
the client machine does not explicitly grant them any permissions. 

> -  It requires the applet to have access to a common implementation of 
> GSSManager.

If there is no common implementation, the implementation of
org.ietf.gss.GSSManager that is shipping with the applet will get used. If
GSS-API becomes a standard (Java) system package then there will be a
common implementation on the system.

> -  It encourages mixing of objects between providers.  Having a 
> GSSManager class that instantiates multiple providers suggests that 
> one might be aware of another.

If we want to have a model where a system wide GSS-API allows any
arbitrary mechanism specific GSS-API to plug in at the lower layers, then
there will be mixing of objects between providers. I don't see a problem
with that so long as the classes in the framework access the other classes
through the public API's only. It would be an implementation choice to
make your classes aware of other providers and use them in ways not
specified by the API; however, as far as provider management goes, all
provider management is usually done for you by the java.security.Security
class.

> -  It adds more weight to the applet code.

True. The wrapper classes and in fact the GSSManager can be avoided by
applets with the loss of some convenience and flexibilty.

> -  A provider management API is currently not specified for GSSAPI.

True again. However, there are somethings that are left to the language
level to work out. The java language comes with its own provider
management API in the form of the java.security.Provider and
java.security.Security classes. We would just be leveraging that.

> I propose that the applet writer must know the name of the GSSFactory 
> class and instantiate it directly for an "stand alone" provider.

I'm ok with this change. It will mean that the applet code will look like:

	import my_package.MyGSSFactory;

	GSSFactory factory = MyGSSFactory();
	IGSSCredential cred = factory.getCredential(...);

There are two drawback I see that applet developers on this alias will
have to decide if they can live with: 

(a) As an applet developer, only code I write will use MyGSSFactory(). 
There is no single point control where I can specify that all GSS calls
that occur in my applet (including in classes not written by me) use
MyGSSFactory. 

(b) Some loss of portability unless I pass in the name of the factory
implementation as a the string to the applet and then use that in a
Class.forName().newInstance(). 

> The "system" and "stand alone" methods differ in how classes are 
> instantiated and where the GSSManager functionality lies. Reorganizing 
> the document would help separate the details of implementation from 
> the GSSAPI interfaces.
> 
> Separate the document into two sections. The first defines the set of 
> interfaces and common classes adding an IGSSManager interface (or, if 
> you like GSSManagerInt  see sample code at the end).    The second 
> specifies two implementation models, the "stand alone" model oriented 
> towards applets and the "system" model oriented towards applications.  
> 
> Stand Alone Model
> -----------------
> In the stand alone model the  implementation provider provides a class 
> that implements GSSFactory and IGSSManager.  The application must know 

The stand alone provider doesn't even need to provide a GSSManager. The
GSSManager is a non-instantiable abstract class that just helps
demultiplex calls to provider specific factories.  The applet programmer
has a reference to the provider specific factory in what you propose and
can go directly to it for all queries meant for GSSManager. 

> the name of the provider class that implements GSSFactory.  The 
> application uses the GSSFactory interface to get instances of the 
> GSSContext, GSSCredential, and GSSName classes as needed.  Using 
> different implementations requires instantiating different classes, 
> this reinforces the fact that different implementations probably will 
> not co-operate to share tokens.  Here the GSSManager functionality is 
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I'm not sure I follow you here. The only time a system wide GSS-API would
have to interpret a token would be when it is the first token on the
acceptor side during context establishment. The format for this token is
laid out in the section "Mechanism-Independent Token Format" of RFC 2078
(page 78). After this the context handle or context object encapsulates
information about which underlying mechanism is being used. And no matter
where the mechanism came from, if it follows the specs for the GSS-API
implementation of that mechanism, the token will be readable.

> covered by the same class that implements GSSFactory.
> 
> 
> System Model
> -----------------
> In the "system" model there is a well known GSSManager class that 
> implements the IGSSManager interface. as well as well known 
> GSSCredential, GSSName and GSSContext classes that implement their 
> respective interfaces.  In this model there may be co-operation 
> between mechanisms so that tokens can be created for and used in 
> multiple mechanisms.
> 
> 
> I am pushing for two different models because applets and applications 
> need different things.  In the applet world the browser restricts 
> access to system properties and functions.  Browser support limits how 
> quickly new features are implemented.  Additionally, the smaller the 
> applet the better.  An application, on the other hand, can demand 
> better VM support, have huge code size, and access anything in the 
> system it wants to.  I would probably not be able to use the proposed 
> changes in an applet.  

In your proposal then there will be two sets of classes that GSS packages
will expose: 

Stand alone provider
--------------------

Will expose an implementation of the following interfaces to the
programmer -

GSSFactory

IGSSContext
IGSSCredential
IGSSName

and will expose the following concrete classes to the programmer -

GSSException
Oid
ChannelBindings
MessageProp

System wide provider
---------------------

Will expose the following concrete classes to the programmer - 

GSSManager

GSSContext
GSSCredential
GSSName

GSSException
Oid
ChannelBindings
MessageProp

(Instances of the IGSS* interfaces, if needed, will be obained via the
GSSManager which will query the provider under the wraps.)

If this is more or less what we all want then we will start thinking along
these lines and work out some thing to mail you next week. 

Thanks,
Mayank

> 
> 
> -Joe
> 
> 
> Code Samples
> --------------
> 
> New interfaces:
> /**
>  * IGSSManager is a interface to provide information about mechanism   
>  * implemented in the specific provider
>  *
>  */
>  public interface IGSSManager {
>    public Oid[] getMechs();
>         public Oid[] getNamesForMech(Oid mech) throws GSSException;
>         public Oid[] getMechsForName(Oid nameType);
>         public Oid getDefaultMech();
>  }
> 
> 
> 
> /**
>  * GSSFactory is the main interface that a provider implements. 
>  * The caller must know the name of the class that implements this     
>  * interface
>  */
> public interface GSSFactory {
>    // Factory methods      
>    public GSSContextInt    getContext();
>    public GSSCredentialInt getCredential();        
>    public GSSNameInt       getName();
> 
> }
> 
> /** an stand alone GSSAPI provider would implement both of the above   
>  *  interfaces
> 
> public class GSSStandAloneProvider implements IGSSManager, GSSFactory{
> 
> ...
> 
> }

==========================================================================
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]