gss_accept_sec_context & rcache

[Rainer Weikusat]

Jeffrey Hutzelman <jhutz at cmu.edu> writes:
> On Tuesday, May 30, 2006 11:18:47 AM +0200 Rainer Weikusat
> <rainer.weikusat at sncag.com> wrote:
>
>> Jeffrey Hutzelman <jhutz at cmu.edu> writes:

[...]

>>> Because GSS_S_DUPLICATE_TOKEN means that a duplicate per-message token
>>> was received when message replay detection is enabled.  It does not
>>> apply to context negotiation.
>>
>> This is a quote from RFC1509, section 3.4:
>>
>> 	GSS_S_DUPLICATE_TOKEN The input_token is valid, but is a
>>                         duplicate of a token already processed.  This
>>                         is a fatal error during context establishment.
>>
>> The same text is contained in RFC2744 (and in both language
>> independent API specifications as well).
>
> First of all, RFC1508/1509 describe GSS-API version 1, which AFAIK no
> one has used in some time.

One possible reason for this would have been 'backwards compatibility
to v1', which is why I wrote that both v1 and v2 demand this
behaviour:

	The GSS major status code GSS_S_FAILURE is used to indicate
	that the underlying mechanism detected an error for which no
	specific GSS status code is defined.
        (RFC2744, p. 14)

Which fairly clearly implies that GSS_S_FAILURE should not be returned
if such a more specific code exists.        

[...]

> On rereading, it appears that RFC2743 does permit sequencing-related
> errors to be returned during context establishment.

There are two 'sequencing errors' defined by GSSAPI, namely
GSS_S_UNSEQ_TOKEN and GSS_S_GAP_TOKEN, none of which may be returned
by gss_accept_sec_context (they don't make much sense w/o an
established context, anyway).

> So, it would be reasonable for the library to behave as you suggest.
> Which brings us back to your original question - why doesn't it?  My
> guess is going to be that not much translation of error codes is
> done at this layer - if the underlying Kerberos operation fails,
> you're going to get GSS_S_FAILURE, unless there's a specific reason
> something more detailed needs to be returned.

The 'specific reason' here would be 'spec says it should be that way'.

The point of the question was mainly 'is this an old bug in code
nobody has looked at for a couple of years or something particularly
clever I am missing'.

I am going to assume the former.