>> IMO, you add layers, transparent to the user experience,
>>until the easiest way to break the security model is for someone to
>>come into the office after hours and just take the server.
>Which brings up my favorite topic, physical security<GRIN>.
...which is something we can't do anything about, in VNC. It's solely the
responsibility of the guy owning the server.
Scott mentions the difficulties of revoking a compromised key. In the
context of VNC, how difficult does this have to be? Initial host-key
exchange is done using a "key password" which can be changed by the user by
physically sitting at the server (or by controlling it). Authentication is
done by the VNC password which is changed in the same way. Session keys
are generated randomly for each session. The next question is, do we need
a host key, and if so how does one go about changing it?
The session key could in theory be encrypted using the key password and
sent to the client, which would then decrypt it and start using it. If the
key password is compromised, full security is restored simply by changing
the key password. With a host key used as an intermediate step, if the
host key were to be compromised then all communications are insecure -
whether the key password or VNC password are changed - until the host key
can be replaced. This is doubly evil since once the key password is
compromised, so is the host key, so the above scenario of a compromised key
password means not only changing the password but the key itself.
Without a host key, one could argue that the identity of the remote server
becomes less verifyable than if one were present. However, given an
uncompromised key password, the encryption of the key using that password
is verification enough. On compromisation of the password, again changing
the password is sufficient to restore security and identity. This also has
the advantage that no host key is stored at the client end - since clients
are usually less secure than servers (and there are more of them), this can
only be a good thing. This is particularly relevant where no permanent
storage is available at the client, eg. a Network Computer or a Java
applet, or where a public terminal is involved.
In summary: the client is authenticated to the server by correct decryption
and use of the session key (implying knowledge of the shared secret - the
key password) and by regular VNC authentication. The server is
authenticated to the client by a valid host key being sent using the shared
secret.
Comments?
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED] (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]
The key to knowledge is not to rely on people to teach you it.
Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/
-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-----END GEEK CODE BLOCK-----
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
