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

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. 
Based on the discussion here, the draft should acknowledge cases where
there is an error that is not a KDC error per RFC4120, say for example
the acceptor runs out of memory.

Jeffrey Hutzelman wrote:
> More generally, a mechanism should return GSS_S_CONTINUE_NEEDED in
exactly
> those cases where the peer is expected to send another token, and no
> others.
Would it be preferable to return a GSS_S_CONTINUE_NEEDED and a KRB_ERROR
in cases where the client is not expected to send another token, for
example in the case of a policy error? The error message contains useful
information for trouble-shooting. 	

I would not recommend returning an error token when the returned status
is NOT GSS_S_CONTINUE_NEEDED, in that cases, most apps would simply
throw that away.
--larry
-----Original Message-----
From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] 
Sent: Sunday, March 18, 2007 4:24 PM
To: Nicolas Williams
Cc: Liqiang(Larry) Zhu; Olga Kornievskaia; Michael.Eisler@netapp.com;
andros@citi.umich.edu; kitten@lists.ietf.org; spkm@ietf.org
Subject: Re: Comments on draft-zhu-pku2u-01.txt

On Sun, 18 Mar 2007, Nicolas Williams wrote:

> On Sat, Mar 17, 2007 at 03:04:39AM -0400, Jeffrey Hutzelman wrote:
> > On Fri, 16 Mar 2007, Liqiang(Larry) Zhu wrote:
> >
> > > 6. User to User when applied by server policy
> > >
> > >    In the case that the client application doesn't know that a
service
> > >    requires user-to-user authentication, and requests and receives
a
> > >    conventional KRB_AP_REP, the client will send the KRB_AP_REP
> > >    request, and the server will respond with a KRB_ERROR token as
> > >    described in RFC1964, with a msg-type of
> > >    KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may
optionally
> > >    pass the TGT in the data field of this error message. In
response to
> > >    this error, the initiator sets flags and returns a
> > >    GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism
> > >    described in section 4.
> >
> > While this is a token carrying a KRB_ERROR, it's not an "error
token" in
> > the sense that we're talking about.  In the context of Olga's and my
> > comments, an "error token" is one which causes the peer to abort
context
> > establishment and return an error status to its caller.  Such a
token
> > should never be returned with GSS_S_CONTINUE_NEEDED, because no
reply is
> > expected.
>
> The quoted text does not call this an error token.

No, it doesn't, but check the current thread.  The current PKU2U
document
indicates that "In all cases, GSS_Accept_security_context returns
GSS_S_CONTINUE_NEEDED... a KRB_ERROR if there was an error...".  Olga's
reading and mine is that this in some cases requires reinturning
GSS_S_CONTINUE_NEEDED with an output token that is an "error token" as I
define it above; that is, one which the initiator is expected to handle
by
aborting the context establishment (Olga didn't use the phrase "error
token", but I did).

Larry quoted the text from section 6 of the Kerberos U2U as a
counterexample to my argument that when an error token is emitted, it
should always come with a real error code, not GSS_S_CONTINUE_NEEDED.
But
the quoted text is not actually a counterexample, because although the
token described containes a KRB-ERROR, it is not an "error token"; it is
intended to trigger the U2U mechanism, which will result in another
context token.

The case described on page 5 of PKU2U-01 describes a token produced when
"there was an error while processing the request or the local policy
prevented a ticket from being issued."  These are situations in which
context establishment cannot continue, and the error token is intended
to
cause GSS_Init_sec_context to return an appropriate failure code.  Since
no further tokens are expected, the correct result code is something
other
than GSS_S_CONTINUE_NEEDED.

More generally, a mechanism should return GSS_S_CONTINUE_NEEDED in
exactly
those cases where the peer is expected to send another token, and no
others.

-- Jeff

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