Java GSI GSS-API Implementation Features and Limitations
The Java GSI implementation is an implementation of the Java GSS-API. It supports the GSS-API extensions and the new proxy certificate format specifications as defined by the Global Grid Forum.
The implementation is based on JSSE (for SSL API) and the BouncyCastle library (for certificate processing API).
Features:
- Implements Java GSS-API
- wrap/unwrap support SSL wrapped tokens
- Implements most of the GSS-Extensions including:
- Context options
- Supports PROTECTION_FAIL_ON_CONTEXT_EXPIRATION (in Java GSI GSS-API called CHECK_CONTEXT_EXPIRATION)
- Supports DISALLOW_ENCRYPTION (but only on a per-session basis)
- Defined additional options:
- GSS_MODE
- DELEGATION_TYPE
- REJECT_LIMITED_PROXY
- REQUIRE_CLIENT_AUTH
- Delegation API
- both wrapped and unwrapped mode (SSL compatible mode)
- Import and export of credential
- both opaque and mechanism specific data import/export
- Starting with JGlobus 2.0, SHA-2 (specifically SHA-256, SHA-384 and SHA-512) certificates are also supported.
- Supports GSI and SSL compatibility mode (set via context option interface - GSS_MODE)
- Supports limited and full delegation both using initSecContext/acceptSecContext
and initDelegation/acceptDelegation methods (set via context option interface
- DELEGATION_TYPE)
- Supports enabling / disabling checking of peer credential for limited proxy.
- Supports enabling / disabling client authentication for acceptors (set via context option interface - REQUIRE_CLIENT_AUTH)
- Supports checking GSSAPI credential usage, setting/getting context lifetime
- Supports anonymous authentication and anonymous credentials
- Supports internationalization of error messages
- Supports authorization check (on the initiating side, hostbased service, identity, etc.)
- Support certificate extension checking (certificate chain validation is performed by the ProxyPathValidation library)
- BasicConstraints and KeyUsage certificate extension are checked.
- Any certificates with unsupported critical extensions will be rejected.
Changes in JGlobus 2.0 GSSAPI:
- With the replacement of PureTLS with JSSE, SHA-2 (specifically SHA-256, SHA-384 and SHA-512) certificates are now supported.
- getMIC() and verifyMIC() are no longer available because of the underlying JSSE constraints.
- GSI_BIG QOP no longer available. wrap/unwrap can no longer switch between encrypted and unencrypted communication.
- setOption(GSSConstants.TRUSTED_CERTIFICATES, TrustedCertificates) and the corresponding getOption no longer supported. Standard GSI mechanisms can be used to specify the Trusted Certificate folder, etc.
- Previously deprecated setOption(GSSConstants.GRIM_POLICY_HANDLER, value) deleted.
- GlobusGSSCredentialImpl.getGlobusCredential replaced with GlobusGSSCredentialImpl.getX509Credential
- The "value" Object parameter to setOption(GSSConstants.DELEGATION_TYPE, value) should be of type GSIConstants.DelegationType, while Integer is supported as well for backward compatibility.
- Confidentiality service fixes
- RFC definition
- Only initiator can invoke requestConf. No default specified by Java-bindings RFC; per C-bindings (and also implied by the name requestConf) default is taken to be "false".
- Acceptor can only check if the established context provides confidentiality by checking the result of getConfState().
- Ability to selectively apply confidentiality via MessageProp.setPrivacy() object passed to wrap().
- GSI C GSSAPI behavior
- Only Initiator can request confidentiality since only init_sec_context() has the request_flags parameter. Confidentiality off by default causing the null cipher suites to be added at the front of the platform's default SSL cipher suites. If confidentiality is requested, the platform's default SSL cipher suite is used, which in most cases excludes the null ciphers.
- Acceptor and Initiator can check if the established context provides confidentiality by checking the return_flags parameter to accept_sec_context().
- Ability to selectively apply confidentiality, but only by requesting confidentiality at context establishment time and later selectively negating confidentiality by use of GSI_BIG QOP.
- OLD JGlobus behavior
- Initiator as well as Acceptor able to request confidentiality using requestConf() but this isn't guaranteed for the initiator since the null cipher suite TLS_RSA_WITH_NULL_MD5 is always added at the end. Confidentiality is on by default but even when confidentiality is on, TLS_RSA_WITH_NULL_MD5 is added at the end resulting in confidentiality not being guaranteed. If confidentiality is turned off, then only the null cipher suite TLS_RSA_WITH_NULL_MD5 is enabled.
- Acceptor and Initiator can check if the established context provides confidentiality by checking getConfState().
- Ability to selectively apply confidentiality, but only by requesting confidentiality at context establishment time and later selectively negating confidentiality by use of GSI_BIG QOP.
- NEW JGlobus behavior
- Initiator as well as Acceptor able to request confidentiality using requestConf() in which case only the non-null cipher suites supported by JSSE are enabled. Confidentiality is off by default causing all the null cipher suites to be enabled and placed in front of any cipher suites enabled by default by JSSE which are usually non-null cipher suites. In other words:
- Setting requestConf(true) will cause:
- all non-NULL cipher suites to be enabled
- all NULL cipher suites to be disabled
- SSLPolicyInt.TLS_RSA_WITH_NULL_MD5 to no longer be added at the end of enabled cipher suites.
- Setting requestConf(false) will cause:
- all NULL cipher suites to be enabled including SSLPolicyInt.TLS_RSA_WITH_NULL_MD5
- all the default enabled cipher suites (including non-NULL) to then be added.
- Acceptor and Initiator can check if the established context provides confidentiality by checking getConfState().
- Ability to selectively apply confidentiality no longer available as GSI_BIG QOP is no longer supported.
- WARNING: Applications that require confidentiality are supposed to check GSSContext.getConfState() after context establishment to make sure the confidentiality service is in fact available but none of them in jGlobus appear to do so!
Clarification:
- setOption(GSSConstants.REQUIRE_CLIENT_AUTH, true) and setOption(GSSConstants.ACCEPT_NO_CLIENT_CERTS, true) will cause the former setting to take precedence; in other words client authentication will be "required".
- setOption(GSSConstants.REQUIRE_CLIENT_AUTH, false) will cause the setting setOption(GSSConstants.ACCEPT_NO_CLIENT_CERTS, Boolean) to take precedence; "true" will cause client authentication to be "requested" but not required and "false" will cause client authentication to be not desired.
Limitations:
- No GAA support. Additional certificate chain validation is performed by the ProxyPathValidation library (this is performed after the SSL library verified the chain)
- Only looks for a proxy file when asked to load default credentials.
- Does not support protection key parameter to credential import and export API
- Does not support extensions parameters in the delegation API
- There
is a few unimplemented methods (e.g.in GSSContext: getWrapSizeLimit(),
export(), isTransferable(), etc) All unimplemented methods return GSSException.UNAVAILABLE
error and are marked as unimplemented in JavaDoc. Most of stream based operations
defined in Java GSS-API are not implemented (but can be implemented easily)
- The org.ietf.jgss.Oid is not completely implemented (this might be
a problem if the library is used with Java 1.3.x, that class is built in
with Java 1.4.x)
Versions of software used:
- PureTLS: puretls-0.9b4 with a few custom modifications
- Cryptix: 3.2 (PureTLS depends on it)
- Cryptix ASN.1 Kit (Custom version provided by PureTLS)
-
BouncyCastle: 1.17