On 11/12/2010 12:36 PM, Alex Peshkoff wrote:

> On 11/12/10 18:21, Jim Starkey wrote:
>> It occurred to me that it might be useful to have declarative,
>> enforceable security policy in the server based the client's IP address
>> zone, where zones might be defined as internal (behind a firewall), DMZ,
>> VPN, external, or whatever. The policy might dictate what the client
>> *must* use for session encryption -- none, RC4, AES128, AES256,
>> something else, or no access at all.
> Except server-wide policy per-user setting can also be welcome. If it's
> known that user MrX can work from home and his home IP is 1.2.3.4,
> personally he may be granted right to access server from particular IP.

In theory, yes. But he's going to have to get a fixed IP out of his ISP
to make that work. If he figures out how to do that, ask him to explain
how he did it...

>> Analogous to the initial connect
>> protocol, the server would give the client a choice of encryption
>> schemes and let the client pick one, perhaps based on a user parameter.
>> The client, of course, couldn't connect with anything other than his
>> give list. This would let security default within the firewall to no
>> encryption while requiring clients in an external zone to use a robust
>> -- but expensive -- session encryption.
>>
>> Another useful and easy to implement feature would be to restrict
>> capabilities based on zone and/or encryption level. Roman Simakov's
>> excellent point of setting passwords as weak link could be addressed by
>> a security policy that says that user administration must take place
>> over an encrypted linked, even if the client node lies within the
>> internal zone. It also could be used to say that user administration
>> could *only* be done from an internal zone.
> I.e. before connecting to server client (like isql) must know that it is
> going to perform administrative tasks?
>
>

I've been worrying about that. One solution is allow the encryption
level to be changed in mid-session and invent a DML extension to invoke
it. It could be done on the client side at the expense of limited
client side command parsing. A better solution is to let the server
initiate the change in encryption. This, in turn, would require yet
another protocol extension.

A secure architecture is going to require a modest number of protocol
extensions, which is why I am arguing to put the architecture and
infrastructure in place first, then implement the specifics as needed.


--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376