Subject: summary of PKINIT and PKCROSS updates

From: Brian Tung <[email-masked]>
Date: Thu, 4 Dec 1997 09:32:00 -0800

John thought it might be a good idea to summarize the updates made to
the PKINIT and PKCROSS drafts.

PKINIT.  There are no large-scale changes to the PKINIT protocol.
Some minor changes have been made: the encoding for X.500 names,
the addition of two new encryption types, a new error type for when
the client doesn't possess or doesn't show possession of the right
KDC certificate, the use of a hopefully registered OID arc for the
principal name object for use in an X.509 certificate, a new method-
type for the CLIENT_NOT_TRUSTED error, and some other cosmetic
changes.

PKCROSS.  The protocol has, once again, been largely revamped, this
time to take advantage of the newly proposed ticket extension field
to be found in the Kerberos RFC Revision.  In short the protocol
goes as follows:

        1.  The client submits a request to the local KDC for
            credentials for the remote realm.

        2.  The local KDC submits a PKINIT request to the remote
            KDC.  This request has a flag set to indicate that
            the request is a special cross-realm key request.

        3.  The remote KDC responds as per PKINIT, except that
            the ticket contains a TicketExtension which indicates
            that this is a cross-realm key response.  The
            TicketExtension may also contain policy information,
            which the local KDC must reflect in the credentials
            it forwards to the client.  Call this ticket TGT_{L,R}.

        4.  The local KDC passes a ticket, TGT_{C,R}, to the client.
            This ticket contains in its TicketExtension field the
            cross-realm key ticket, TGT_{L,R}.  This ticket is
            encrypted using the key sealed in TGT_{L,R}.  (The
            TicketExtension field is not encrypted.)  The local KDC
            may optionally include another TicketExtension type that
            indicates the hostname and/or IP address for the remote KDC.

        5.  The client submits the request directly to the remote
            KDC, as before.

(The preceding exposition stolen shamelessly from our own draft.)

I will discuss these changes in further detail in Washington, D.C.

b