On 11/2/11 8:57 PM, John C Klensin wrote:
Russ and I have assumed that your intended use of Kerberos was
hop-by-hop client-server, the sort of thing that could be done by
attaching some conventions to SMTP AUTH. I can imagine using it end
to end, with the message originator obtaining a ticket, including
that ticket with the message, and then having the delivery server
validate the ticket. That does eliminate the issues of relays and
hop-by-hop arrangements, but the result is the same problem in a
slightly different guise: the assumption that the recipient will be
able to access appropriate mechanisms to validate the ticket may not
hold up in a relay environment, especially if the relays cross
realms, just may not be true... and we are back to how one
establishes a global trust model and makes it work.
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.
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. Protection is achieved by ticket
verification based upon the realm's shared secret. The low overhead (in
comparison to other schemes) associated with ticket verification would
precede protected sessions.
The goal is to ensure the domain name used by an entity can remain a
solid basis for acceptance. When any identity granting acceptance can
be easily spoofed or replayed, it will be. Since the introduction of
IPv6, recognized domain names have become a more constrained dataset
than that of IP addresses. DKIM lacks practical replay protections and
SPF's authorization can not cope with shared resources or source
translations imposed by receiving networks.
Kerberos can limit use of a ticket, which may inhibit ticket
forwarding. The domain protection was intended for MTA to MTA
exchanges. Depending upon the Kerberos configuration, subsequent MTAs
may need to request separate tickets.