[SPKM] Re: Comments on draft-zhu-pku2u-01.txt

Jeffrey Hutzelman wrote:
> 
> On Sun, 18 Mar 2007, Liqiang(Larry) Zhu wrote:
> > Jeffrey Hutzelman wrote:
> > > Why?  How does the initiator handle these tokens?  If it does so in any
> > > way other than by producing a new token, then the acceptor should not be
> > > returning GSS_S_CONTINUE_NEEDED.
> >
> > The deployment experience shows that if the client (instead of the
> > acceptor or the KDC) can log the error information, the cost of trouble
> > shooting is significantly lower.
> >
> > If the acceptor returns a KRB_ERROR message with a status that is
> > anything but GSS_S_CONTINUE_NEEDED, there is no guarantee and it is in
> > fact very unlikely that the trouble-shooting information can make it to
> > the client side in order to get logged.
> 
> No; you are confused.  GSS_S_CONTINUE_NEEDED does not mean "there is a
> token to send to the peer".  It means "another token is expected from the
> peer".  Any token produced by GSS_Accept_sec_context should be sent to the
> peer regardless of the returned status code.

Actually, that is not completely accurate.

An application that obtains a context token along with a fatal routine
error from one of the context establishment calls (gss_accept_sec_context
or gss_init_sec_context) is *NOT* required to send this to the peer.
It may do so, but it may also shutdown the communication channel.
I expect that a lot of applications will not actually send such a token
(ours doesn't).

> 
> Behaving otherwise violates the abstraction and will break application
> protocols which expect the GSS-API to behave as specified, regardless of
> which mechanism is being used.

Returning CONTINUE_NEEDED status when the mechanism spec does *NOT*
define a clear method how to continue the context establishment
handshake to successful completion is broken on my scorecard.

-Martin

_______________________________________________
SPKM mailing list
SPKM@ietf.org
https://www1.ietf.org/mailman/listinfo/spkm