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

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Sat, 15 Nov 1997 17:37:14 -0500

I've just read over draft-ietf-cat-iakerb-00.txt, and have the following
following comments to make.

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.  

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

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.

3)  I suggest that the protocol used in this draft be more formally
specified.  Currently, it is at most informally defined, with the
discussion in the "Sample Usage Scenarios" necessary in order to
determine the actual protocol flow.

Proposed replacement text to section 2 which reflects the above
comments follows:

------------------------------------------

2.    Basic Protocol

The mechanism ID for user to user GSS-API Kerberos, in accordance with
the mechanism proposed by SPNEGO for negotiating protocol variations,
is:

    {iso(1) member-body(2) United States(840) mit(113554)
   infosys(1) gssapi(2) krb5(2) initialauth(4)}

The basic protocol is an extension of the GSSAPI Kerberos V5 mechanism
documented in RFC1964 [2], and consists of two optional phases, and one
mandatory phase.  The two optional phases use the AS and TGS exchanges
as defined by the Kerberos V5 protocol in RFC1510 [1].

In the first phase, the client may send an AS request to the server, to
which the server responds with an AS reply.  If the client does not need
to engage in an AS exchange, it may skip this phase and proceed on to
the second or third phase.  

In the second phase, the client may send a TGS request to the server, to
which the server responds with an TGS reply.  The client may send zero,
one, or more TGS requests, as necessary.

Finally, the third (and mandatory) phase consists of the GSSAPI Kerberos
V5 initial context establishment exchange, as defined by RFC1964 [2].

The client may either request a TGT during the first, AS exchange phase
or directly request a session ticket if the connection is for a short
period, only one service will be contacted, and the service principal
and client principal are both in the same realm.  Otherwise, the client
will use the TGT it initially obtained and use it to create further TGS
requests during the second phase.

The AS request, AS reply, TGS request, and TGS reply messages are all
encapsulated using the format defined by RFC1964 [2].  This consists of
the GSS-API token framing defined in appendix B of RFC1508 [XXX]:

   InitialContextToken ::=
   [APPLICATION 0] IMPLICIT SEQUENCE {
           thisMech        MechType
                   -- MechType is OBJECT IDENTIFIER
                   -- representing "Kerberos V5"
           innerContextToken ANY DEFINED BY thisMech
                   -- contents mechanism-specific;
                   -- ASN.1 usage within innerContextToken
                   -- is not required
           }

The innerContextToken consists of a 2-byte TOK_ID field (defined below),
followed by the Kerberos V5 KRB-AS-REQ, KRB-AS-REP, KRB-TGS-REQ, or
KRB-TGS-REP messages, appropriate.  The TOK_ID field shall be one of the
following values, to denote the Kerberos V5 protocol message which has
been encapsulated in the message:

	Message			TOK_ID

	KRB-AS-REQ		00 03
	KRB-AS-REP		01 03
	KRB-TGS-REQ		02 03
	KRB-TGS-REP		03 03

------------------------------------------

Comments?

						- Ted