<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: CIPE source code modifications
From: Damion Wilson <dwilson,AT,ibl,DOT,bm>
Date: Tue, 25 Mar 2003 15:56:53 +0100
In-reply-to: <3E62A96A.9080905@ceag.ch>

This can be handled by different management frontends. My aim is to arrange 
things so that people with different security needs can write interfaces to 
cipsrvr that implement their particular style of management. In the future, 
you'll only have to maintain your control panel and not cipsrvr itself.
The BerkeleyDB interface that I want to use will allow protected CIPE 
configuration storage on floppies and USB keys, but some people will want to 
continue to use the registry. That's fine, too.

I'm simply trying to head off problems in the future of having multiple, 
imcompatible forks of cipsrvr.exe, which is a bad idea for the CIPE 
community. If everyone decided to do that then the project would be in 
disarray. There are obviously differing opinions on how the backend security 
of the cipe control information is handled on Windows (an issue that doesn't 
seem to exist on Linux) and the only way to properly handle it is to split 
off that functionality from the actual operation of the tunneling mechanism.

I'd appreciate your help in this matter. We all need to use as much foresight 
in this as possible.

On Monday 24 March 2003 09:41 pm, you wrote:
> Damion K. Wilson wrote:
> > BerkeleyDB supports Rijndael encryption/password protection of and entire
> > database. I'm thinking along those lines. I'll need some feedback from
> > the community on how the CIPE-Win32 Manager application is going to
> > address people's requirements. In fact, if the list could send me their
> > wish/pet peeve lists, that'd help a lot.
> I certainly cannot speak for the CIPE-Win32 community - just my personal
> opinion. I would propose continue using the Windows registry and
> optionally encrypt the entries that we would like to prevent from being
> inspected. A special database for this purpose would probably bring more
> problems than solutions, primarily because of the need to maintain and
> to manage the database files. I like the way the registry interface is
> made - I would not change it.
> Carsten.

<< | Thread Index | >> ]    [ << | Date Index | >> ]