At first I thought that it might be good to leave section 4.1,
but now I changed my mind. I think the order of the preference
might depend on the running environment: some people prefer
"secured" one, some people prefer DNS... So I'd like to make
the order configurable and move section 4.1 to appendix, as a
hint for implementation.
masahiro
On Wed, 27 Jun 2012 15:00:29 -0400, Sam Hartman
<hartmans-ietf(_at_)mit(_dot_)edu> said:
"t" == t p <daedulus(_at_)btconnect(_dot_)com> writes:
t> Just to make public what I have hinted at privately, I think that steps
t> in section 4.1 may be somewhat underspecified.
t> A related issue is that section 4.1 prefers DNS to DHCP for Kerberos
t> information but the Security Considerations stress the weakness of
t> DHCP and recommend authenticating DHCP. What if DHCP is secure
t> and DNS is not? Should DNS still be preferred?
Yes probably.
DNS has been and will continue to be the dominant way to discover KDCs.
I see this as a specialized DHCP option for certain deployments, not
something you'll see in the enterprise for desktops or laptops as an
example.
I mean some people may deploy it, but I suspect that you won't see it in
most situations where DNS works well today.
So, basically in all cases, including preconfigured DNS servers, I'd
expect DNS to be preferred.
Note that choosing the right KDC does impact availability--if you have
the wrong KDC it won't work.
In general though, choosing the wrong KDC does not compromise
authentication. It's a bit more complex than that, but KDC location has
not generally been considered security sensitive.