CURRENT_MEETING_REPORT_

Reported by Paul Lambert/Motorola

Minutes of the Internet Protocol Security Protocol Working Group (IPSEC)

The IPSEC Working Group met during the twenty-ninth IETF and discussed
the IP Security Protocol (IPSP) and IP Key Management.  Two separate
meetings on these topics were originally scheduled, but a conflict with
security topics presented during the Wednesday plenary forced the
combining of the two sessions.


IP Security Protocol Status and Discussion

A brief summary of the working group status, charter, goals, and related
work was presented.  The working group has been slow in developing an
Internet-Draft for the IP Security Protocol (IPSP). There are many
specifications for RNetwork Layer SecurityS (SP3-N, SP3-A, SP3-I, SP3-D,
SP3-C, NLSP, I-NLSP, swIPe, PIP and others), but there currently is no
consensus approach represented in an Internet-Draft.  There are also
many implementations of various flavors of IP layer security (ANS, AT&T,
DEC, Hughes, Morningstar, Motorola, Semaphore, UUNET, Qualcom and
others).  So far, none of these implementations interoperate.

A presentation was given describing a proposal being developed by Jim
Zmuda and Paul Lambert.  The proposal represented work developed from
the February 1995 ISOC Symposium on Network and Distributed Systems
Security (SNDSS). A generic protocol format supported any cryptographic
encapsulation technique.  A specific example (also suggested as a
default) used DES for the encryption algorithm and MD5 as an integrity
check value algorithm.

Donald E. Eastlake gave a verbal description of the draft specification
that he had posted to the mailing list earlier in the morning (PIPS:
Practical IP Security).  This document describes protocol formats and
processing for a IP layer security mechanism that combines the
encapsulation mechanism and key management.

The use of sequence numbers in the protocol to provide replay protection
was discussed.  Large sequence numbers could provide good protection
from replay using a sliding window approach for validation.  No
reliability (re-transmission) would be provided by this security
mechanism.

A suggestion to the use of compression techniques with IPSP was made
during the course of the discussions.  Network layer encryption will
beak existing techniques that compress the TCP and IP protocol
information.  Compression could be provided as part of the IPSP
processing.  On transmission, the data would have to be compressed prior
to encryption.

Numerous individuals in the meeting indicated that they were developing
or planning to develop implementations of IPSP. An interoperability
demonstration will be scheduled for the July 1994 IETF meeting.  The
group in the room seemed to converge on the use of DES for encryption,
MD5 for confidentiality, and manual key management for the initial
interoperability tests.


Key Management

The discussion of IPSEC key management was started with a brief review
of the working groups key management charter and goals.  The group is
chartered to develop an application layer protocol and cryptographic
techniques to provide peer-entity authentication and key management for
the IPSP. The peer-to-peer authentication exchange will support public
key cryptographic techniques and negotiate options for IPSP. A rough
draft of a protocol for IP Key Management (IPKM) was posted by Dave
Solo.

Work is progressing in other working groups on the definition of
certificate structures, certification hierarchies, and certificate
distribution.  The IPSEC-defined IP Key Management (IPKM) should use as
much of the existing work as possible for support of the public key
based mechanisms.

Discussions on the relationship of IPSP to the other working groups
examined the overlap of these mechanisms.  Several members of the group
expressed strong opinions that the IPSEC Working Group should focus on
the authentication exchange and directly use work from other groups for
the distribution of certificates.  In particular, the DNS security
techniques will provide certificates that could be used by IPKM in an
authentication exchange.

It was proposed that at a minimum the IPKM should provide authentication
for IPSP based on network addresses.  DNS names, PGP identities, and PEM
identities were also proposed as possible approaches for peer-entity
authentication, but no consensus on these approaches was evident.

The IPSP authentication exchange, being separate from IPSP, should be
usable by other protocols that may need an authentication exchange.  In
this context, the group discussed how the IPKM requirements relate to
GSS-API and Kerberos.  The IPKM authentication exchange should be
compatible with the GSS-API and could serve as one of the GSS-API
methods.  Other GSS-API mechanisms, like Kerberos, could also be used to
distribute keying material for the establishment of a security
association for IPSP. John Linn and Paul Lambert volunteered to write a
short Internet-Draft on IPSEC and the GSS-API for the next meeting.

Phil Karn presented a proposal for an authentication exchange based on
the Diffie-Hellman public key algorithm.  Public key information is
first exchanged that allows the creation of a private key held only by
the two peer systems.  Using these keys to encrypt subsequent PDUs,
additional protocol exchanges authenticate the identity of the peer
systems.  This approach allows for the creation of a security
association without revealing the identities of the two peer-systems.

This exchange was nearly identical to the Diffie-Hellman exchange
documented in ISO 11577 (Network Layer Security Protocol - NLSP). Phil
suggested that the certificate formats and distribution could be
provided by PGP (Pretty Good Privacy, a specification for secure
electronic mail).  Phil introduced a concern that the processing time
required to calculate the public key algorithms would increase the
susceptibility of a system to denial of service attacks.  He suggested
that protocol exchanges could be introduced to minimize the spoofing of
network addresses in the exchange.

Charlie Perkins (IBM) presented a key distribution and authentication
system called Net/SP/KryptoKnight.  This work is available as a product
on AIX, OS/2 and GSS-API. It is exportable, Kerberos-like, and uses
symmetric key distribution and authentication.


Attendees

Garrett Alexander        [email protected]
Mark Allyn               [email protected]
Ward Bathrick            [email protected]
Kym Blair                [email protected]
Stephen Crocker          [email protected]
Cheri Dowell             [email protected]
Donald Eastlake          [email protected]
Robert Enger             [email protected]
Louis Fernandez          [email protected]
Barbara Fraser           [email protected]
Chris Gorsuch            [email protected]
Richard Graveman         [email protected]
Marc Hasson              [email protected]
Song Kwan Ho             [email protected]
Jim Hughes               [email protected]
Charlie Kaufman          [email protected]
Hiroshi Kawazoe          [email protected]
Stephen Kent             [email protected]
Paul Lambert             [email protected]
John Larson              [email protected]
Ben Levy                 [email protected]
John Linn                [email protected]
Steven Lunt              [email protected]
Piers McMahon            [email protected]
Masataka Ohta            [email protected]
Peter Phillips           [email protected]
Michael Ressler          [email protected]
Oscar Strohacker         [email protected]
Dale Walters             [email protected]
Suguru Yamaguchi         [email protected]
Dan Zerkle               [email protected]

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.