Subject: FW: Java GSS-API Consensus

From: "Linn, John" <[email-masked]>
Date: Wed, 17 Nov 1999 15:14:30 -0500

CAT/Java fanciers:

Mayank Upadhyay has provided the attached summary of the ad hoc Java group
discussion which took place during last week's IETF meeting, and has asked
that I forward it to the WG. Thanks to all who contributed to this
discussion. I ask that WG members concerned with JGSS review this summary
and raise any requisite issues promptly in order that the JGSS specification
can proceed expeditiously towards WG Last-Call. 

--jl

---------------------------------------------------------

Following the working group meeting interested JGSS participants met
for a follow up discussion. These included Ram Marti, Gary Ellison,
Theodore Ts'o, Marc Horowitz, Ken Raeburn, Michael Smith, Jack Kabat
and Mayank Upadhyay.

We reconfirmed the agreement on the two issues that were decided at
the meeting:

 (a) Use of abstract class for GSSManager with a static getInstance()

 (b) Lack of support for Object as token

We have also reached a consensus on the remaining issue of provider
selection. While this is not an issue for monolithic GSS
implementations, our agreement was that there should be some sort of
minimal provider hooks in the API that would enable applications to
use non-monolithic implementations that support the Java
provider model. There was a concern that the GSSManager method
setProvider() that is included in the current draft might not be
sufficient for applications to do this.

To decide what minimal hooks need to be provided we first enumerated
the four basic ways in which we see most applications using providers:

 (1) Applications that don't care about what provider is used (the
 default case)

 (2) Applications that want a particular provider to be preferentially
 used for a particular mechanism

 (3) Applications that want a particular provider to be used
 preferentially all the time, irrespective of what mechanism is being
 used

 (4) Applications that want to use the locally configured providers as
 far as possible but if support is missing for some mechanism then
 check with their own provider

In order to support this functionality, two calls are required:
addProviderAtFront() and addProviderAtEnd(). These
calls have the effect of creating an ordered list of <oid, provider>
pairs where each pair indicates a preference of provider for a given
oid.

The use of these minimal hooks does not require any knowledge of the 
SPI and it is hoped that these will serve the needs of most
applications. Additional hooks may be added to an extended GSSManager
that could be part of the SPI specification that will follow later.

The specification for the two provider related methods is as follows:

(1) Non-static method in GSSManager:
	void addProviderAtFront(Provider, Oid) throws GSSException

addProviderAtFront is used to indicate to the GSSManager that the
application would like a particular provider to be used ahead of all
others when support is desired for the given mechanism. When a value
of null is used instead of an Oid for the mechanism, the GSSManager
must use the indicated provider ahead of all others no matter what the
mechanism is. Only when the indicated provider does not support the
needed mechanism should the GSSManager move on to a different
provider.

Calling this method repeatedly preserves the older settings
but lowers them in preference thus forming an ordered list of
provider and Oid pairs that grows at the top.

Calling addProviderAtFront with a null Oid will remove all previous
preferences that were set for this provider in the GSSManager
instance. Calling addProviderAtFront with a non-null Oid will remove
any previous preference that was set using this mechanism and this
provider together.

If the GSSManager implementation does not support an SPI with a
pluggable provider architecture it should throw a GSSException with
the status code GSSException.UNAVAILABLE to indicate that the
operation is unavailable.

(2) Non-static method in GSSManager:
	addProviderAtEnd(Provider, Oid) throws GSSException

addProviderAtEnd is used to indicate to the GSSManager that the
application would like a particular provider to be used if no other
provider can be found that supports the given mechanism. When a value
of null is used instead of an Oid for the mechanism, the GSSManager
must use the indicated provider for any mechanism.

Calling this method repeatedly preserves the older settings but raises
them above newer ones in preference thus forming an ordered list of
providers and Oid pairs that grows at the bottom. Thus the older
provider settings will be utilized first before this one is.

If there are any previously existing preferences that conflict with
the preference being set here, then the GSSManager should ignore this
request.

If the GSSManager implementation does not support an SPI with a
pluggable provider architecture it should throw a GSSException with
the status code GSSException.UNAVAILABLE to indicate that the
operation is unavailable. 

Examples:
---------

(1) addProviderAtFront

Suppose an application desired that the provider A always be checked
first when any mechanism is needed, it would call:

	GSSManager mgr = GSSManager.getInstance();
	// mgr may at this point have its own pre-configured list
	// of provider preferences. The following will prepend to
        // any such list:

	mgr.addProviderAtFront(A, null);

Now if it also desired that the mechanism of Oid m1 always be
obtained from the provider B before the previously set A was checked,
it would call:

	mgr.addProviderAtFront(B, m1);

The GSSManager would then first check with B if m1 was needed. In
case B did not provide support for m1, the GSSManager would continue
on to check with A.  If any mechanism m2 is needed where m2 is
different from m1 then the GSSManager would skip B and check with A
directly.

Suppose at a later time the following call is made to the same 
GSSManager instance:

	mgr.addProviderAtFront(B, null)

then the previous setting with the pair (B, m1) is subsumed by this
and should be removed. Effectively the list of preferences now becomes
{(B, null), (A, null), ... //followed by pre-configured list 

Please note, however, that the following call:

	mgr.addProviderAtFront(A, m3)

does not subsume the previous setting of (A, null) and the list will
effectively become {(A, m3), (B, null), (A, null), ...}

(2) addProviderAtEnd
---------------------

Suppose an application desired that when a mechanism of Oid m1 is
needed the system default providers always be checked first, and only 
when they do not support m1 should a provider A be checked. It would
then make the call:

	GSSManager mgr = GSSManager.getInstance();

	mgr.addProviderAtEnd(A, m1);

Now, if it also desired that for all mechanisms the provider B be
checked after all configured providers have been checked, it would
then call:

	mgr.addProviderAtEnd(B, null);

Effectively the list of preferences now becomes {..., (A, m1), (B, 
null)}.

Suppose at a later time the following call is made to the same 
GSSManager instance:

	mgr.addProviderAtEnd(B, m2)

then the previous setting with the pair (B, null) subsumes this
and therefore this request should be ignored. The same would happen if
a request is made for the already existing pairs of (A, m1) or (B, 
null).

Please note, however, that the following call:

	mgr.addProviderAtEnd(A, null)

is not subsumed by the previous setting of (A, m1) and the list will
effectively become {..., (A, m1), (B, null), (A, null)}

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