Editor's note: These minutes have not been edited.
IPSEC WG Meeting Notes, Montreal IETF, June 1996
The co-chairs would like to thank Steve Kent for contributing his
personal notes on the meeting, which were used as the basis for these
minutes. The co-chairs edited the notes somewhat, so any errors are
their responsibility.
SESSION 1, Tuesday: AH/ESP and existing IPsec documents
Jim Hughes presented his Combined ESP transform with HMAC and
anti-replay. Steve Kent suggested changing the proposal to rely on a
negotiated anti-replay window size, to accept all packets within the
window unless they are replays, and to not try to reduce the overhead
by relying on a constructed IV. All three suggestions were adopted. Note
that this protocol requires distinct simplex channel keys, derived from
a master key for the SA.
RSA reported on their S/WAN interoperability testing: TIS, NSA,
Raptor, SCC, and others worked well together. The next test session
will require Oakley/ISAKMP, and optionally SKIP, for key
management, in support of AH and ESP.
John Gilmore argued for widespread, near term deployment to protect
against passive wiretapping. His goal is 5% of Internet traffic by the
end of 1996. His personal agenda is to counter government (not just US
Government) efforts for key-escrow initiatives. His proposal is to put
crypto-walls in place (devices that don't even do packet filtering and
don't rely on authenticated keys). His tactic is to leverage freely
available software in order to build such crypto-walls, define new DNS
records for unauthenticated key storage, avoid export controls by
developing software outside of the US.
A firewall vendor gave a talk on using IPSEC with firewalls, as a
followup to mobile IP problem of getting mobile IP traffic out of a
foreign domain. Asssume a model where presence of valid AH is
required for firewall traversal, in either direction. The initially
presented model looks at traversing a single firewall, nominally at the
home agent permieter. The second model presented shows foreign and
home firewalls. The talk points out the need for multiple, layered SAs,
from MN-to-firewall-1, then maybe between firewalls, then from HA
to firewall-2, and eventually one SA above these to carry forwarded
traffic from HA to MN. Speaker notes the problems of being able to
transmit the mobile IP messages, ICMP messages, and key management
messages through firewalls as a precursor to establishing SAs in this
complex environment. The bottom line is that one has to look carefully
at the rules that firewalls employ to determine what traffic will be
allowed across, as this might cause serious problems for SA
establishment, especially for mobile IP case. However, the proposed
solution is pretty complex and there are easier approaches to dealing
with this problem in the mobile IP case, e.g., co-locating FAs and HAs
with firewalls, or establishing long term SAs, between HAs and FAs
and their local firewalls, to facilitate forwarding of mobile IP traffic.
Ran Atkinson spoke about the standards process and it's applicability
to the IPSEC RFCs. Because some of the 1825-29 RFCs are being
replaced, and because all of them cross reference one another, the group
cannot be advanced from Proposed Standard to Draft Standard until 6
months elapses after the last of the inter-related documents have been
updated. Ran also discussed his revised IPSEC Security Architecture
document, a replacement for RFC-1825. Steve Kent suggested that the
WG revisit AH to remove its two-different modes of use, given the new
ESP options that incorporate autehntication and thus obviate the need
for the embedded AH mode (ESP followed directly by AH). Steve also
suggested that the WG revise ESP to add in optional, variable length
fields for IVs, integrity checks, etc. so that the transform documents are
independent of one another and don't grow geometrically as new
algorithms are added. The WG adopted both suggestions and Steve
Kent agreed to work with the WG co-chairs to provide suitable text for
the revised RFCs.
Session 2, Wednesday: Key Management Issues
Bob Moskowitz (Chrysler) challenged the group to solve a network
layer security problem for communication among automotive parts
suppliers and manufacturers, but with a lot of nasty residual problems,
e.g., misuse of net numbers by particiants, diverse set of existing
firewalls, etc. Bob's goal is to start deploying IPsec by the end of 1996.
Ashar Aziz presented SKIP. Note the use of the SKIP header between
IP header and AH or ESP. Two modes of use: the first mode has no setup
messages once the master keys are in place, no Perfect Forward Secrecy,
and has significant per-message overhead. This mode relies on pre-
positioned D-H master keys from which unicast keys are derived. The
second mode uses ephemeral Diffie-Hellman, with certificates, in a 4-6
message exchange, with approximate PFS, anonymity, etc. Claimed
multicast mode support is based on a group co-ordinator creating a group
key (distribution of the private key to group members is not described
here and is potentially hard to implement or scale) which the sender
uses as the target for Diffie-Hellman computation. Checkpoint,
Toshiba, ETH, Sun have interoperable implementations of SKIP, based
on recent testing. Some gaps in the SKIP-06 spec were uncovered, and are
being fixed in the next draft. Ashar pushed for adoption of the
certificate discovery protocol (CDP) independent of SKIP. Also can
move CRLs as well as certificates, not just X.509 certificates, but PGP
too.
Doug Maughan reported on ISAKMP. Free software is available via
MIT server at
http://web.mit.edu/network/isakmp. cisco has also
worked on an ISAKMP with Oakley implementation, also freely
available from cisco and MIT web sites. There is also an
implementation by the UK Defence Research Agency. ISAKMP
provides very general KMP framework, capable of supporting various
key exchange algorithms, authentication, security association
management, and denial of service protection. Recent I-D changes:
moved from request/response to chained payload format (for better
performance and/or more flexible for multi-exchange protocols), can
negotiate multiple SPIs at the same time (for greater efficiency and
flexibility), and an expanded set of authentication payload types (for
better support of more exchnage types). Format is more complex now,
because of support of multiple paylodas per message, negotiating
multiple protocols at one time, etc. See version 5 specification I-D for
details. Jon Millen's analysis notes that cookies don't buy much Denial-
of-Service protection, and that authentication and key exchange is
sufficiently decoupled to require further analysis. Interoperability
testing, using Oakley, is now going on between cisco and DRA. Work
will continue to add other key exchange algorithms, commercial and
government.
Hilarie Orman described Oakley briefly. Oakley is quite flexible: can
use Diffie-Hellman exchange and/or pre-positioned keys or Public Key
(RSA) encryption ; authentication via RSA encryption, signatures or
predistributed shared secrets; integrity is available but can be omitted,
and Perfect Forward Secrecy is available but can be omitted. Minimal
message exchange is 3 messages, though more round-trips can also occur.
She has also published the group paramaters for several bases,
yielding 90-bit strength key outputs. ISAKMP integration is almost
complete. She suggested having the ESP and AH transforms define how
the necessary key bits are extracted from the output of the Oakley
computation. Basically, a general collection of modules that can meet
lots of different requirements, using a consistent syntax.
Dan Harkins reported on the status of the ISAKMP-Oakley integration
effort. A new Internet-Draft is out with a coherent profile of ISAKMP
and Oakley when used together. The first two ISAKMP messages
establish an SA, then the parties negotiate SAs for their clients. Four
modes of Oakley are specified: Main Mode (for ISAKMP phase 1
exchange, four messages); Agressive Mode (quick, but no identity
protection, an alternate phase 1 exchange in 3 messages); Quick Mode (
a phase 2 exchange, in 3 messages, but can be repeated multiple times
after a phase 1 exchange); Group Mode (for changing from one group to
another, over time). cisco's free ISAKMP+Oakley code will be
implementing this specification.
Hugo made some comments on Oakley/ISAKMP. He likes the overall
framework, but sees a need to refine the specs to remove some ambiguity
and facilitate interoperability. From a cryptographic standpoint he
has some suggestions, but lacked time to go into details. From a
capability perspective, he would like to see a support for pre-
positioned or centrally-distributed symetric keys, with PFS, which
Oakley does allow. cisco has indicated that they would accommodate
that request. Hugo doesn't like the reliance on Diffie-Hellman in the
new Oakley/ISAKMP profile, relative to the broader capabilities of
Oakley. Finally, Hugo expressed some concerns about the differences in
types of attacks one might mount in the public key vs. symmetric key
arena. The bottom line is that the ISAKMP and Oakley protocols
accommodate all of these suggestions, it's just an issue of of getting the
cisco implementation to incorporate these features.
Very brief, surprizing comments from John Gilmore, announcing that he
has purchased all of Bill Simpson's rights, including copyright, for
Photuris, to ensure that it is considered as a viable contender in the key
management protocol sweepstakes. However, he has not obtained any
rights to Photuris from Phil Karn. Further, there is no new draft
available addressing the previously discussed deficiencies of Photuris.
There was no evidence of broad support for Photuris at this meeting.
There was a short talk on Eliptical Curve Cryptography (ECC)
technology, for both Diffie-Hellman exchanges and DSA- & RSA-
equivalent (signature with recovery, but not excatly RSA) signautues. A
major benefit is that shorter key lengths are security equivalent to
larger key lengths. The IEEE P1363 specifications were mentioned and
there was some discussion of patents relative to the use of ECC. There
are some ECC-related patents, in addition to the general public key
patent, but they relate mostly to implementations not to the basic
math. The speaker is from Certicom, which holds some of these
implementation patents.
Closing discussions were process oriented, i.e., how will the WG decide
what will become the default key management standard for IPSEC ?
Jeff Schiller conducted straw polls which showed significant
differences of opinion between Oakley/ISAKMP and SKIP, although
everyone wants a quick resolution to the issue! Jeff suggests having a
special committee come back with a justifiable resolution.
