Pinning KDC IP addresses. g.w at
Fri Feb 16 10:00:48 EST 2007

On Feb 15,  6:50am, Sam Hartman wrote:
} Subject: Re: Pinning KDC IP addresses.

Good morning to everyone.

> The position we're taking in the krb-wg is that it is inappropriate
> to assume that kdcs share state or that clients will tend to go back
> to the same KDC.

It thus seems fortuitous that OTI is focused on the anti-thesis of
KDC's sharing state or the notion of clients going back to the same

I find the krb-wg position intrigueing.

Does the position of the working group imply that KDC's are to be
discouraged from sharing information for replay avoidance and
authentication throttling?

If true this would seem to suggest a subliminal message to OATH and
HOTP.  The RFC for HOTP clearly indicates a T (throttling) factor as a
primary element in the security strength formula.

One would anticipate shared attempt information as a pre-requisite for
a truely robust throttling implementation in a master/slave

> In our preauth draft Larry and I are working on a state cookie that
> clients can send back to servers to establish state.

We differ perhaps only in semantic interpretation.  IDfusion has a
state cookie, only we call it the authorization payload field of the

> MIT is not interested in code that assumes requests should go to the
> same KDC unless the IETF decides to modify Kerberos and make this a
> requirement.

We would certainly not wish to burden MIT with any code.

The intent of OTI is not to constrain selection of target KDC's but to
allow the client to express its connection intention in a manner which
would preclude an attacker from re-using the one time identification
payload against another KDC.  Hence our interest in the callback which
Ken has discussed.

> --Sam

Best wishes for a pleasant weekend.

}-- End of excerpt from Sam Hartman

As always,

			 The Hurderos Project
         Open Identity, Service and Authorization Management

"Quidquid latine dictum sit, altum viditur."
        (Whatever is said in Latin, sounds profound.)
                                -- Kevin M Bealer

More information about the krbdev mailing list