CURRENT_MEETING_REPORT_
Reported by Paul Lambert/Motorola
Minutes of the Internet Protocol Security Protocol Working Group (IPSEC)
Many thanks to Tom Benkart who served as recording secretary for these
meetings.
The IPSEC Working Group met twice during the Twenty-Eighth IETF. On
Tuesday, November 2 the IPSEC working group met and discussed the IP
Security Protocol (IPSP). On Wednesday, November 3 the working group
held a demonstration of two IPSP implementations and discussed the key
management requirements of IPSEC.
Working Group Status
Paul Lambert began the meeting with a review of the charter and a
working group status report.
o The working group is behind schedule.
o Only I-NLSP has been submitted as an Internet-Draft.
o It is important to track the IPng candidates.
Since I-NLSP is the only Internet-Draft so far, it may be used as the
template for a document from the entire group. That does not mean that
its concepts would be adopted, just that it provides the working group
with a starting point.
Richard Thomas stated that the NLSP specification may be available
electronically soon. It is on the list of documents to be made
available from ISO.
IPSP Requirements Review
Agreement must be reached on the requirements before the contending
proposals can be evaluated. Requirements were discussed in Amsterdam,
but the decisions were not considered final due to the small number of
participants. Since the minutes from that meeting were not published,
the working group as a whole did not have a chance to comment. The
following comments reflect points from the Amsterdam and Houston
meetings.
o Encapsulation versus IP option - encapsulation was selected.
o Limited coupling between key management and IPSP - agreed; the only
coupling will be the SAID.
o Use of TLV encoded fields - rejected (speed favored over
flexibility).
o SAID implies the label to minimize the information carried per
packet (key management exchanges are far less frequent). The label
can also be carried as part of the protected data (i.e. normal
IPSO in protected IP header).
o Sequence numbering is an open issue.
o A flags field in the clear header is an open issue. Donald
Eastlake will post something to the mailing list stating his view
of its usage.
o A protocol field in the IPSP header is probably needed. It could
be eliminated by having the SAID imply that information also, but
there is controversy about using the SAID for this purpose.
o An ICV will be included in IPSP.
o Peek-through (to see the upper level protocol/ports) will not be
supported. Mechanisms such as mapping this information into QOS
can be used to meet the needs of firewalls (although firewalls
themselves were not universally liked in the working group).
o Multicast was listed as an issue but not discussed due to lack of
time.
o No decision was reached about fragmentation and reassembly support
in IPSP.
Fragmentation was the major item addressed and remains an open issue.
Protocols such as NFS send maximum-sized UDP datagrams, and the
encapsulation done by IPSP in ISs frequently results in additional
fragmentation. MTU Discovery can be a solution (provided the routers
account for the IPSP encapsulation in their ICMP messages), but MTU
Discovery is not commonly used today. NFS 3 runs over TCP, so this
might not be so large an issue when that version is available.
Reassembly is not required in IPSP as long as layering is maintained.
For example, in the case of IPSP between two ISs, reassembly is handled
by the normal IP processing since the added IP header specifies the
remote IS as the IP destination.
Jim Zmuda and Bill Simpson volunteered to write a requirements document
based on the discussions.
Experimental IPSP Implementation Review
o I-NLSP - Rob Glenn
- NLSP is a starting point for reaching consensus within the
working group.
- I-NLSP is NLSP-CL along with any enhancements the working group
specifies.
- Including a content length field in the protected data is
useful with random padding.
- A sample implementation is done (CLNP only), but it is not
optimized.
o swIPe - Phil Karn
- Authentication is faster than decryption, so the authentication
field is in the unprotected header and is checked first.
- Minimal header size is emphasized over good alignment of fields
since Phil's application involves low-bandwidth lines.
- With a single system sometimes being an IS and sometimes being
an ES, potential problems arise depending on where in the IP
logic IPSP is placed.
- The working group probably will not be able to agree on a
single IPSEC PDU format because of the wide range of bandwidths
being discussed.
- Sequence numbers are used to guarantee different packet
contents for seeding the CBC (essentially acting as an IV).
Future uses for the field are still up in the air.
o KeyRing - Rob Hagens
- Target application is gateway-gateway (IS-IS).
- Small window of valid sequence numbers is allowed to prevent
replay.
- Fragmentation is not an issue since it always does IP over IP
with a remote IS as the outer IP destination.
o TANDU/Cryptonette - Charlie Kaufman
- Target is cheap universal encryption running at LAN speeds.
- Hardware solution in a chip to be added to interface cards.
- No performance penalties (including extra copies).
- Stateless encryption by including the algorithm and session key
in the clear header. The session header is encrypted under the
recipient's master key. The session key field must be large (8
bytes for DES).
- Fragmentation/reassembly has been implemented in this layer for
performance reasons.
- The ICV is at the end of the packet to minimize processing
latency.
- Any fragmentation of the datagram by routers in between the
encryption systems causes a large performance penalty because
of the stateless decryption.
o LAN Guardian - Mike O'Dell
Uses UDP as part of the encapsulation mechanism because of
fragmentation and reassembly issues. In the future, it may tunnel
over TCP to facilitate CBC. Several people in the group expressed
concerns about this because of possible TCP attacks. Also, adding
TCP would impact real-time protocols.
o SP3 - Paul Lambert
In the SP3 specification the SP3-D and SP3-A are the modes of most
interest to the working group. SP3-D is a version of dual-IP
encapsulation. SP3-A provides a dual address space without the
duplication of the IP header.
The question of supporting multiple PDU formats as part of the IPSP
specification is an open issue. Arguments in favor are that different
media types will need different formats to be efficient, and that ES-ES
IPSP could do TCP-UDP over IPSP instead of IP over IP encapsulation.
Arguments opposed are that the added complexity will make IPSP more
difficult to specify and implement. One possible approach is to specify
a negotiation mechanism with defaults (like PPP).
IPSP Implementation Demonstrations
Jim Zmuda and Phil Karn gave demonstrations of their implementations.
Jim's implementation was based on the ISO 11577 specification for
Network Layer Security Protocol (NLSP) and used the NLSP specification
of a Security Exchange Protocol (SAEP) for key management. The
implementation demonstrated by Phil Karn was based on Phil's KA9Q
software running on a portable computer (80386 based). This
demonstration ran between Houston and Phil's home. Key management was
based on the manual entry of DES key variables.
Key Management
What is key management and what is the groups charter for key
management?
o A protocol and cryptographic techniques.
o Application layer protocol for IPSP.
o Independent of IPSP.
o Initially supporting public key techniques (not patent issues!).
o Later adding Key Distribution Center (e.g., Kerberos) and/or
manual.
Existing work we might be able to take advantage of:
o There is nothing that directly applies, but many pieces exist.
o SNDS KMP - Missing some things like algorithms and algorithm
negotiation.
o IEEE 802.10C - Available in draft form, still very rough and is
based on GULS.
o ISO GULS - Specifies generic envelopes, very complex, no specific
algorithms or option negotiation.
o PEM - Not real-time, but does address certificates and public keys.
o X.509 - IPSEC will likely use X.509 certificate formats.
o X9.17 - Private keys, now working on public keys.
o SAMP - 2nd generation SDNS KMP, may be posted to net soon.
o SAEP - Embedded in NLSP, network layer protocol.
o Kerberos - Private keys centrally managed.
o CATS-GSSAPI - IPSP KMP might be able to use their interface to pass
information to IPSP; also an outstanding question of whether IPSP
will meet their needs from a user perspective.
Key Management Liaisons:
o IEEE 802.10C - Peter Yee
o Kerberos - John Linn
o Others still required for ISO, and ANSI
Key Management Requirements
This meeting was the first attempt to list the requirements for a KMP.
The requirements fall into two categories - Peer-to-Peer Exchanges and
Security Management.
Peer-to-Peer Exchanges
o Authentication Mechanism/Algorithm Negotiation - we will support
multiple algorithms.
o Peer-Entity Authentication - often built into the key exchange.
o Key Establishment - obtain or create a key for use by IPSP.
o Security Association Negotiation - we need to agree on a definition
of a Security Association (SA). It's more than just keys,
especially since we are trading off simplicity in IPSP for added
context implied by the SA. The SA probably includes the algorithm,
key, label, and services.
o Termination of SA - what is a "session", what is its lifetime?
IPSEC is mixing a connectionless IPSP with a connection-oriented
SA. What are the recovery mechanisms (e.g., do "aborts" have to be
authenticated)?
Security Management
o Certificate Distribution - Peer-to-Peer or via a third party.
o CRL List - Possibly support through SNMP.
o Centralized Key Distribution - Used for shared keys/multicast. We
may defer work on this item until later.
o Access Control Attributes.
Issues
o Device name and address implications for directories and
certificates.
o Authorization List/Delegation - what hosts is an IPSP router
permitted to act as a proxy for? Is this information dynamically
discovered or statically configured? Dynamic is more flexible but
potentially adds much more complexity.
o How are IPSP access lists for routers distributed and maintained?
o Can a SA change, or is a change accomplished by terminating an old
SA and establishing a new one??
o Shared keys - used for multicast or (possibly) multiple IPSP
routers serving a site.
Existing hosts have to be able to take advantage of IPSP services in
routers without any change to the host (i.e., IPSP is transparent to
non-IPSP end systems).
Dave Solo volunteered to write a requirements document for IPSEC Key
Management.
Concern was expressed about supporting public keys first in the IPSEC
goals because of possible delays from patent issues (a lesson learned by
PEM). Having a standard API for communicating keys from the KMP entity
to IPSP would facilitate support for private/shared keys.
Existing Key Management Implementation Presentations
Rob Hagens gave a presentation on KeyMan product. Following are
attributes of the product:
o The routers have a pre-configured list of peer entities.
o A Key Encryption Key is used in the current Beta release; a new
version using public/private keys is in development.
o Traffic key lifetimes are dynamically specified.
o Different TEKs are used in each direction; setup can be done in two
messages, but four are normally used.
o All PDUs have the same format (48 bytes).
o Public keys are currently locally stored (manual distribution).
o TEK generation does not use Diffie-Hellman, so recorded traffic
could be decrypted if the private keys are ever learned.
o If a router crashes, it establishes new SAs; the other routers
discard the old SA when a new setup is requested.
Jim Zmuda gave a presentation of key management in the NetLock product.
It uses SAEP and a trusted Certification Authority on at least one of
the systems. A Diffie-Hellman exchange is used to generate a secret for
shared keys. The secret is also encrypted with the sender's private key
for authentication.
Attendees
Garrett Alexander gda@tycho.ncsc.mil
Randall Atkinson atkinson@itd.nrl.navy.mil
Alireza Bahreman bahreman@bellcore.com
Steven Bellovin smb@research.att.com
Tom Benkart teb@acc.com
Larry Blunk ljb@merit.edu
Ken Carlberg Carlberg@cseic.saic.com
Cheng Chen chen@accessworks.com
Richard Colella colella@nist.gov
Stephen Crocker crocker@tis.com
Waychi Doo wcd@berlioz.nsc.com
Robert Downs bdowns@combinet.com
Donald Eastlake dee@skidrow.lkg.dec.com
Antonio Fernandez afa@thumper.bellcore.com
Richard Fox rfox@metricom.com
Dan Frommer dan@isv.dec.com
Vincent Gebes vgebes@sys.attjens.co.jp
Jisoo Geiter geiter@mitre.org
Robert Glenn glenn@osi.ncsl.nist.gov
Mei-Jean Goh goh@mpr.ca
Chris Gorsuch chrisg@lobby.ti.com
Phillip Gross pgross@ans.net
Robert Hagens hagens@ans.net
Phil Karn karn@qualcomm.com
Charlie Kaufman kaufman@zk3.dec.com
Elizabeth Kaufman kaufman@biomded.med.yale.edu
Stephen Kent kent@bbn.com
Edwin King eek@atc.boeing.com
Michael Kornegay mlk@bir.com
David Kristol dmk@allegra.att.com
Paul Lambert paul_lambert@email.mot.com
John Linn linn@security.ov.com
Brian Lloyd brian@lloyd.com
Kanchei Loa loa@sps.mot.com
Steven Lunt lunt@bellcore.com
Gary Malkin gmalkin@xylogics.com
Glenn McGregor ghm@lloyd.com
Michael Michnikov mbmg@mitre.org
Greg Minshall minshall@wc.novell.com
Sandra Murphy murphy@tis.com
Andrew Myles andrew@mpce.mg.edu.au
Michael O'Dell mo@uunet.uu.net
Steve Parker sparker@ossi.com
Henning Schulzrinne hgs@research.att.com
Vincent Shekher vin@sps.mot.com
William Simpson Bill.Simpson@um.cc.umich.edu
Frank Solensky solensky@ftp.com
Dave Solo solo@bbn.com
James Solomon solomon@comm.mot.com
Michael St. Johns stjohns@arpa.mil
Don Stephenson don.stephenson@sun.com
Richard Thomas rjthomas@bnr.ca
Susan Thomson set@bellcore.com
Dean Throop throop@dg-rtp.dg.com
Jerry Toporek jt@mentat.com
Paul Traina pst@cisco.com
Theodore Ts'o tytso@mit.edu
Anthony Valle valle@huntsville.sparta.com
Chuck Warlick chuck.warlick@pscni.nasa.gov
David Woodgate David.Woodgate@its.csiro.au
Peter Yee yee@atlas.arc.nasa.gov
James Zmuda zmuda@mls.hac.com