[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No Subject
> I agree that DNS feels like the right way to store these things. It
> would be nice if someone could convey to the people doing the next
> generation of DNS that setting the record size high enough that this
> could be done would be a big win. Presently, records can't be large
> enough to accomodate future key lengths.
DNS may seem attractive at first, but obtaining the destinations certificate
is not the only requirement that we need to consider. Here are some ideas
on a few requirements:
- Multiple certificates may be supported by a single
IPSEC Key Management Agent.
- IPSP will support multiple algorithms. Determination of the
algorithm (for integrity, confidentiality, etc.) could be provided
by the same mechanism that establishes the cryptographic keying
relationship.
- The IPSEC Key Management (IP-KM) should provide Rpeer-entityS
authentication. A real-time authentication is required to
ensure that the keying relationship is established correctly.
- The establishment of keying relationships for broadcast and
multicast communications need to be supported by IP-KM.
- A mapping of the destination address to the address of an
intermediate IPSEC device must be supported. The address of
the decrypting device may not be the same as the final
destination.
Using DNS to retrieve the destination certificate would allow a key to be
created by sending only the initiators certificate to the destination. This
one-step key certificate exchange may appear to be a useful hack, but it
does not provide any way to support all of the requirements. As soon as you
consider exchanging more than one PDU, you might as well allow for the
destination to send its own certificate.
There may also be some problems using DNS to distribute certificates for
mobile hosts. The dynamics of a mobile-IP configuration would favor the use
of key management mechanisms that are peer-to-peer.