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

From: Shoichi Sakane <[email-masked]>
Date: Tue, 29 Jul 2008 21:58:09 +0900

This is my response to the message from Jeff submitting in April.
I apologize to my so delayed response.

--Jeffrey Hutzelman wrote:
> 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.

My scenario is that a client has both the key shared with the KDC and
its realm name at least.  The KDC address is sometimes changed before
the node connected to the network.  So I want to add a mechanism
which the node gets the address of the KDC.

The embedded devices can not run without fundamental configuration.
I think the address of the KDC to which the client belongs must be
such information.

> "the default realm to be used when parsing a name with no realm"
> might be reasonable.

> 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.

> 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 agree with that getting several kerberos configuration from a DHCP
server.  If we want to include the DHCP option to get the configuration.
We have to classify the kerberos information which is allowed to pass
by the server, which is not allowed.  And, we need to define "local
security policy" of the configuration.

> 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.

That's true.

> 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.

Yes, your point is correct.  But, it's not always true.

In the industry networks, there are lots of small networks which are
segregated from each.  They run autonomously.  Some of them does not
use DNS because the communication is mostly closed within its network.
And the network has a mechanism to give the address which a node will
talk to.  In additon to that, some of industry network protocol assumed
existence of the DHCP server on the local network.  So I think that
getting configuration by DHCP is not bad idea, is resonable solution.

I don't say that any nodes using the Kerberos has to use the KDC's
address provided by a DHCP server.  If a node want to get the address
from a DHCP server, just use the DHCPv6 option.  Otherwise, use DNS or
manually configuration.

However, it is important to consider the conexistence of both mechanisms.
We need to clarify the behavior when there are multiple mechanisms in
the same network.  In addition, we need to consider the way not to mess
the current system when the DHCPv6 option is introduced.
> 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?).

DHCP is the protocol for host configuration.  It means that providing
the address of KDC as well as providing a set of configuration of the
Kerberos is straightforward on the DHCP protocol.  For example, the
DHCPv6 option for NIS configuration defined by RFC3898 provides the
address of the NIS server, which is like the client's KDC address.
It seems to me that the issue is majority and minority of the service.

> 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.

That's true.

> 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.

Yes, you are right.  Such configuration is useful to both nodes.
I have tought this issue at the dhc meeting of the previous IETF meeting.
My target is essentially industry networks where there are many IPv6
enable embedded nodes.  And each device is hardly configured due
to being several types of device, due to being poor interface for
configuration.  That is why I proposed a DHCPv6 option to get
such configuration.  If someone interested in adding a DHCP option.
I am happy with supporting it.

Best regards,

===
Shoichi Sakane
Yokogawa Electric Corporation

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

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 29 Jul 2008 10:52:49 -0700

> which the node gets the address of the KDC.

[from lower down]

. . . and there is no DNS service.

I have a prejudice in favor of using the DNS SRV records.  Of course  
you probably used the DHCP to find the DNS server in the first place,  
so that seems like an argument that there is no difference from a  
security standpoint.

Speaking personally:  no opposition, but no need for this feature  
either.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 30 Jul 2008 04:55:58 +0900

Hi Henry,

> . . . and there is no DNS service.

Right.

> Speaking personally:  no opposition, but no need for this feature  

I don't say that this feature is mandate.

If this feature does not exist, and if there is no DNS service,
the nodes can not get the KDC address.  It means that the node
can not talk to the KDC of the node's realm.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg