[....] You take the certificate you get back from the server and do a
cryptographic check back to the root key. That is a known problem (How
do you trust a key that someone sends to you in the mail anyways? Same
method!)
The biggest problem, currently, is getting DNS to deliver such large
pieces of data. That seems to be the more pressing problem. We solved
certificate verification in the creation of certificates.
An IP security protocol will (in some cases) facilitate trusted
communications between host pairs. Since the traffic between host
pairs is typically identified by address pairs in the IP header,
it makes sense to authenticate based on IP address. So when the
time comes to obtain a remote hosts certificate for IPSP, the local
host as already obtained it's address Just ask the remote host for
it's IP certificate, certificate chain, or partial certificate
chain as part of an IP security negotiation.
Key management is another issue. The process of address allocation
on the Internet is generally one where network providers or
administrators glom large chunks of address space and parcel them
out to smaller administrators and finally to individual hosts. A
certificate chain for an IP addresses should follow similar lines
with each subnet authority vouching for the addresses directly
below it.
For this to work, each IP certificate will need to reference it's
parent address space and each host should be prepared to offer a
(partial) certificate chain.
For example:
Host A [130.13.16.5] wishes to establish an authenticated confidential
communications channel with Host B [128.138.240.1]. It composes
a message which says something like this:
Hi 128.138.240.1, I'm 130.13.16.5
I will do these IPSP methods (in order of preference):
RSA
IDEA
EDE2
MD5 (integrity check using shared key)
Here's my RSA certificate chain:
130.13.16.5/32 [public key] expires 1/12/1993
- signed by 130.13.16.0/24
130.13.16.0/24 [public key] expires 1/10/1995
- signed by 130.13.0.0/16
130.13.0.0/16 [public key] expires 1/1/2001
- signed by 0.0.0.0/0
The remote machine also supports RSA and so verifies the first
hosts certificate chain. It picks one of the shared key/integrity
check methods supported by the first host and responds with something
like this:
Hi 130.13.16.5, I'm 128.138.240.1
Here is an RSA encrypted random number (for you):
[random key]
Do this IPSP method:
IDEA
From here on, all data is encrypted using IDEA with the least
significant 128 bits of the "random key".
It may be beneficial to break out the negotiation into separate
parts (key exchange methods, shared key methods, digital signature
methods), but care should be taken to avoid unnessesary chit chat
since this will drastically impact TCP setup time.
For a performance boost, systems could piggy back the TCP SYN and
ACK/SYN packets along with the IPSP negotiation messages for faster
TCP setup. This would suggest using an IP option as opposed to an
encapsulation method. On the other hand, encapsulation would seem
to be a better way to link subnet's together.
Comments?
brad