[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [resend] Use of DNS to distribute keys


> [....]  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
References: