Subject: Incorrect JGSS Error codes in Sun's implementation of RFC2853

From: Dean Povey <[email-masked]>
Date: Mon, 15 Mar 2004 16:12:53 +1000

I realise that JGSS was probably worked on in the old CAT working group, 
but this seems like the most logical place to ask a question about the 
specification.

RFC2853 describes a Java binding for GSSAPI.  In this specification it 
lists a bunch of GSS Status codes and corresponding integer values to be 
used to indicate errors in a GSSException.

These are listed below:

      Table: GSS Status Codes

      Name                   Value   Meaning

      BAD_MECH                 1     An unsupported mechanism
                                     was requested.

      BAD_NAME                 2     An invalid name was supplied.

      BAD_NAMETYPE             3     A supplied name was of an
                                     unsupported type.

      BAD_BINDINGS             4     Incorrect channel bindings were
                                     supplied.

      BAD_STATUS               5     An invalid status code was
                                     supplied.

      BAD_MIC                  6     A token had an invalid MIC.

      NO_CRED                  7     No credentials were supplied, or
                                     the credentials were unavailable
                                     or inaccessible.

      NO_CONTEXT               8     Invalid context has been
                                     supplied.

      DEFECTIVE_TOKEN          9     A supplied token was invalid.

      DEFECTIVE_CREDENTIAL    10     A supplied credential was
                                     invalid.

      CREDENTIALS_EXPIRED     11     The referenced credentials
                                     have expired.

      CONTEXT_EXPIRED         12     The context has expired.

      FAILURE                 13     Miscellaneous failure,
                                     unspecified at the GSS-API level.

      BAD_QOP                 14     The quality-of-protection
                                     requested could not be provided.

      UNAUTHORIZED            15     The operation is forbidden by
                                     local security policy.

      UNAVAILABLE             16     The operation or option is
                                     unavailable.

      DUPLICATE_ELEMENT       17     The requested credential
                                     element already exists.

      NAME_NOT_MN             18     The provided name was not a
                                     mechanism name.

      OLD_TOKEN               19     The token's validity period has
                                     expired.

      DUPLICATE_TOKEN         20     The token was a duplicate of an
                                     earlier version.

For reasons best known to Sun, their implementation in JDK 1.4 ignores 
these status codes, and uses their own list:

public static final int BAD_BINDINGS 1
public static final int BAD_MECH 2
public static final int BAD_MIC 6
public static final int BAD_NAME 3
public static final int BAD_NAMETYPE 4
public static final int BAD_QOP 14
public static final int BAD_STATUS 5
public static final int CONTEXT_EXPIRED 7
public static final int CREDENTIALS_EXPIRED 8
public static final int DEFECTIVE_CREDENTIAL 9
public static final int DEFECTIVE_TOKEN 10
public static final int DUPLICATE_ELEMENT 17
public static final int DUPLICATE_TOKEN 19
public static final int FAILURE 11
public static final int GAP_TOKEN 22
public static final int NAME_NOT_MN 18
public static final int NO_CONTEXT 12
public static final int NO_CRED 13
public static final int OLD_TOKEN 20
public static final int UNAUTHORIZED 15
public static final int UNAVAILABLE 16
public static final int UNSEQ_TOKEN 21

These seem to correspond more or less to the C constants used in the C 
bindings for GSSAPI.

As a result, code compiled with a JGSS implementation that uses the 
constants defined in the spec will behave strangely when run with Sun's 
implementation and vice versa (Java binds constants at compile time, not 
run-time).

Now, I could jump up and down and point the finger at Sun's implementation 
and say it is clearly wrong.  However, there will be a lot of code out 
there compiled with these constants that will break if they change it.

Since as far as I am aware only Sun and us implement RFC2853 (we do the 
error codes correctly), then it seems to me easiest if we update our 
implementation to match Sun's and correct the specification.

So my question is, is this a sensible thing to do, and what would be the 
appropriate process?

Thanks.
-- 
Dean Povey,             |em: [email-masked]| JCSI SSO - Single Sign-On
Wedgetail Communications|ph:  +61 7 3023 5139   | for J2EE & Active Directory 
Level 14, 388 Queen St, |fax: +61 7 3023 5199   |          -oOOo-
Brisbane, Australia     |www: www.wedgetail.com | single-sign-on.wedgetail.com