Re: [kitten] Kerberos Realm Crossover with DNSSEC/DANE

[Rick van Rein <[e-mail]>]

Hello Greg,

Thanks for looking into this.

>
> * Are you sending these messages to the regular KDC ports, and then
> having the KDC dispatch them to a different process, or are you using a
> separate daemon?  I'm not sure whether these messages are part of the
> Kerberos protocol or not.


Yes, this is the intention.  That's why I've used [APPLICATION] tags
that differ from what Kerberos is using now (according to my grep over
RFCs that responded to "grep Kerberos").

The reason for coupling KDCs directly is so we can establish crossover
keys between realms that service all their users at once, for the
agreed-upon period of time.  Also, the KDC can be expected to have
access to DNSSEC/DANE validation, which may be more questionable for
clients behind uncontrollable middle boxes.

The reason for a different process to which the KDC dispatches is to
avoid filling up the KDC with slow external communication including
timeouts.

FYI, a student of mine (Oriol Caño) worked this flow into AS, in a
different daemon/process, and got it working (with syntax violations for
not passing back a Ticket) as the intended DANE-based construction of
ECDH crossover keys.  The only issue we ran into with the kdb API was
that we needed to supply a NUL-terminated ASCII string with a password,
while binary key computations are probably better in this case.


>
> * Wrapping the messages in padata and
> KX-REQ/KDC-REQ-MOD/KX-REP/KDC-REP-MOD seems to add a lot of complexity
> for no obvious benefit.  Can KX-PA-DATA messages be sent directly
> instead?


Yes, I think this would be fine.  I have tried to stay as close to the
existing packet structure to reduce the chances of trouble, hence the
Reserved fields.  But this is certainly something I can use this sort of
input on :)

>
> (With an application tag, if they're part of the Kerberos
> protocol, and of course with a different sequence name.)


Yes, of course.

>
> If there is a
> need for a typed hole in the new message type, a pa-data sequence can be
> included in the KX messages.


I see no such reason as yet.  I'm curious what Nico thinks though; he
has done some preliminary work on PKCROSS which approaches the problem
from a client.  That's another reason for the Reserved fields in the
*-MOD structures, to give that approach some wiggling room.

>
> Or the ASN.1 sequences can be made
> extensible (a good practice anyway) and extensions can require
> standardization, if we don't think there is likely to be lots of
> independent interest in extending this particular message type.


OK.  I saw no ",..." in RFC 4120 so I decided not to use it, but I am
quite happy to move in this direction.  You're actually saying the
things that I didn't dare to propose!

>
> * Since DANE is being leveraged as an anchor, I wonder if it would be
> possible to cut out X.509 and PKIX, without having to reinvent them.
> Could we store eddsa public keys in DNS and send eddsa signatures, for
> instance?


That would simplify matters, but also disable a few potential benefits:

* certificates signed by a federation CA could be used to mark the
boundaries of that federation
* extended key usage can be helpful to signal that a cert is indeed
meant to be used this way; that enables listing certain client
certificates, if the intention were to let those contact a KDC directly
(as under PKCROSS)
* extended key usage sets the certificates intended for KXOVER apart
from those that, say, merely identify the KDC to their clients as part
of PKINIT

The first may be resolved by explicitly mentioning acceptable pubkeys in
an accepted-remote list in the KDC config.

The second may be resolved if PKCROSS uses its own mechanisms (I can't
think of other EKU signals that could matter).

The third seems important, but may be resolved with a _kxover prefix in DNS.

> I realize there might be issues with key rollover and DNS
> caching, but I don't know whether those issues are automatically solved
> by using certificates.

I would love to get rid of the timing restrictions in certificates for
KDC use, indeed.

DNS timing issues are probably the same as for DANE.  We should
carefully choose our semantics here; it seemds reasonable to state that
the negotiated validity period for a crossover key (bounded by each
KDC's max setting) cannot be reduced by a retraction in DANE.  Or we
could state that no new crossovers should be created if DANE is
retracted.  Kerberos doesn't seem to be prepared for keys being
withdrawn after they are handed out in client TGTs.  Then again, the
situation we're talking about now is drastic.

I wonder if there is a suitable DNS RRtype to do what you are proposing
here?
 * CERT stores X.509 and OpenPGP keys
 * IPSECKEY and TKEY have dedicated/other purposes
We might define an extra case for TLSA, using the public key (or its
hash).  Or we might specify to ignore surrounding certificates by
default and strip it down to the public key.

Thanks!
 -Rick