help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cfengine and hosts using DHCP


From: Mark . Burgess
Subject: Re: cfengine and hosts using DHCP
Date: Wed, 22 May 2002 22:48:49 +0200 (MET DST)

On 27 Apr, Juha Ylitalo wrote:
> Current mode in cfservd <-> cfagent interaction seems to be based on
> idea that both parties have static IP and they have been introduced to
> each others at some point by administration.
> Are there any best practises on how to use cfengine in environments were
> you have mixed environment of static and DHCP addresses (i.e. Linux/*BSD
> workstations and laptops), where your cfservd or other central file
> repository can give all its configuration files
> (/var/cfengine/masterfiles/inputs/*), but clients should somehow be able
> to verify that downloaded files came from trusted source?
> I guess I could create script that would download PGP signed tarballs,
> verify signature and then untar them to /var/cfengine/inputs, but if
> there are better solutions, I would like to hear about them.
>  

I would like to air/propose a solution for DHCP hosts and public/private
keys in cfengine. 

ASSUMPTION: servers have fixed IPs, otherwise there is no security,
and we might as well just switch off key checking.

The problem is that client IPs can change so authentication becomes
difficult. The server looks up the key for the corresponding IP address,
but it is not right because the IP has changed, while the key has
remained the same.

I propose a list with IP ranges which are "DHCP variable". If an IP
is in this list and TRUST is switched on, any existing key can be
replaced with a new key, and the old key is recorded in a "used cars"
list, access is granted. If TRUST is switched off, the server looks
in the "used car list" of all DHCP keys to see if it has been seen before. If 
not
access is refused. If it has been seen before -- it uses this earlier
trust to accept the connection and replace the IP-key binding.

With this approach, one salvages the autonomic nature of the key
dialogue, and keeps maximal security (minimal trust), thus avoiding
manual key management. 

Any suggestions?

Mark


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work: +47 22453272            Email:  Mark.Burgess@iu.hio.no
Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~





reply via email to

[Prev in Thread] Current Thread [Next in Thread]