[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Status of IPSEC Key Management
Hugo,
Good questions. When I say "SKIP" I mean the version of SKIP
without PFS, using long term D-H certificates. The 0-exchange key
generation nature of this version of SKIP is attractive, and the fact that
the traffic key is identified by crypto header information is important as
well. Admittedly, the 0-exchange feature is something of a misnomer, in
that each communicating party much have acquired the long term certificate
of the other in advance, and may also need to have acquired a recent CRL
too. However, these retrieval operations are outside the key management
protocol per se, and they need not involve communication with the other
party. Hence there is a difference between this approach and approaches
based on updated traffic keys generated from shared secrets created by
previous exchanges between the parties.
Does that help clarify my comments?
Steve
Message-Id: <199609130501.WAA07611@toad.com>
To: "Donald E. Eastlake 3rd" <dee@cybercash.com>
Cc: chk@border.com, perry@piermont.com, kent@bbn.com, ipsec@TIS.COM
Subject: Re: DNSSEC *can* retrieve "A" and "KEY" records in the same query
In-Reply-To: <Pine.SUN.3.91.960912081806.15052A-100000@cybercash.com>
Date: Thu, 12 Sep 1996 22:01:50 -0700
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
I stand corrected. I hadn't closely read the latest (-10) DNSSEC draft yet.
The ability to retrieve keys along with A and NS records reduces
long-haul round trips, because the keys will be cached and can be
retrieved from the local cache. There are currently no applications
which ask for both A and KEY records. The app (typically) asks for A
records with gethostbyname to open a TCP connection. When the first
TCP packet comes out, a key management daemon (on the same host, or on
a S/WAN gateway) asks for the KEY records.
John