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

[[e-mail] (Martin Rex)]

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


I'm sorry to disagree, but I believe that the opposite applies.

GSS-API does *NOT* define a wire protocol, only a wire token format.
It is *ENTIRELY* up to the application to decide about whether and how
to embed and send GSS-API tokens .. or not.

It is perfectly OK for an application to discard a context level token
from a gssapi mechanism that is returned along with a fatal major_status
from the context iterator call -- *unless* the specific application wire
protocol explicitly requires a different behaviour[*].


Since it requires additional application protocol complexity and additional
application code (calling of gss_process_context_token) to process
"unexpected" context token in an application protocol, it is *MUCH* easier
to unconditionally discard context level tokens from a context iterator
call that accompany a fatal major_status code.

A "portable" application caller does not know whether such a token
will be "unexpected" for the peer, so conveying such a token without
knowing whether the peer will be capable of dealing gracefully with it
is somewhat "risky".  My application code will never convey context error
tokens, I will not contemplating ever conveying error tokens, and I've
NEVER had a situation where this decision was detrimental during the
past 19 years where we've been using GSS-API to protect our application's
communication for our proprietary communication protocols.

-Martin


  [*] SSL&TLS define a wire protocol and specify certain behaviour in
  addition to protocol PDUs.  Microsoft implemented SSL&TLS with a GSS-API
  style interface: The Microsoft SChannel SSP, and the application caller
  "Microsoft IIS" unfortunately follows the proprietary apps protocol
  approach and discards error tokens, rather than sending fatal TLS alerts
  to the peer, as the TLS protocol _requires_ it.