Internet-Draft M. Smith Common Authentication technology WG TIAA-CREF 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, , December 1998 [2] Jack Kabat, "Generic Security Service API Version 2 : Java bindings," Internet-Draft, , 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]