On 11/12/10 20:54, Jim Starkey wrote:

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

I have not tried it myself, but on site of my ISP I see 100 rubles (~
$3) for getting fixed IP and same payment ($3) per month for it.
But even if not - ISPs typically provide dynamic IP from known range. We
may specify that range.

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

This has one issue except protocol extension. When server asks client to
enhance encryption level, client does it and suggests user to repeat
last operation. Very good, but 99% of users will use same password value
like it was before. And that value already used to travel unencrypted
over network, and if caught - can be reasonably attempted a few minutes
after failed attempt. What to do? Keep blacklist of passwords
transferred insecure?

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

Our trunk is in a very good phase for protocol extensions - it is
unstable 3.0. Even if someone gets a build with half-done protocol, this
is not big problem :)
But certainly understanding architecture first is very good idea.