On 01/31/2013 10:35 PM, Kurt Seifried wrote:
Can't reply on the wiki page, FAS is throwing a 500 server error
try to log in.
On Thu, Jan 31, 2013 at 4:47 AM, Jaroslav Reznik <jreznik(a)redhat.com
= Features/LessBrittleKerberos =
Feature owner(s): Stef Walter <stefw(a)redhat.com
Make kerberos in Fedora simpler to use by removing some of the
that are common failure points. In particular we remove the need for
clients to sync their clocks, and remove the need to have reverse
carefully setup for services.
== Detailed description ==
MIT kerberos 1.11 now contains work so that clients do not have to
system clocks with that of the KDC. A time offset is discovered
and stored along with the local credentials. This removes a common
failure when using kerberos.
One concern, would this time offset be per server on the client, e.g. if
people get used to this then a group of servers may all have varyingly
wrong times (e.g. server A is 10 minutes fast, server B is 34 minutes
slow and server C is only off by 2 seconds).
It's stored per-realm on the client.
But yes, things do definitely get more complicated when servers with out
of sync times are involved. At this point, this feature is about
kerberos clients being out of sync, not servers.
This paper does outline some solutions for handling clock skew on
servers, and eventually we'll want to make sure we can handle this in a
robust and maintenance free way.
But for now, first step is to fix clock-skew for kerberos clients. This
has real benefits for Fedora users and
Also mitm attacks again.
That's a very general statement so I'll ask for details. Have you found
realistic MITM attack(s) in krb5 1.11?
To be clear, the above paper was largely implemented a while back in MIT
krb5, but only recently did we complete the work to make encrypted
timestamp preauth work with clock skew.
Is the following email post related to your concerns? If so, see the
remainder of the discussion:
Kerberos clients can optionally verify reverse DNS records for
they connect to as a way of trying to identify which realm they
However in many cases these do not exist. Kerberos should fall back
default behavior in that case. Failure to do this is a common point
when using kerberos.
would this for example cache data so that for example if the server has
reverse DNS setup, then it stops woring the client warns the user (e.g.
indicating a possible man in the middle attack)?
I don't think so. Apparently many (most?) kerberos implementations do
not look at reverse DNS data at all.