Subject: RE: draft-ietf-cat-iakerb-00.txt

From: "Linn, John" <[email-masked]>
Date: Mon, 17 Nov 1997 10:09:02 -0500

Ted writes:

> 1)  Since the krb5-initialauth protocol is effectively an extension of
> the RFC-1964 Kerberos protocol, it would be useful if its method of
> assigning TOK_ID's were compatible with the general schema used by
> RFC-1964, to avoid the possibility of future TOK_ID clashes in future
> extensions of RFC-1964.  
> 
Good point.  I agree.

> Hence, I propose the following TOK_ID's to replace the ones in
> draft-ietf-cat-iakerb-00.txt:
> 
> KRB-AS-REQ	00 03
> KRB-AS-REP	01 03
> KRB-TGS-REQ	02 03
> KRB-TGS-REP	03 03
> 
> For historical reasons (which perhaps John Linn could shed some light
> upon), the second byte has been used to denote the general "class" of
> the GSSAPI token.  (00 is for the initial context stablishment, 01 is
> for sign/seal tokens, 02 is for delete context tokens).
> 
If I recall the rationale and discussion correctly, the idea is that
this two-level structure allows a quick demultiplexing on a received
token: the class level allows quick detection of whether a received
token is being passed to a call intended for the right phase of a GSS
context's lifetime, while the first byte discriminates among the various
messages which correspond to that phase. The current case could be
handled consistently either with a new "03" indicator as suggested or
with new non-colliding values in the "00" group; use of "03" seems
clean, conceptually corresponding to a new precursor phase within
context establishment. 

> 2) I suggest that the AS exchange be made optional; this allows the AS
> and TGS exchanges to both be omitted, at which point the protocol
> simplifies to the existing Kerberos V5 mechanism context establishment
> protocol.  At some point, when we revise the Kerberos V5 mechanism, we
> may want to simply include these tokens into the base mechanism.
> 
Agreed.  

--jl