Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> writes:
I would like to thank you, Russ, and Keith for the feedback. I'll
attempt to pull together an I-D to further clarify. This is to allow
inbound MTAs the means to belong to a "protected" realm as specified by
their SRV records. The SRV indicated servers are to leverage the
verification of domain based certificates prior to the granting of
tickets. These tickets are protected by the realm's shared secrets.
An I-D would be helpful, yes, because the words that you're putting
together don't make a lot of sense to me. For example, you're talking
about using all of DNS, X.509 (I assume) for certificates, and Kerberos
tickets, and I'm not sure why you'd use all those together, or if you're
talking about using PKINIT to obtain Kerberos tickets.
If I had to guess, I'd say that you're postulating per-realm Kerberos KDCs
tied together via an X.509 infrastructure (with what issuing CA?) and
doing cross-realm authentication using something akin to the PKCROSS
proposals, but I'm not sure if I'm following. Having it all laid out in
an I-D would be helpful for that.
Generally, the change relevant to SMTP would be retrieving and caching
tickets for specific destinations within a protected realm at extended
intervals of perhaps every 10 hours.
Why would you need an SMTP-related change for the standard Kerberos
functionality of obtaining and caching service tickets? That would be a
good thing to explain in the I-D.
Kerberos can limit use of a ticket, which may inhibit ticket forwarding.
In practice, address restrictions in Kerberos tickets don't actually work
(due largely to NAT), which means that everyone turns them off, which
means that Kerberos has very little protection against ticket forwarding.
You can set a flag in the ticket saying whether it is forwardable or not,
but that flag is advisory for addressless tickets, and an attacker can
just copy the ticket to another host and use it anyway.
--
Russ Allbery (rra(_at_)stanford(_dot_)edu)
<http://www.eyrie.org/~eagle/>