Subject: Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option

From: t.p. <[email-masked]>
Date: Fri, 8 Jun 2012 11:37:27 +0100

Just to make public what I have hinted at privately, I think that steps
in section 4.1 may be somewhat underspecified.

They give the logic a client, one which supports both DHCP and DNS,
should
follow in order to find a KDC, with DNS information being preferred.
One scenario outlined in section 1 is of a user having entered userid
and
passphrase and waiting to be authenticated.  The steps imply a number of
timeouts in succession without specifying what balance to take of how
long
to wait for a server to respond versus how long to keep the user
waiting.
I would find it difficult to know what balance to strike without
guidance.

A related issue is that section 4.1 prefers DNS to DHCP for Kerberos
information but the Security Considerations stress the weakness of
DHCP and recommend authenticating DHCP.  What if DHCP is secure
and DNS is not?  Should DNS still be preferred?

Tom Petch

----- Original Message -----
From: "Jeffrey Hutzelman" <[email-masked]>
To: "Samuel Weiler" <[email-masked]>
Cc: <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, May 24, 2012 6:50 PM
Subject: Re: [secdir] secdir review of
draft-sakane-dhc-dhcpv6-kdc-option

---

From: tglassey <[email-masked]>
Date: Fri, 08 Jun 2012 07:23:33 -0700

> follow in order to find a KDC, with DNS information being preferred.
Yes, this is because the DNS auth models are better than DHCP today AFAIK.
> to wait for a server to respond versus how long to keep the user
True but this is likely to be set in the client as a flat config value 
one would think.

And if so this is actually a good thing you bring up Tom. My take is 
that from a policy management standpoint the  timeout period should be a 
"policy level" control IMHO and should have both a default value and a 
method of overriding it to allow people when they need to  to create a 
more "synchronous" expectation from a responder.
> and DNS is not?  Should DNS still be preferred?
DNSSEC is clearly beyond DHCP security models so perhaps for a working 
system this makes sense unless you want to create an autonomous DNS 
client which can exist in a pre-boot model.

Pardon my restating the obvious but "Still the issue is that DNS 
services dont work until they are loaded and DHCP is designed to work 
from a firmware boot (as we all know)".

How does this fit into what NEA is supposed to provide as a baseline?
> From: "Jeffrey Hutzelman"<[email-masked]>
> To: "Samuel Weiler"<[email-masked]>
> Cc:<[email-masked]>;
> <[email-masked]>;<[email-masked]>;<[email-masked]>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2178 / Virus Database: 2433/5055 - Release Date: 06/07/12
>
>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Jun 2012 15:00:29 -0400

>>>>> "t" == t p <[email-masked]> 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.