[SPKM] 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