Internet-Draft M. Smith
Common Authentication technology WG TIAA-CREF
<draft-ietf-cat-gssv2-javabind-spi-02.txt> October 1999
Expires: January 2000
A Service Provider API for GSS mechanisms in Java
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2. Abstract
This document specifies a "provider API" by which GSS mechanisms
implemented in Java can be accessed through an intermediate "broker"
or "shim" layer.
3. Acknowledgments
This document is the result of work done in the Common Authentication
Technology (CAT) working group of the IETF. Special thanks are due to
Mayank Upadhyay and Jack Kabat. Thanks also are due to John Linn for
helpful comments on a preliminary version of this document. Dave
Arnold's eagle eyes detected several errors and inconsistencies in an
Smith Document Expiration: January 2000 [Page 1]
Java-GSS Service Provider API October 1999
earlier version. All errors and imbecilities, of course, remain the
author's own.
4. Introduction
The Generic Security Service API (GSS-API)[1], a product of the CAT
working group, specifies a language- and mechanism-independent
interface by which application programs can use security services
(e.g. authentication and privacy). Companion documents specify
"language bindings" of the abstract GSS-API to particular languages.
For the Java language binding, it seems appropriate to define a type
of GSS implementation consisting of a "shim" or "broker" layer,
providing no security services itself. Actual security services would
be provided by mechanism implementations (MIs). These MIs would
register themselves with the "shim" layer, and be accessed by the
shim layer through a "provider" API.
This document specifies the interface between "shim" layer
implementations and MIs; means for registering the latter with the
former; and means for controlling the "default mechanism" behavior of
shims. The interface exposed by the shim layer to application
programs consists of the interfaces defined for the Java GSS binding,
as described in [2], plus the additional methods specified in the
interface org.ietf.jgss-spi.MechanismManager, defined in this
document (see section 10 below). Note that the interfaces of the
Java-GSS binding remain the object of ongoing work; this document
will be aligned with the final state of those interfaces. It is not
expected that this alignment will involve changes to this document
above the level of minor detail.
5. Components of this specification
This specification defines a java "package", to be named
org.ietf.jgss-spi. This package contains the following interfaces:
org.ietf.jgss-spi.GSSMechanismManager extends
org.ietf.jgss.GSSManager
org.ietf.jgss-spi.GSSMechanism
6. The shim layer and the mechanism implementation layer
A "shim" implementation consists of a class implementing the
interface org.ietf.jgss-spi.GSSMechanismManager (which in turn
extends the interface org.ietf.jgss.GSSManager defined in [2]).
Smith Document Expiration: January 2000 [Page 2]
Java-GSS Service Provider API October 1999
7. Mechanism implementations and providers
A mechanism implementation (MI) consists of a class implementing the
interface org.ietf.jgss-spi.GSSMechanism described in section 9.2
below. It is instances of classes implementing GSSMechanism which
are "registered" by the "shim" as providers of security services.
Various means are provided for making MIs available to shim
implementations. An array of names of classes implementing
GSSMechanism may be listed in instances of java.security.Provider,
indexed by a well-known property name (see 10 below). As part of its
initialization, a shim implementation may query
java.security.Security's getProviders() method and register any MIs
found in installed java.security.Providers under this property name.
Providers containing this property name can also be passed to shim
instances after their initialization, and any MIs which they contain
added dynamically with instance scope (see 10.1.5).
Or the name of a single class may be listed in an instance of
java.security.Provider, under a property name containing a dotted-
decimal representation of an Oid. GSSMechanismManager provides
methods which will permit such a Provider instance to be passed in
and the GSSMechanisms it contains to be added dynamically with
instance scope (see 10.1.4 below).
Alternatively, instances of classes implementing GSSMechanism can be
passed directly (without being encapsulated in an instance of
java.security.Provider) to GSSMechanismManager's
insertMechImplementation() method, and inserted in the shim's list of
implementations, with shim instance scope (see 10.1.3 below).
Besides providing methods to manage the repertoire of MIs,
GSSMechanismManager also provides means to control the default
behavior of shim instances (see sections 10.1.2 and 10.1.3 below).
8. Names, credentials, and contexts
MIs must implement the interfaces GSSName, GSSCredential, and
GSSContext (defined in [2]). Note, however, that these interfaces
incorporate some degree of multi-mechanism functionality; since MIs
are not multi-mechanism, the functionality of some of the methods of
these interfaces, as implemented by MIs, will be circumscribed. These
limitations of functionality are described in detail in section 9.1
below.
Shim layers must also provide implementations of these three
interfaces; each "shim" name or credential will serve as containers
Smith Document Expiration: January 2000 [Page 3]
Java-GSS Service Provider API October 1999
for one or several MI names and credentials, and a shim context will
serve as a container for precisely one MI context. What follows here
is a general discussion of the relationship between (on the one hand)
names, credentials, and contexts created by the shim and used by
calling applications, and (on the other hand) those created by MIs.
For more detail, see the discussion of MIs' implementations of
individual methods of the three interfaces (below, sections 9.1.1,
9.1.2, and 9.1.3).
8.1. Names
The shim's version of createName() will produce a GSSName which
includes mechanism-specific names for as many of its registered
mechanisms as possible; a shim createName(), if no mechanism
parameter is provided, will successively call the createName() method
of each of its registered MIs. If an MI can generate a name
corresponding to the parameters provided, its createName() method
will return a GSSName (guaranteed, of course, to be a "name for
mechanism") based on those parameters; otherwise, it will throw an
exception, which will be caught internally by the shim's
createName(). When the shim's createName() has finished going through
its list of currently registered MIs, it will return an instance of a
class implementing GSSName and containing all the GSSName instances
successfully returned by the calls it made to the various MIs'
createName() methods. If no mechanisms were registered or if none
could successfully create a name from the parameters provided, the
shim's createName() will throw an exception. (See 11.5 below for
further considerations on this topic.)
8.2. Credentials
The shim's createCredential methods will in turn call the
createCredential methods of one or more registered MIs. If the
requesting application specified Oid(s) for specific mechanisms, only
MIs implementing the requested mechanisms will be called; otherwise,
the shim should call the createCredential methods of as many
registered MIs as possible. If the requesting application provided a
GSSName parameter, this must be a "container" name returned by the
shim as decribed in the previous section. The shim must pass to each
MI's createCredential call the MI-specific component of the shim's
container name object that was created by that MI; if a given MI was
unable to provide a component for this name, then it should not be
called. Each MI so called will attempt to obtain and return an object
implementing GSSCredential (with circumscribed, i.e. single-
mechanism, functionality as described more fully in section 9.1
below.) The shim's credential implementation, as returned to the
calling application, will act as a container for these various MI-
Smith Document Expiration: January 2000 [Page 4]
Java-GSS Service Provider API October 1999
specific credentials. If no mechanisms were registered or if none
could successfully create a credential from the parameters provided,
the shim's createName() will throw an exception. (See 11.5 below for
further considerations on this topic.)
The shim's implementation of the add() method of GSSCredential will
call the createCredential method of the MIs (if any) registered for
the Oid specified in the add() call, provided that the GSSName holder
(if any) associated with this GSSCredential holder contains a
component for that MI. If this process successfully returns a
credential, that credential will be added to the set contained in the
shim's GSSCredential implementation.
If there is no MI registered for this Oid, the shim will throw a
GSSException with status BAD_MECH. If a GSSName holder was provided
and it contained no GSSName element for any of the MIs implementing
this mech, a GSSException will be thrown with status BAD_NAME. If MIs
for this mech and appropriate GSSNames are found, but none of the
MIs' createCredential() methods succeeds, the shim will throw an
exception. (See 11.5 below for further considerations on this topic.)
8.3. Contexts
Contexts are created, in [2], by two versions of the createContext
call: one which takes an interprocess token and reconstitutes a
"freeze-dried" context, and others which take various optional
parameters and are used to establish a new context ab ovo (either on
the initiating or accepting side). Behavior of the first version
(with the interprocess token) is implementation-dependent and will
not be specified here. Behavior of the second version is, generally,
as follows (see 9.2 below for more detail):
The shim's createContext call will return an object created by the
shim and implementing GSSContext from [2]; this is referred to as the
"context holder." Any parameters (names, credentials, etc.) supplied
by the calling application will be stored away in this context
holder, but no MIs will yet be called; an initiating application may
still want to set various other context parameters, using the set()
methods of GSSContext, which may affect the choice of a mechanism,
and an accepting application has not yet provided an input context-
establishment token.
When the requesting application finally calls the context holder's
initSecContext() or acceptSecContext() methods, the shim will call
one or more appropriate MI(s) in an attempt to see whether any of
them can establish the context with the requested parameters. (If an
Oid specifying a mechanism is provided, of course, only MIs
implementing that mechanism will be called). As with the
Smith Document Expiration: January 2000 [Page 5]
Java-GSS Service Provider API October 1999
createCredential call (above), if name or credential parameters are
provided by the calling application, these must be the shim's
container implementations of these interfaces, and the shim will
provide, to each MI, only those name or credential components of the
name or credential container that were originally provided by that
MI.
9. The provider layer: details
Generally speaking, a mechanism implementation (MI) at the provider
layer looks very much like a single-mechanism GSS implementation,
with certain limitations and extensions. Such an implementation must
implement the interface org.ietf.jgss-spi.GSSMechanism described
below (section 9.2), and the interfaces
GSSName
GSSCredential
GSSSecurityContext
from [2].
Note, however, that these three GSS interfaces are designed, in
general, to encapsulate multiple mechanisms, and the interfaces at
the provider layer are designed only to encapsulate a single
mechanism. Thus, some versions of the methods defined in these three
interfaces are superfluous for MIs. These differences are described
in the following subsections.
For the sake of brevity, and to avoid duplication, the semantics of
methods in the MI version of these interfaces will be described only
to the extent that they differ from those defined in [2]. Methods
which do not differ as to signature, functionality, or exception
generation will not be re-described here.
(For some second thoughts on this subject, see 11.4 below).
9.1. Functional limitations in MIs
9.1.1. GSSName
MI implementations of GSSName can only be "names-for-mechanism" (MNs)
as defined in [1].
9.1.1.1. canonicalize()
The canonicalize() method in MI implementations of GSSName will throw
a GSSException with major status of BAD_MECH if the Oid parameter is
Smith Document Expiration: January 2000 [Page 6]
Java-GSS Service Provider API October 1999
not the one for the mechanism supported by this MI.
9.1.2. GSSCredential
9.1.2.1. add()
The method add() in MIs throws a GSSException with major status of
BAD_MECH, since MIs are not multi-mechanism.
9.1.2.2. getName(GSSOIDString mechoid)
This version of the getName method, which takes an OID designating
the mechanism, will throw a GSSException with major status of
BAD_MECH unless the Oid is the one for the mechanism supported by
this MI.
9.1.2.3. getUsage(GSSOIDString mechoid)
This version of the getUsage method which takes an OID designating
the mechanism wil throw a GSSException with major status of BAD_MECH
unless the Oid is the one for the mechanism supported by this MI.
9.1.2.4. getRemainingAcceptLifetime()
This method will throw a GSSException with major status of BAD_MECH
unless the Oid parameter is the one for the mechanism supported by
this MI.
9.1.2.5. getRemainingInitLifetime()
This method will throw a GSSException with major status of BAD_MECH
unless the Oid parameter is the one for the mechanism supported by
this MI.
9.1.3. GSSContext
MIs handle context initiation off the getContextForInit() method of
GSSMechanism (q.v., 9.2 below). This method takes parameters
representing the services being requested of this context, and
therefore, MI implementations of GSSContext no-op the various pre-
initiation methods of GSSContext, sc.
requestMutualAuth
requestReplayDet
requestSequenceDet
requestCredDeleg
requestAnonymity
Smith Document Expiration: January 2000 [Page 7]
Java-GSS Service Provider API October 1999
requestConf
requestInteg
requestLifetime
setChannelBinding
9.2. The interface GSSMechanism
For MIs, the interface GSSMechanism in effect replaces the interface
GSSManager defined in [2], and it has a certain family resemblance to
that interface, since it constitutes the factory class that MIs use
to create credentials, names, and contexts. Since an MI is single-
mechanism, however, and because this interface is not intended to be
used by application programmers, this interface can be somewhat
stripped-down as compared with GSSManager, for performance reasons
inter alia.
9.2.1. Constants
GSSMechanism defines the following bit-mappings of a short integer
field, to be used in indicating the services requested for a context:
public static short GSSServiceDelegReq = 1 << 0; // Delegation
public static short GSSServiceMutualReq = 1 << 1; // Mutual
authentication
public static short GSSServiceReplayDetReq = 1 << 2; // Replay
detection
public static short GSSServiceSequenceReq = 1 << 3; // Sequence
enforcement
public static short GSSServiceAnonReq = 1 << 4; // Anonymity
public static short GSSServiceConfReq = 1 << 5; // Confidentiality
public static short GSSServiceDelegReq = 1 << 6; // Integrity
9.2.2. Methods
9.2.2.1. No-parameter constructor
Classes that implement GSSProviderImplementation must provide a no-
parameter constructor.
9.2.2.2. acceptable()
The full signature of this method is:
Smith Document Expiration: January 2000 [Page 8]
Java-GSS Service Provider API October 1999
public boolean acceptable
(Object token,
GSSCredential cred,
Object[] channelBindings) throws GSSException;
This method indicates whether the Object passed as 'token' is usable
by the implementing mechanism as a context-establishment token, with
the credential in the second parameter and the channel bindings in
the third. The "cred" parameter may be null; this value requests
default credential behavior. If provided, 'cred' must be a
GSSCredential object returned by this MI; if not, a GSSException will
be thrown with major status of DEFECTIVE_CREDENTIAL. The
channelBindings parameter may be null, in which case the context will
not be bound to a channel.
This method is intended to be used by the acceptor-side version of
the createContext() method of the shim's GSSManager implementation to
determine which of the registered mechanism implementations to use
when a context-establishment token is submitted and a context is to
be initially created for acceptance.
9.2.2.3. getContextForAccept()
The full signature of this method is:
public GSSContext getContextForAccept
(Object token,
GSSProviderCredential cred,
Object[] channelBindings)
throws GSSException;
This method creates a security context using the MI's mechanism,
using the "token" parameter as a context-establishment token, with
the credential in the second parameter and the channel bindings in
the third. 'cred' may be null; this requests default behavior. If
non-null, 'cred' must be a GSSCredential object returned by this MI.
The channelBindings parameter may be null, in which case the context
will not be bound to a channel.
This method is intended to be used by the acceptor-side version of
the createContext() method of the shim's GSSManager implementation
when a context is to be initially created for acceptance.
9.2.2.4. getContextForInit()
The full signature of this method is:
public GSSContext getContextForInit
Smith Document Expiration: January 2000 [Page 9]
Java-GSS Service Provider API October 1999
(GSSCredential cred,
GSSName targname,
int lifetimeReq,
Object[] channelBindings,
short servicesRequested)
throws GSSException;
This method requests the provider to create and return a GSSContext
object for the mechanism this MI implements, suitable for use on the
initiating side of the context. The "cred" parameter may be null;
this value requests default credential behavior. If non-null, "cred"
must be a GSSCredential object returned by this MI's
createCredential() method. "targname" is a GSSName obtained from this
MI's createName() method designating the intended acceptor of the
context. "lifetimeReq" is the requested lifetime of the context (see
the relevant section of [1]); zero requests a mechanism-specific
default. "channelBindings" may be null and if so, the context will
not be bound to a channel. "servicesRequested" is a bit-mapped field
whose bits have the meanings described in 9.2.1 above.
This method is intended to be used by the initiator-side version of
createContext() in the shim layer.
9.2.2.5. initable()
The full signature of this method is:
public boolean initable
(GSSCredential cred,
GSSName targname,
int lifetimeReq,
Object[] channelBindings,
short servicesRequested);
This method requests the provider to determine whether a GSSContext
object can be created for the mechanism this provider implements,
suitable for use on the initiating side of the context, with the
parameters supplied. The "cred" parameter may be null; this requests
default credential behavior. "targname" is a GSSName obtained from
this MI's createName() designating the intended acceptor of the
context. "lifetimeReq" is the requested lifetime of the context (see
the relevant section of [1]); zero requests a mechanism-specific
default. "channelBindings" may be null and if so, the context will
not be bound to a channel. "servicesRequested" is a bit-mapped field
whose bits have the meanings described in 9.2.1 above.
This method is intended to be used by the initiating side's version
of the createContext() method of GSSManager in the shim layer, in
Smith Document Expiration: January 2000 [Page 10]
Java-GSS Service Provider API October 1999
determining which of the mechanisms available to use when initiation
of a security context is requested.
9.2.2.6. createCredential
The full signature of this method is:
public GSSCredential createCredential
(GSSName aName,
int lifetimeReq,
int usage)
throws GSSException;
This method is functionally equivalent to the method of the same name
in GSSManager (see [2], section 6.1.13), except that it does not
permit an Oid parameter to be provided (since MIs are single-
mechanism). 'aName' may be null, in which case default principal
credentials are being requested; otherwise, 'aName' must be a GSSName
returned by the createName() method of this MI.
9.2.2.7. GSSName createName(byte[] externalrep, Oid nameSpace)
This method is functionally identical to the method of the same name
in GSSManager ([2], 6.1.7), except that the 'name' object returned is
an MI-specific "name for mechanism" (MN).
9.2.2.8. Oid[] getNames()
Similar to getNamesForMech of GSSManager([2], 6.1.5) but takes no Oid
parameter identifying the mechanism (since MIs are single-
mechanism).
9.2.2.9. Oid[] getMech()
Returns an Oid identifying the mechanism implemented by this MI.
9.2.2.10. short getServices()
This method returns a bit-mapped short integer indicating to
services available from this MI (see 9.2.1 above).
Smith Document Expiration: January 2000 [Page 11]
Java-GSS Service Provider API October 1999
10. The shim's management API
The interface org.ietf.jgss-spi.GSSMechanismManager (which in turn
extends the interface org.ietf.jgss.GSSManager defined in [2])
defines both the application-related services of GSS itself, derived
from GSSmanager, and an additional set of management functions which
permit the repertoire of MIs available to be changed, and default
behavior to be specified. These management functions are the subject
of this section.
Conceptually, the shim maintains an ordered list of GSSMechanism
implementation instances (MIIs) known to it, and a corresponding
ordered list of Oids implemented by these MIIs; that is, a given MII,
and the Oid of the mechanism it implements, occur at the same ordinal
position on their respective lists. A shim's getMechs() method must
return Oids in the order in which they occur on this internal list.
Default behavior depends, in part, on the ordering of the internal
MII list. Versions of GSSManager methods (createName,
createCredential, createContext) which do not specify a mechanism Oid
will cause the list of installed MIIs to be "visited" in the order
defined by this internal list. Context creation, in particular, will
use the first MII on the list for which the following conditions are
satisfied:
1) Credential and/or name elements exist, provided by this MII, in
any instances of the shim's container credential or name classes
provided as parameters to the context-creation call; and
2) The MII can satisfy the services (e.g. anonymity, mutual
authentication, privacy, etc.) requested in the context creation
call.
Various means exist for adding MIIs to the list:
1) An array of names of classes implementing GSSMechanism may be
listed in instances of java.security.Provider, indexed by the
property name "GSSMechanism". As part of its initialization, a shim
implementation may query java.security.Security's getProviders()
method, call the constructor for each class listed under this
property name, and add each GSSMechanism instance so obtained to its
list of MIIs. The shim's MII list will then (after initialization)
hold all the GSSMechanism implementations listed in installed system-
wide Providers, in the order in which those providers were installed.
2) After initalization, GSSMechanismManager's
addProvider(java.security.Provider prov) method may be called; the
'prov' parameter will be searched for a property named
Smith Document Expiration: January 2000 [Page 12]
Java-GSS Service Provider API October 1999
"GSSMechanism," and MIIs installed from the class list associated
with that property, as described in the previous paragraph. This
method adds MIIs from providers to a specific instance of the shim
(not system-wide). Shim implementors may check with the local
SecurityManager or AccessController if it is considered necessary to
restrict this operation to privileged code.
3) The name of a single class may be listed in an instance of
java.security.Provider, under a property name of the form
"GSSMechanism-x.y.z...", where 'x.y.z...' is the dotted-decimal
representation of the Oid of the mechanism implemented by that class.
GSSMechanismManager's addProvider(Oid mech, Provider prov) method
will call the constructor for a class whose name is found in such a
property, and add the resulting GSSMechanism instance to the MII
list. This version of addProvider, like the previous one, operates on
a particular instance of the shim, rather than system-wide. Shim
implementors may check with the local SecurityManager or
AccessController if it is considered necessary to restrict this
operation to privileged code.
4) Finally, entries may be inserted directly into the list, or
removed from it, by the methods removeMechImplementation() and
insertMechImplementation(), defined below (section 10.1.1. and
10.1.2). These methods operate on a particular shim instance, not
system-wide, and additionally offer means to change the ordering of
MIIs on the internal list. Shim implementors may check with the
local SecurityManager or AccessController if it is considered
necessary to restrict these operations to privileged code.
All the methods discussed above, of course, affect the list of Oids
as well as the list of MIIs.
10.1. Methods of the management API
10.1.1. GSSMechanism[] getMechImplementations();
This method returns the list of the GSSMechanism instances registered
in this instance of the shim, in the same order as the corresponding
Oids would be returned by the getMechs() method defined in
GSSmanager. This order will correspond to the order in which the shim
will call its registered GSSMechanisms when it handles a method to
which a default mechanism parameter has been provided.
10.1.2. GSSMechanism removeMechImplementation(int position);
This method removes the MII at position 'position' from this instance
of the shim's internal MII list, and returns a reference to it. This
Smith Document Expiration: January 2000 [Page 13]
Java-GSS Service Provider API October 1999
method will throw an array index out of bounds exception if
'position' is out of bounds.
10.1.3. void insertMechImplementation
(GSSMechanism mii, int position);
This method will insert 'mii' at 'position' in the internal list of
MIIs maintained by this instance of the shim, and will move the
former occupant of 'position' and all its successors one step down
the list. The Oid of the mechanism implemented by 'mii' will be
inserted in the corrresponding position in this instance's Oid list
(i.e. the list of Oids that would be returned by getMechs()). This
method will not throw an index out of bounds exception; if 'position'
is past the end of the current list, this method will add 'mii' at
the end. If 'position' is negative, 'mii' will be added at the
beginning.
10.1.4. void addProvider(Oid mech, java.security.Provider prov)
throws GSSException;
This method permits MIs "contained" in java.security.Provider objects
to be added dynamically to shim instances.
The Provider 'prov' will be queried for a property with the name
"GSSMechanism-x.y.z...", where "x.y.z..." is the dotted-decimal
representation of the Oid in 'mech'. The value of this property
should be the name of a class implementing GSSMechanism. An instance
of the class will be created and added at the end of this shim
instance's current list of MIIs.
This version of addprovider() will throw a GSSException with major
status of BAD_MECH if no property with the appropriate name was
found, a GSSException with status UNAVAILABLE if the class denoted by
the property value could not be loaded, and a GSSException with
status FAILURE if the class denoted by the property value was
available but did not implement GSSMechanism.
10.1.5. boolean addProvider(java.security.Provider prov)
The Provider 'prov' will be queried for a property with the name
"GSSMechanism". The value of this property should be an array of
names of classes implementing GSSMechanism. An instance of each
class will be created and added at the end of this shim instance's
current list of MIIs. No exceptions will be thrown by this version of
addProvider(); it will return 'true' if any MIIs were successfully
added, 'false' otherwise.
Smith Document Expiration: January 2000 [Page 14]
Java-GSS Service Provider API October 1999
11. Topics for further discussion
11.1. SPNEGO
One reader of an early version of this document has raised the
question whether SPNEGO should be regarded as "just another mechanism
provider," or be included in the shim implementation. Either approach
is possible with the interfaces defined in this document. In favor of
including SPNEGO in the shim are arguments from performance and
interoperability. On the opposite side of the question is the desire
to minimize the size and complexity of the shim. The author sees no
clear-cut case for either approach; comments are sought from
interested parties.
11.2. A concrete class?
This document specifies interfaces only and leaves open the
possibility of multiple "shim" implementations. Some participants in
the Working Group have expressed the view that either in this
document or in the Java-GSS bindings document [2], a concrete class
ought to be specified which would have shim functionality and
consitute the "vanilla" or "default" or "reference" implementation of
GSS for Java.
11.3. SecurityManager/AccessController
Shim implementors may wish to use the authorization services of the
Java environment to control access to the management functions
defined in section 10.1 above. The Working Group may wish to consider
whether the means by which such checks are made should be
standardized, and if so, how: e.g. do we prefer to use some existing
type of Permission object and standardize its parameters for use by
shims, or define a new Permission object type, as part of this
specification?
11.4. New interfaces, or function limitation?
This document at present specifies that MIs implement the standard
GSS-API interfaces (defined in [2]) for name, credential, and
context; but by virtue of the inherently single-mechanism nature of
MIs, this document specifies certain limitations of function in these
interfaces as implemented by MIs. Perhaps it might be preferable to
define separate interfaces for MIs, modeled on the standard GSS
interfaces but with inherently single-mechanism semantics and
suitably adjusted parameters and exception repertoires.
Smith Document Expiration: January 2000 [Page 15]
Java-GSS Service Provider API October 1999
11.5. Comprehensive failure
It will sometimes occur that none of the registered MIs will be able
to establish a context or create a name or credential successfully;
but they may all fail for different reasons. What exception(s) should
the shim report in this case?
11.6. Diagnostic information from initable() and acceptable()
Do the methods initable() and acceptable() in GSSMechanism (sections
9.2.2.2 and 9.2.2.5) need to return more detailed diagnostic
information?
12. Security Considerations
This entire document deals with security.
13. Conclusion
This document specifies a "provider API" by which GSS mechanisms
implemented in Java can be accessed through an intermediate "broker"
or "shim" layer, and an API by which the repertoire of mechanisms and
default behavior can be managed.
14. References
[1] J. Linn, "Generic Security Service Application Program Interface,
Version 2, Update 1," Internet-Draft, <draft-ietf-cat-
rfc2078bis-08.txt>, December 1998
[2] Jack Kabat, "Generic Security Service API Version 2 : Java
bindings," Internet-Draft, <draft-ietf-cat-gssv2-javabind-02.txt>,
August 1998
15. Author's Address
Michael Smith
TIAA-CREF
730 Third Avenue
Mailstop 485-27-02
New York, NY 10017
Smith Document Expiration: January 2000 [Page 16]
Java-GSS Service Provider API October 1999
USA
Phone: 212 490 9000 x 1760
Email: ms@gf.org
Smith Document Expiration: January 2000 [Page 17]