[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.