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.

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