Proposal for using NAPTR/URI records

Greg Hudson ghudson at
Tue Feb 24 13:33:55 EST 2015

On 02/23/2015 11:59 PM, Nico Williams wrote:
> Using NAPTR certainly takes MS-KKDCP from the realm of curiosity that
> might turn out to be very handy, to the realm that requires
> significant security review and treading carefully.

>From the perspective of our client code, MS-KKDCP is just another way of
communicating with the KDC, functionally equivalent to TCP or UDP.  We
do not transmit any information about the sendto-kdc channel up the
stack; for instance, the proxy's name or certificate does not have any
impact on PKINIT KDC cert validation.

Using MS-KKDCP can provide some security advantages (e.g. a passive
listener cannot as easily capture PA-ENC-TIMESTAMP messages to conduct
offline dictionary attacks against), but everything above the sendto_kdc
layer considers those advantages to be incidental benefits or
defense-in-depth.  Auto-discovering the MS-KKDCP proxy discards most of
these security benefits (unless DNSSEC is used, or a private CA is
configured for verifying the proxy server cert), but does not introduce
any new vulnerabilities relative to communicating over TCP or UDP, which
we are already willing to auto-discover.

Using MS-KKDCP also provides firewall penetration for certain classes of
firewalls.  This, and not the additional security benefits, is probably
the motivating use case for proxy auto-discovery.

More information about the krbdev mailing list