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

From: "Mike Swift (NT)" <[email-masked]>
Date: Mon, 17 Nov 1997 10:40:07 -0800

Thanks for responding. I've inserted comments below

> -----Original Message-----
> From:	Theodore Y. Ts'o [SMTP:[email-masked]]
> Sent:	Saturday, November 15, 1997 2:37 PM
> To:	[email-masked]
> Subject:	draft-ietf-cat-iakerb-00.txt
> 
> 
> 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).
> 
Sounds like a good idea - once we finalize how to do this I'll update the
draft.

> 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 - if a ticket has already been obtained it makes no sense to get
another one. Should this draft be re-written as an extension of RFC1964 with
the same mechanism ID?

> 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.
> 
O.k.
> Proposed replacement text to section 2 which reflects the above
> comments follows:
> 
The text looks fine. If we decide thsi should be an extension of RFC1964
then I may reword this section to reflect that.

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

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Mon, 17 Nov 1997 21:53:12 -0500

From: "Mike Swift (NT)" <[email-masked]>
   Date: Mon, 17 Nov 1997 10:40:07 -0800

I think we will need to use a different mechanism ID so we can
distinguish between implementations that support these extensions, and
those that do not.  Keeping the protocols as aligned and as
backwards-compatible as possible will help make the implementation work
much easier, though.

I expect that there may be other extensions to RFC1964 that we will want
to add, eventually --- for example, support for triple-DES, since DES is
rapidly reaching the end of its useful lifetime.

   > one, or more TGS requests, as necessary.

After looking at the above paragraph again, I realized it needs
rewriting to be unambiguous; proposed replacement text follows:

The second phase, (which may be skipped if the client does not need to
take advantage of the remote KDC's Ticket Granting Service), consists of
the client sending a TGS request, and receiving a TGS reply from the
server.  After receiving the TGS reply from the server, the client may
repeat the above cycle of sending a TGS request and receiving a TGS
reply any number of times, as necessary.

							- Ted