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

Jeff wrote:
> This is a good point.  GSS_S_CONTINUE_NEEDED indicates that it will be

> necessary to make the call again with another token provided by the
peer. 
> When GSS_Init_sec_context or GSS_Accept_sec_context emits an error
token, 
> it should also return an appropriate error status, not 
> GSS_S_CONTINUE_NEEDED.

This is not necessary accurate. In the User2User protocol,
http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.tx
t,
the server can return a KRB_ERROR with the GSS_S_CONTINUE_NEEDED status.

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

On Friday, March 16, 2007 04:52:40 PM -0400 Olga Kornievskaia 
<aglo@citi.umich.edu> wrote:

>    In all cases, GSS_Accept_security_context() returns
>    GSS_S_CONTINUE_NEEDED status [RFC2743] and the output token is a
>    KRB_AS_REP message if a ticket was created or a KRB_ERROR message
if
>    there was an error while processing the request or the local policy
>    prevented a ticket from being issued.
>
> If the acceptor returns GSS_S_CONTINUE_NEEDED in the case of an error,
> what happens when the initiator after processing the error token
decides
> to stop, will the server just hang there in the continue needed state?

This is a good point.  GSS_S_CONTINUE_NEEDED indicates that it will be 
necessary to make the call again with another token provided by the
peer. 
When GSS_Init_sec_context or GSS_Accept_sec_context emits an error
token, 
it should also return an appropriate error status, not 
GSS_S_CONTINUE_NEEDED.

> Token ids are defined for KRB_AS_REQ and KRB_AS_REP but not for
KRB_ERROR?

The token ID for KRB_ERROR is defined in RFC 4121.

> Perhaps last paragraph of Section 6 can have a more detailed
explanation
> that doesn't require the user to go search for a different draft to
find
> our that AP_REQ should carry TYPED_DATA of type TD_IAKERB_FINISHED.
I'm
> sure i'm missing something but why is there a need to tie AS_REQ/REP
to
> AP_REQ/REP no such ties exist in original Kerberos message flow?

I'm not entirely sure what you're talking about here.  The AS exchange
is 
tied to a later AP exchange via the session key; this is true whether
the 
AS exchange results in a TGT or directly in some other service ticket. 
However, this does not protect the integrity of the plaintext portion of

the AS exchange, and in particular of PA-DATA contained in the AS-REQ,
and 
this is generally considered to be a shortcoming of the current AS 
exchange.  While this is likely to be fixed in the next update to the 
Kerberos protocol spec (see draft-ietf-krb-wg-rfc1510ter), it is also 
possible for a higher layer to perform an after-the-fact integrity check
of 
the entire AS exchange, as IAKERB does.  Whether this is necessary or a 
good idea is, of course, up for discussion.

-- Jeff

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