Subject: picking PK-CROSS apart a little

From: Ken Raeburn <[email-masked]>
Date: 14 Apr 2001 06:13:47 -0400

After spending a little time meditating on cross-realm trust issues
recently, I starting thinking about an idea that I guess looks a
little like PKCROSS without the PK part, and certainly less fully
thought out.  So I've gone back to look at the PKCROSS spec, which
I've never really gone over in great detail, wanting to understand
PKINIT better before I start in on things based on it.  And so now
I've got some comments I'm going to inflict on you all.... :-)

First, as I understand it, PKCROSS adds a ticket extension which
provides a way of doing direct inter-realm authentication between
realms that haven't exchanged keys.  But is it really required that
the ticket in the extension be acquired through PKINIT?  Yes, one goal
of PKCROSS was to leverage existing PKI, but this extension seems
useful without the PKI, too.  For example, if RAEBURN.ORG and
ATHENA.MIT.EDU have exchanged inter-realm keys, and ATHENA.MIT.EDU and
CS.CMU.EDU have done likewise, shouldn't I be able to have the
RAEBURN.ORG KDC issue an inter-realm TGT for CS.CMU.EDU using this
same extension, and leave the ATHENA.MIT.EDU KDCs out of the loop for
random authentication exchanges?  The main difference is, the two KDCs
would use Kerberos rather than PK to authenticate to one another.

Does this sound like it's worth pursuing outside of PKCROSS?  The only
thing I think it would need at the moment is some specification of how
the ticket extension and the KDC option function that isn't tied to
the PK aspects.  And maybe a different name for the KDC option.

There's still the issue of whether such a ticket ought to be trusted,
of course.  Clearly, in the non-PK case, any intermediate realms
should be attached to the transited-realms field even if they weren't
explicitly accessed in a particular authentication exchange.  (The
remote realm should add them, when its TGS issues a ticket based on
one of these special inter-realm TGTs.)  This makes it no different
trust-wise than if the intermediate realms were actually contacted.

This in turn leads me to wonder what goes into the transited-realm
field in the normal PK version of PKCROSS.  Section 2 says:

    them.  In this way, we take advantage of the the distributed trust 
    management capabilities of public key crypography while maintaining 
    the advantages of localized trust management provided by Kerberos.

But since only section 5.4 mentions that field, it sounds like some of
the information from the PK side might not be provided to the
application server.  The current model in Kerberos 5 has been that the
application server has the responsibility to do the trust path
verification, with some optional help possible from the KDC in
kerberos-revisions via the TRANSITED-POLICY-CHECKED flag.  If the
information isn't supplied, a random application server is denied the
opportunity to do anything different from what the KDC administrators
have deigned to configure for the whole realm.

This isn't the first case where we've started going in different
directions.  Is the application client/server required to figure
something out?  Is the KDC required to provide the information?  Is
the client/server permitted to make its own decisions, or must
everything be centralized whether the maintainer of a particular
service likes it or not?

I also notice that there doesn't seem to be a mention of what client
and server principal names are used in the exchange between KDCs.  On
first reading, I was assuming the "krbtgt" principals would be used,
but since it is a different service -- and section 5.3 goes so far as
to say that different keys are used -- it seems logical to use a
different principal name.  Maybe "pkcross/REALM@REALM"?  If pkcross is
treated as a normal service that just happens to be implemented within
the KDC, stuff like the preserving of old keys described in 5.6 falls
out as (what should be) standard practice for dealing with servers.

Section 5.1 step 4 -- additional ticket extensions indicating hostname
or address (and port number?) of the remote KDC?  That'd probably be
useful in some non-PK situations too.  Though I like some of the
flexibility that SRV record lookups permit.

Ken