[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: revised IPsec minutes for Montreal

 
Ashar, 
 
>Received: SEPTEMBER 16, 1996 08:04 
>Sent: SEPTEMBER 13, 1996 16:52 
>From:     Ashar Aziz <ashar@osmosys.incog.com>  
> 
>About two weeks ago I sent the following protest regarding the 
>Montreal meeting minutes to the IPsec chairs.  I haven't seen 
>a correction posted or received any response to my message. 
>Since the minutes went out on the ipsec mailing list, I would 
>like to make my objections known here also. 
 
The minutes were updated and sent out directly to the IETF yesterday 
(September 15).  They should be updated on the web site soon.  Since you seem 
anxious to accurately capture and relive the excitement of the Montreal 
meeting the updated minutes are attached. 
 
 
Regards, 
 
Paul 
 
 
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
Paul Lambert                     Director of Security Products 
Oracle Corporation               Phone:         (415) 506-0370 
500 Oracle Parkway, Box 659410     Fax:         (415) 633-2963 
Redwood Shores, CA  94065       E-Mail: palamber@us.oracle.com 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
"Secure Jobs"  ->  send resumes to: palamber@us.oracle.com   
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- BEGIN included message

Steve,

  Please replace the currently online meeting minutes for Montreal's IPsec
meeting with those attached below.  Editorial changes were made per request
from Ashar Aziz.  These revised minutes have been specifically reviewed and
approved by Paul Lamber (IPsec co-chair) and Jeff Schiller (Security AD).

Thanks,

Ran
rja@inet.org





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
authentication 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 2-6 message exchange depending on how much state
already exists in the end nodes (specifically: 2 messages for Certificate
Discovery Protocol, 2 messages for Algorithm Discovery Protocol, plus 2
messages for PFS before the first data packet can be sent) with PFS (though
SKIP's PFS is different from others in that it does not provide PFS for
identities), anonymity, etc. SKIP's multicast approach is based on a group
co-ordinator creating a group key which the sender can then use (though the
SKIP multicast proposal explicitly does not specify how the group owner is
determined nor how knowledge of the group owner's identity is communicated
scalably and authentically to the members of the group nor how the group key
is created).  Use of an expanding ring search to find the information was
discussed as one approach to distributing the group private key. 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.
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 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.

--

-- END included message

Follow-Ups: