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

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.

--larry

-----Original Message-----
From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] 
Sent: Sunday, March 18, 2007 4:44 PM
To: Liqiang(Larry) Zhu
Cc: kitten@lists.ietf.org; Nicolas Williams; andros@citi.umich.edu;
Michael.Eisler@netapp.com; spkm@ietf.org
Subject: RE: Comments on draft-zhu-pku2u-01.txt

On Sun, 18 Mar 2007, Liqiang(Larry) Zhu wrote:

> The intention of the text in -01 is that if a KRB-ERROR message should
> be generated according to rfc4120, then GSS_S_CONTINUE_NEEDED MUST be
> returned.

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.

_______________________________________________
Kitten mailing list
Kitten@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten

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