Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00

[Greg Hudson <[e-mail]>]

On 02/05/2015 02:46 AM, Weijun Wang wrote:
>> As I said, I don't have a strong opinion either way, but I'm not sure
>> why it would be important or useful to give the caller a chance to
>> decline to send an error token.
> 
> The current implementation does not send the error token (This is not
> precisely specified although the doc does mention that a token generated
> by initSecContext/acceptSecContext is meant to be consumed by
> acceptSecContext/initSecContext by the peer).  Either a caller does not
> want to send the token at all, or one should have already written extra
> code to generate that token and send it.

Error tokens are usually consumed by accept/init on the peer.  The
exception is if the peer is already in the GSS_S_COMPLETE state, in
which case it needs to be consumed by gss_process_context_token.

I don't think it's legitimate for a GSS application to decide to discard
a token simply because it came with an error return.  If the application
knows that the other peer is in GSS_S_COMPLETE state and the protocol
has no way of framing a context token to a peer in that state, then it
has no choice to discard the token.  But absent that specific knowledge,
the token should always be sent.

> If we now silently send the token, it will be a big behavior change and
> a surprise for everyone.

As an implementor I certainly understand wanting to be conservative
about surprising applications.  I don't know how likely it is that Java
applications would break if tokens started showing up in the output
stream when init/accept raises an error.

On the flip side, making the caller explicitly retrieve the token is
likely to result in a lot of applications which don't bother.  That's
unavoidable for the byte array methods, but not for the stream methods.

(As an aside, I believe the Python bindings plan to solve this by
raising an exception for the GSS_S_CONTINUE case as well as for errors,
so an application needs code to extract a token from an exception in
order to work for anything more than a single hop.)