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

[Weijun Wang <[e-mail]>]

On 2/6/2015 0:06, Greg Hudson wrote:
> 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.

I was wrong about that.

>
> 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.

It should not break. The peer might have been a non-Java app and is 
already sending that token.

One problem is that if the app "have already written extra code to 
generate that token and send it", now it will send it twice.

>
> 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.

Stream methods are not used by many. So most people would have to 
rewrite their apps to make use of this feature.

Thanks
Max

>
> (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.)
>