[Top] [All Lists]

Re: SMTP and Kerberos

2011-11-03 18:18:58

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.


<Prev in Thread] Current Thread [Next in Thread>