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-i...@mit.edu>
>>>>> said:
>
>>>>> "t" == t p <daedu...@btconnect.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.
>
