Subject: Re: [Ietf-krb-wg] adding KDC option for DHCPv6

From: Sam Hartman <[email-masked]>
Date: Fri, 04 Apr 2008 14:15:48 -0400

My main problem with this proposal is that today, Kerberos cannot
really work with one KDC.  In particular, KDCs can return referrals to
other kerberos realms.
Clients are responsible for finding these other kerberos realms.

I think that a DHCPV6 option for knowing the realm of the local client
would be a very good idea.

I think that if we plan to move to a model where you can ask your
local KDC to chase down a referral for you so that you only need to
talk to the local KDC then a DHCPV6 option to configure the address of
a KDC would not be a bad idea.

I don't think a DHCP option for the principal name of a device is a
good idea.  IN addition to a principal you need to configure a key.  I
don't think DHCP is an appropriate mechanism for configuring a key.
It seems that you should use whatever mechanism you use to configure
the key to also configure the principal.

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 04 Apr 2008 14:38:32 -0400

speaking as an individual...

> would be a very good idea.

I think that before talking about an option for this, you need to clarify 
what is meant by "the realm of the local client".  If all you mean is "the 
default realm to be used when parsing a name with no realm", that might be 
reasonable, though I'd be worried about workstations that behave badly when 
their configured default realm is not the same as that of some local 
service, or of the users who use it.  We see problems like this today from 
time to time.

I'm rather concerned about putting Kerberos configuration into DHCP in 
general, because much "Kerberos configuration" is really about local 
security policy, and you don't get much security if your security policy is 
set by listening to whoever suggests one.  However, there are some specific 
cases where I don't see a problem.

I don't see a security problem with configuring "default realm" via DHCP.

I don't see a security problem with configuring "address of KDC" via DHCP, 
but I also don't see it as a very good idea.  Even if you can ask "your" 
KDC to chase down referrals for you, "your" KDC is the KDC of the client 
principal, which is the only one the client can trust.  There are 
well-defined mechanisms for using the DNS to perform realm-to-KDC-hostname 
and hostname-to-IP-address mappings, and it just seems wrong to suggest 
that clients should talk to a KDC whose address is provided by a DHCP 
server instead of one for the client principal's realm.

In a more general sense, I don't think that using BOOTP or DHCP to provide 
clients with the address of "the" server for some application has ever been 
the right thing.  Doing so makes sense only in limited cases where the 
service in question is either part of the network infrastructure (like DNS 
servers) or closely tied to network topology (NTP servers, perhaps?).  For 
other things, it does not -- the address of "the" print server doesn't 
depend on where you are on the Internet; it depends on what printer you 
want to print to!  The same is true for a KDC; the address to use depends 
less on where you are than on what realm you want to reach.

Incidentally, it's not clear to me that any of this should be specific to 
DHCPv6.  Kerberos is a network-layer-agnostic service; any configuration 
derived from DHCP is likely to be just as useful to IPv4 nodes as to IPv6 
nodes.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Fri, 04 Apr 2008 15:06:25 -0400

Jeff, DHCP+possibly TFTP is the best option we have for configuration
of embedded network devices.  In that case, I actually think
specifying a lot of local security policy in DHCP is fine, although I
do draw the line at private/secret keys.