Re: Java GSS-API bindings

[Martin Rex <martin.rex at sap-ag.de>]

Bob Blakley wrote:
> 
> The CORBA security service was specifically designed to encapsulate GSS-API
> and is in a sense a somewhat more abstract binding for GSS-API.
> I'm including some snippets of the CORBA security interfaces for
> authentication, credential acquisition, and context establishment
> here for your edification and delight :-)
> All of the syntax here is CORBA IDL; this could easily be used as
> the basis for a java implementation.
> 

I must admit that I donÄ't know anything about Corba an Java, and
I'm could even be considered ignorant and biased against Corba,
but the supplied snipped looks suspiciously wrong about GSS-API
in a few details...

In the snippet I also see several GSS-API defined terms with
a different meaning and several terms that GSS-API doesn't have.
I don't particularly like this shift/change in terminology.

-Martin

> =========== type definitions ============
> 
> typedef sequence<SecAttribute> AttributeList;
> 
> // Security mech types supported for secure association
> const CORBA::ServiceDetailType SecurityMechanismType = 1;
> 
> // security association mechanism type
> typedef string MechanismType;
> struct SecurityMechandName {
> MechanismType        mech_type;
> SecurityName
>         security_name;
> };
> 
> // Authentication return status
> enum AuthenticationStatus {
> SecAuthSuccess,
> SecAuthFailure,
> SecAuthContinue,
> SecAuthExpired
> };

"expired authentication" is not defined by GSS-API.

> 
> // Association return status
> enum AssociationStatus {
> SecAssocSuccess,
> SecAssocFailure,
> SecAssocContinue
> };
> 
> // Authentication method
> typedef unsigned long AuthenticationMethod;
> 
> // Security features available on credentials.
> enum SecurityFeature {
> SecNoDelegation,
> SecSimpleDelegation,
> SecCompositeDelegation,
> SecNoProtection,
> SecIntegrity,
> SecConfidentiality,
> SecIntegrityAndConfidentiality,
> SecDetectReplay,
> SecDetectMisordering,
> SecEstablishTrustInTarget
> };


What is the meaning of this enum?  Many of this attributes are
available in combination with others, others may be meaningless
alone or might be conflicting!  Looks extremely weird to me.

Is this enum meant to represent multiple values within a set of
attributes (instead of a "C" bitfield)?  Then why is there a
"integrity", "confidentiality" AND a "integrity+confidentiality" ?

Btw. confidentiality without integrity is NOT available via GSSAPI.

> 
> // Security feature-value
> struct SecurityFeatureValue {
> SecurityFeature      feature;
> boolean value;
> };
> 
> typedef sequence<SecurityFeatureValue>SecurityFeatureValueList;
> 
> // Quality of protection which can be specified
> // for an object reference and used to protect messages
> enum QOP {
> SecQOPNoProtection,
> SecQOPIntegrity,
> SecQOPConfidentiality,
> SecQOPIntegrityAndConfidentiality
> };

QOP at GSSAPI is meant for selecting among different integrity and
confidentiality algorithms, NOT to select these basic services.
Again, GSS-API doesn't provide confidentiality without
integrity (which is a Good Thing!).

