Jonathon:
Heya. Sorry, I should have been more clear:
> 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).
What I meant to say was...a bit more wordy. :) It goes
something like this: suppose that, upon installation, the VNC server
auto-generates a pub-priv key pair. For every client you want to
connect to your server, you give them the generated public key (this
is very similar to SSH using its authorized_keys scheme for
authentication). You can now use this key-pair to increase the
security of VNC authentication by having the VNC server encrypt
its transmissions to the client using the private-key (presuming
some long-term storage ability of every client).
Fairly straightforward, and the pub-priv key pair can be
a sufficient 'pre-shared secret' to foil MITM attacks. The problem
is...suppose you install the decryption key into 100 clients for 5
different servers. And you learn after a month that the fourth
private key has been stolen, and you have to revoke it. It's easy
enough for machines you have physical control over, but for remote
clients that you only know via email....how can they verify it's
you emailing them? :) Really, digital-identity competition is
terribly messy.
> 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.
Well, security but not usability: if you change the 'key
password' no one can connect to your server until you tell them. :)
The biggest trick with using encryption to enhance security of an
electronic channel is how to securely send a secret before you have
the channel secured. And once it is secured, if it becomes compromised,
how do you tell everyone *except* the cracker that the security needs
to be re-initialized? I'm asking rhetorically here...it's a point of
endless debate.
> 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.
If I follow...you're suggesting that an extra password
authentication step be added before 'regular VNC authentication'.
That is, use some pre-shared secret to encrypt the random sequence
that starts the authentication process. I can't see this working if
the client cannot verify (by at least a digital signature) the
integrity of a server first, which requires the client have some
form of long-term storage. If not, a valid authentication exchange
from one session can simply be 'sniffed' and used again in an invalid
reply attack.
I appreciate your efforts with trying to design an improved
security model. A worthy effort, of course, and I wish you luck!
-Scott
---------------------------------------------------------------------
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
---------------------------------------------------------------------
