home *** CD-ROM | disk | FTP | other *** search
- Editor's note: These minutes have not been edited.
-
- From: Paul Lambert <Paul_Lambert@poncho.phx.sectel.mot.com>
- Date: Wed, 10 Aug 1994 8:43:12 MST
- Subject: 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
-
-