gss_accept_sec_context & rcache

Jeffrey Hutzelman jhutz at
Tue May 30 10:00:11 EDT 2006

On Tuesday, May 30, 2006 11:18:47 AM +0200 Rainer Weikusat 
<rainer.weikusat at> wrote:

> Jeffrey Hutzelman <jhutz at> writes:
>> On Monday, May 29, 2006 01:05:47 PM +0200 Rainer Weikusat
>> <rainer.weikusat at> wrote:
>>> Is there a particular reason why gss_accept_sec_context
>>> returns GSS_S_FAILURE/ KRB5_RC_REPLAY for duplicate
>>> initiator tokens instead of GSS_S_DUPLICATE_TOKEN?
>> 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.  The implementation we're all talking about here is 
of GSS-APIv2u1, which is described in RFC2743 (with C and Java bindings in 
RFC2744 and RFC2853, respectively).  The current specs, published in 2000, 
_obsolete_ the old ones, which means text from the old spec is not part of 
the new one and does not apply.  So, let's stick to the current spec, OK?

On rereading, it appears that RFC2743 does permit sequencing-related errors 
to be returned during context establishment.  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.  But I 
guess we'll have to wait for someone from MIT to comment on their 
philosophy with respect to this.

-- Jeff

More information about the krbdev mailing list