[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPSEC Minutes - July 94
IPSEC Minutes - July 94
Minutes of the IP Security (IPSEC) WG
at the Thirtieth IETF
(July 27 and 28, 1994)
The IP Security (IPSEC) Working Group met twice during the Thirtieth IETF in
Toronto. On Wednesday July 27, the IPSEC working group met and discussed the
IP Security Protocol (IPSP). On Thursday July 28, the working group
discussed IPSEC key management and possible algorithms and embodiments of
the Internet Key Management Protocol (IKMP).
Wednesday July 27, IPSEC Working Group Meeting (IPSP)
A brief summary of the working group status, charter, goals, and related
work was presented. The IPSEC Working Group will develop a security protocol
in the network layer to provide cryptographic security services to protect
client protocols of IP (IPv4 and IPv6). The protection shall support
combinations of authentication, integrity, access control, and
confidentiality services. The IP Security Protocol (IPSP) shall be
independent of the cryptographic algorithm and support host-to-host
security, and subnet-to-subnet and host-to-subnet topologies.
Many implementations and specification of network exist. The swIPe protocol
has recently been released as a freely available software. A brief summary
of swIPe was provided by Perry Metzger. Paul Lambert gave a brief overview
of the Secure Data Network System (SDNS) protocol SP3. Many implementations
of SP3 or SP3-like devices exist, but none are freely available. Few of
these implementations interoperate (a feature?). It was noted that SP3 can't
directly protect TCP without a selector of some sort.The SP3 SAID controlled
formats inside the packets: permits I sandwich or a non-IP sandwich. The SP3
features provided a little of anything. The problems with SP3 include a
difficult to read specification, unnecessary fields in the clear header
(very minor problem), closely tied to ISO TP (makes support of TCP and other
Internet protocol slightly harder).
Rob Glenn, of NIST discussed NLSP and his recent enhanced proposals. He felt
that NLSP was not a bad place to start, but was difficult to understand,
overly complex, had an inefficient packet structure, was flexible and
extensible, but too much so. NLSP was rejected by the IPSEC working group.
Rob has documented two proposals that have evolved from his work with NLSP.
He has an implementation of I-NLSP done in BSD 4.4. kernel and has offered
to release the code.
The working group has defined a baseline approach and format for IPSP based
on the lessons learned from existing implementations. The approach is to
define a simple cryptographic encapsulation protocol that supports algorithm
independence through the use of a Security Association Identifier (SAID).
The baseline consists of a single field in the Rclear headerS - the SAID.
The SAID is pre-established and is used to determine the algorithm, key, and
protocol formats for the Rsecurity transformationS. The only information
that must be carried (besides the protected data) in the protected portion
of the PDU is a Next Protocol field.
At least two security transformations will be defined in the base
specification. Currently the group seems to favor including DES-CBC-MD5 (for
confidentiality and integrity) and Keyed-MD5 (for integrity and
authentication only). Additional transformations may include facilities for
sequence integrity (without recovery), and additional algorithms (IDEA,
triple DES, etc.).
A version number was proposed for inclusion in the first three or four bits
of the clear header of the protocol (or as the first bits of the SAID).
Steve Bellovin described authentication in IPng. Authentication is required,
encryption will not be used everywhere. Packet filters may need to filter
data encapsulated within a authentication header. SIPP defined a separate
payload type for the authentication only header.
Summary of IPSP Issues
Protocol numbers need to be assigned for IPSP. A proposal to use one of the
SIPP/IPng numbers was made and will be investigated. The relationship of
IPSP to the SIPP authentication only header needs additional investigation.
More documentation of IPSP is required (Perry Metzger has volunteered to
edit). The use of SAIDs with multicast needs to be clarified. Key management
attributes need to be defined for IPSP for use in the negotiation by key
management.
Thursday July 28, IPSEC Working Group Meeting (IKMP)
IPSEC key management is an application layer protocol that will be developed
independently of IPSP. It is coupled loosely to IPSP via the SAID. The
Internet Key Management Protocol (IKMP) is expected to handle negotiation of
cryptographic algorithms, protocol format, and protocol options. The
functional requirements for IPSP include SAID assignment, key
generation/distribution, attribute negating, terminate/delete association,
SAID maintenance, peer discovery and authentication, recovery, multiparty
associations, etc. Multiparty associations are important for multicast.
Phil Karn has been building an experimental protocol. He has introduced a
goal of eliminating ReasyS denial of service attacks. His RphoturisS system
currently uses Diffie-Hellman techniques. Other design goal is to hide as
much identity information as possible in the protocol.
Numerous key management specifications and implementations exist that could
be leveraged to help create IKMP. These include: SDNS KMP, SAMP, IEEE
802.10C, GULS (sense is that ISO specification is too ugly) PEM might
provide certificates, or perhaps pgp. DNS security work may be a good source
for certificates. SAEP is connected to NLSP but may have some good
components. Kerberos was mentioned as a key management approach, but does
not meet current requirements.
John Linn gave a presentation on the relationship of GSS/CAT API to IPSEC.
The CAT work is focusing on providing callable services to application
protocols, which use RcredentialsS to produce security contexts.
Applications shouldn't care about what mechanism is used. IKMP could be one
of these mechanisms. Implementations of variety of underlying mechanisms
exist. SOme of these existing mechanisms could also be used to establish
keys for IPSP (like kerberos).
Ashar Aziz presented SKIP - simple key management for IP. Hugo Krawczyk
presented a Secure Tunnel Establishment Protocol (see proceedings). Amir
Herzberg presented ideas on ideas on key look-ahead for key management.
Steve Bellovin discussed his personal key management requirements. He feels
that excessive options are a bad thing -- negotiation should be as simple as
possible, as minimal as possible. Note - presenters are now encouraged to
publish postscript versions of viewgraphs to the IPSEC ftp archive. Jim
Hughes (hughes@network.com) has established a ftp archive for IPSEC at
Ftp.Network.Com:IETF/IPSEC.
Summary of IKMP Issues
How does the IPSEC IKMP relate to other IETF key management related
activities? How are shared keys established (e.g. for multicast)? What name
and certificate structures should the IKMP support? Need to work quickly to
field workable solutions.
An interim IPSEC meeting for key management was proposed. This meeting will
occur before the next IETF plenary and the agenda and location will be
posted to the IPSEC mailing list.
Attendees
Jim Hughes Hughes@network.com
Rob Shirey Shirey@mitre.org
Perry Metzger Perry@gnu.ai.mit.edu
Ward Bathrick Ward@mis.hac.com
Rob Glenn Glenn@osi.ncsi.nist.gov
Lisa Carnahan LCarnahan@nist.gov
Ashar Aziz ashar.aziz@eng.sun.com
Dick Brackney Brackned@cc.ims.disa.mil
Dan Frommer danf@radmail.rad.co.il
Charlie Kaufman kaufman@zk3.dec.com
Tim Dean dean@hydra.ora.mmg.gb
Antony Martin Martn@ccint1.rsre.mod.uk
Jim Mahon mahonj@hfsi.com
Shane Davis Shane@delphi.com
David Beyer d.beyer@ieee.org
Jeffrey Weiss jaw@magna.telco.com
Stuart Starley StuartS@Apertus.com
Steve Bellovin smb@research.att.com
Jerry Freedman jfjr@mbunix.mitre.org
Mike Michnikov mbmg@mitre.org
Cynthia Martin martin@spica.disa.mil
Todd Wittbold jtw@mitre.org
Anne Bennett anne@alcor.concordia.ca
Craig Fox craig@ftp.com
Piers McMahon p.v.mcmahon@rea0802.wins.icl.6.uk
Don Stephenson dons@eng.sun.com
Steve Feldman feldman@mfsdatanet.com
Kazu Yamamoto kazu@is.aist-nara.ac.jp
Carl Smith cs@eng.sun.com
Louis A. Mamakos louie@alter.net
Carlisle Adams cadams@bnr.ca
Doug Rosenthal rosenthal@mcc.com
Craig Labovitz labovit@merit.edu
Lee Chastain lee@huachuca-jitcosi.army.mil
Doug Schrauf dhs@cccl.com
Ran Atkinson atkinson@itd.nrl.navy.mil
Mikt St. Johns StJohns@arpa.mil
Howard Weiss hsw@columbia.sparta.com
Masataka Ohen mohen@necom830.cc.fltech.ac.jp
John Flick johnf@hpmd.rose.hp.com
Marcus Leech Mleech@bnr.ca
Tom Arons arons@ece.ucdavis.edu
Steve Kent kent@bbn.com
John Lowry jlowry@bbn.com
Winston Chung wchung@vnet.ibm.com
Anish Bhimani anish@ctt.bellcore.com
Walter Wiebe wwiebe@nsf.gov
Chris Garsuch chrisg@lobby.ti.com
Amir Herzberg amir@watson.lbm.com
Hugo Krawczyk hugo@watson.ibm.com
Chris Seabrook cds@ossi.com
Shin Yoshida yoshida@sumitomo.com
Bill Owens owens@utd.rochester.edu
Richard Graveman rfg@ctt.bellcore.com
Neil Haller nmh@thumper.bellcore.com
Antonio Fernandez Afa@thumper.bellcore.com
Dale Gessey gessey_dale@bah.com
Henry Sinnreich hsinnreich@mcimail.com
David Gaon Gaond@cc.ims.disa.miz
Uri Blumenthal uri@watson.ibm.com
Cheryl Madson cmadson@wellfleet.com
David Woodgate davidw@its.csiro.au
Phil Karn karn@qualcomm.com
David Carrel carrel@cisco.com
Con Healy con@sprinthawk.com
Dragan Grebovich dragan@bnt.ca
Jerry Toporek jt@mentat.com
Antony Martin martin@ccin1.rsre.mod.uk
Tim Dean dean@hydra.dra.hmg.gb
Dan Frommer danf@radmail.rad.co.il
Phil Nesser pjnesser@rocket.com
p. Rajaram rajaram@ctt.bellcore.com
Barbara Fraser byf@cert.org
Charles Perkins perk@watson.ibm.com
David Beyer d.beyer@ieee.org
Bill Owens owens@utd.rochester.edu
Carl Muckenhirn cfm@columbia.sparta.com
Walter Cuilarte guilarte@wg.com
David Kristol dmk@research.att.com
Cyrus Chow cchow@ames.arc.nasa.gov
Mark Oliver oli@hyperk.com
James M. Galvin galvin@tis.com
Glenn Davis davis@realtime.als.ca
Richard Carlson racarlson@anl.gov
Tom Lyon pugs@mdv.com
James Carlson carlson@xylogies.com
John Hawkinson jhawk@panix.com
Steve Kent kent@bbr.com
Kenneth Kung ken@mls.hac.com
Jeff Schiller jis@mit.edu
Laurene J. Wolf wolf@instinet.com
John Linn linn@cam.ov.com
Peter Kirstein kirstein@cs.ucl.ac.uk
Michael Sam Chee mschell@bnr.ca
Richard R. Moore Moorerr@msu.edu
Dave Johnson dsj@cs.cmu.edu
Paul Lambert Paul_Lambert@email.mot.com