[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: key distribution
I think it's a big mistake to believe that a single means of negotiating
secure IP connections and authenicating your peet will covera all
circumstances. DNS may still have a roll to play.
Donald
From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert)
X-Charset: MACINTOSH
To: ipsec@ans.net (ip security mailing list)
>>From INTERNET RE>key distribution
>
>> 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.
I don't see that this point has much to do with anything. You can store
multiple RR's of any type in DNS...
>- 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.
It could but if you can get a good public key for your peer, you can
then negotiate all this.
>- 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.
This does not say much about how you initally get and authenicate
your peer's pubic key.
>- The establishment of keying relationships for broadcast and
> multicast communications need to be supported by IP-KM.
I'm not sure of all the ramifications here but there are currently
DNS entries for some multicast addresses.
>- 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.
An interesting point where its seems like some amount of external
configuration is going to be required. Just where this configuration
information is going to be stored is a question.
>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.
I have nothing against the peers sending each other certificates. IPSEC
should cerainly have a mode which works in the absence of the DNS service.
>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.
That's fine. I don't think the DNS is the solution to all problems.