> 
> // Association options which can be administered
> // on secure invocation policy and used to
> // initialize security context
> typedef unsigned short AssociationOptions;
> const AssociationOptions     NoProtection = 1;
> const AssociationOptions     Integrity = 2;
> const AssociationOptions     Confidentiality = 4;
> const AssociationOptions     DetectReply = 8;
> const AssociationOptions     DetectMisordering = 16;
> const AssociationOptions     EstablishTrustInTarget
> = 32;
> const AssociationOptions     EstablishTrustInClient = 64;
> 
> // Flag to indicate whether association options being
> // administered are the "required" or "supported" set
> 
> enum RequiresSupports {
> SecRequires,
> SecSupports
> };
> 
> // Direction of communication for which
> // secure invocation policy applies
> enum CommunicationDirection {
> SecDirectionBoth,
> SecDirectionRequest,
> SecDirectionReply
> };
> 
> // AssociationOptions-Direction pair
> struct OptionsDirectionPair {
> AssociationOptions      options;
> CommunicationDirection     direction;
> };
> 
> typedef sequence<OptionsDirectionPair>OptionsDirectionPairList;
> 
> // Delegation mode which can be administered
> enum DelegationMode {
> SecDelModeNoDelegation, // i.e. use own credentials
> SecDelModeSimpleDelegation, // delegate received credentials
> SecDelModeCompositeDelegation// delegate both;
> };
> 
> // Association options supported by a given mech type
> struct MechandOptions {
> MechanismType      mechanism_type;
> AssociationOptions      options_supported;
> };
> typedef sequence<MechandOptions> MechandOptionsList;
> 
> ========== principal authentication interface (authenticates and acquires a
> credential)  =============
> 
> // Interface PrincipalAuthenticator
> 
> interface PrincipalAuthenticator { // Locality Constrained
> 
> Security::AuthenticationStatus   authenticate (
> in Security::AuthenticationMethod    method,
> in Security::SecurityName     security_name,
> in Security::Opaque      auth_data,
> in Security::AttributeList      privileges,
> out Credentials       creds,
> out Security::Opaque      continuation_data,
> out Security::Opaque      auth_specific_data
> );
> 
> Security::AuthenticationStatus   continue_authentication (
> in Security::Opaque      response_data,
> in Credentials       creds,
> out Security::Opaque      continuation_data,
> out Security::Opaque      auth_specific_data
> );
> 
> };
> 
> interface SecurityContext; //forward declaration
> 
> =========== Vault interface (equivalent to gss-init and gss-accept) ============
> 
> interface Vault { // Locality Constrained
> 
> Security::AssociationStatus   init_security_context (
> in SecurityLevel2::CredentialsList    creds_list,
> in Security::SecurityName     target_security_name,
> in Object       target,
> in Security::DelegationMode     delegation_mode,
> in Security::OptionsDirectionPairList
>    association_options,
> in Security::MechanismType     mechanism,
> in Security::Opaque      mech_data, //from
> IOR
> in Security::Opaque      chan_binding,
> out Security::Opaque      security_token,
> out SecurityContext      security_context
> );
> 
> Security::AssociationStatus   accept_security_context (
> in SecurityLevel2::CredentialsList    creds_list,
> in Security::Opaque      chan_bindings,
> in Security::Opaque      in_token,
> out Security::Opaque      out_token
> );
> 
> Security::MechandOptionsList   get_supported_mechs ();
> };
> 
> =========== Security Context interface (supports functionality of gss-sign and
> gss-seal) ============
> 
> interface SecurityContext { // Locality Constrained
> 
> readonly attribute SecurityLevel2::CredentialsList  received_credentials;
> readonly attribute Security::SecurityFeatureValueList security_features;
> 
> Security::AssociationStatus   continue_security_context (
> in Security::Opaque      in_token,
> out Security::Opaque      out_token
> );
> 
> void      protect_message (
> in Security::Opaque      message,
> in Security::QOP      qop,
> out Security::Opaque      text_buffer,
> out Security::Opaque      token
> );
> 
> boolean     reclaim_message (
> in Security::Opaque      text_buffer,
> in Security::Opaque      token,
> out Security::QOP      qop,
> out Security::Opaque      message
> );
> 
> boolean     is_valid (
> out Security::UtcT      expiry_time
> );
> 
> boolean     refresh (
> );

Now this last one looks REALLY strange.  What is that "refresh()"
supposed to mean?  Does it mean "security context refresh"?
I don't think so, since security context refresh is nothing that
can be done within GSSAPI (or any other abstraction that doesn't
include and control program flow and transport/peer communication.
And as soon as the library has that power, the "refresh" totally
disappears within the library.  A remaining problem associated
with security context refresh is the "expiration of the security
context while a message is in transit".  One basically cannot
hide this problem from the application, because it does impact
the communication architecture and error handling.

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
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 majordomo at lists.stanford.edu