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

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

I do not agree.

(OT: You might want to convince the MSIE/schannel maintainers,
 currently you need a debugger to figure our the SSL alert received
 by MSIE, MSIE itself presents just a useless "it may everything including
 sunspots" error messages, and its been doing this for 10 years).

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

IMHO, that is more of an application problem than a Kerberos problem.
With your approach, the error and all details will completely hidden
from the Server and Server admins.   I consider it a real problem
when the error is NOT locally reported where it occurs.

Whether and how much a client can do for trouble-shooting may
be application specific!  When helpdesk is called, the only
information that is reliably available/accessible is that
logged centrally on backends/servers.

E.g. when my application notices a "wrong target name in request"
type of error, it aborts the security context establishment
and returns an error message at the "application level" conveying
this error along with the name that the server uses for acquiring
his own credentials.  (since some gssapi mechanisms are poor at
determining this error, my application framing protocol sends
the target name along with the initial context establishment token
and when gss_accept_sec_context() fails with an error it compares
the accompanying target name with its own server name in order
to decide whether it sends a "wrong target name" application level
error message back to the client.

-Martin

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

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