[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPSEC Minutes - IETF28
Subject: IPSEC Minutes - IETF28
Message:
Minutes of the IP Security (IPSEC) WG
at the Twenty-Eighth IETF
(November 2,3, 1993)
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 then discussed the
key management requirements of IPSEC.
Tuesday, 2 November 93 IPSEC Meeting
Paul Lambert started with a review of the charter and WG status.
- The WG is behind schedule.
- Only I-NLSP has been submitted as an Internet Draft (ID).
- It is important to track the IPng candidates.
Since I-NLSP is the only ID 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 WG with a starting point.
Richard Thomas stated that the NLSP spec may be electronically available
soon. It is on the list of documents to be made available from ISO.
Requirements review (Jim Zmuda):
We need agreement on the requirements before we can start to evaluate
the contending proposals. Requirements were discussed in Amsterdam, but
the decisions made were not final due to the small number of
participants. Since the minutes from that meeting weren't published,
the WG as a whole did not have a chance to comment. The following
comments reflect points from the Amsterdam and Houston meetings.
The issues discussed were:
1. Encapsulation vs. IP option - encapsulation was selected
2. Limited coupling between key mgmt and IPSP - agreed; the
only coupling will be the SAID
3. Use of TLV encoded fields - rejected (speed favored over flexibility)
4. SAID implies the label to minimize the information carried per packet
(key mgmt 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).
5. Sequence numbering is an open issue.
6. 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.
7. 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.
8. An ICV will be included in IPSP.
9. 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 WG).
10. Multicast was listed as an issue but not discussed due to lack
of time.
11. No decision was reached about fragmentation & reassembly support
in IPSP.
Fragmentation was the major item addressed in the discussion, and
remains as 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.
Review of Experimental Implementations
I-NLSP - (Rob Glenn/NIST)
- NLSP is a starting point for reaching concensus within the WG
- I-NLSP is NLSP-CL along with any enhancements the WG 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
swIPe - (Phil Karn/Qualcomm)
- 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 WG probably won't 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.
KeyRing - (Rob Hagens/ANS)
- 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
TANDU/Cryptonette - Charlie Kaufman/DEC
- Target is cheap universal encryption running at LAN speeds.
- HW 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 imnplemented 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
LAN Guardian (Mike O'Dell/UUNET)
- 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 WG
expressed concerns about this because of possible TCP attacks.
Also, adding TCP would impact real-time protocols.
SP3 (Paul Lambert/Motorola)
- In the SP3 specification the SP3-D and SP3-A are the modes of most
interest to the WG. SP3-D is a version of dual-IP encapsualtion.
SP3-A provides a dual address space without the duplication of the
IP header.
Another open issue is the question of supporting multiple PDU formats as
part of the IPSP specification. 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).
Wednesday, 3 November 93 IPSEC Meeting
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 protable computer (80386 based). This
demonstration ran between Houston and Phil's home. Key management was
based on the manual entry of DES key variables.
After the demonstration the group reconviened and focused discussions on
key management requirements.
What is key management and what is the groups charter for key
management?
- A protocol and cryptographic techniques
- Application layer protocol for IPSP
- Independent of IPSP
- Initially supporting public key techniques (not patent issues!)
- Later adding Key Distribution Center (e.g., Kerberos) and/or manual
Existing work we might be able to take advantage of:
- There is nothing that directly applies, but many pieces exist
- SNDS KMP - Missing some things like algorithms and
algorithm negotiation
- IEEE 802.10C - Available in draft form, still very rough and
is based on GULS
- ISO GULS - Specifies generic envelopes, very complex, no
specific algorithms or option negotiation
- PEM - Not real-time, but does address certificates and
public keys
- X.509 - IPSEC will likely use X.509 certificate formats
- X9.17 - Private keys, now working on public keys
- SAMP - 2nd generation SDNS KMP, may be posted to net soon
- SAEP - Embedded in NLSP, network layer protocol
- Kerberos - Private keys centrally managed
- 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:
IEEE 802.10C - Peter Yee
Kerberos - John Linn
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
- Authentication Mechanism/Algorithm Negotiation - we will support
multiple algorithms
- Peer-Entity Authentication - often built into the key exchange
- Key Establishment - obtain or create a key for use by IPSP
- 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.
- 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
- Certificate Distribution - Peer-to-Peer or via a third party
- CRL List - Possibly support through SNMP
- Centralized Key Distribution - Used for shared keys/multicast.
We may defer work on this item until later.
- Access Control Attributes
Issues:
- Device name and address implications for directories and
certificates
- 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.
- How are IPSP access lists for routers distributed and
maintained?
- Can a SA change, or is a change accomplished by terminating
an old SA and establishing a new one??
- 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.
Presentations on Existing Key Management Implementations
Rob Hagens/ANS gave a presentation on KeyMan product.
- The routers have a pre-configured list of peer entities
- A Key Encryption Key is used in the current Beta release; a new
version using public/private keys is in development
- Traffic key lifetimes are dynamically specified
- Different TEKs are used in each direction; setup can be done in
two messages, but four are normally used
- All PDUs have the same format (48 bytes)
- Public keys are currently locally stored (manual distribution)
- TEK generation does not use Diffie-Hellman, so recorded traffic
could be decrypted if the private keys are ever learned
- If a router crashes, it establishes new SAs; the other routers
discard the old SA when a new setup is requested
Jim Zmuda/Hughes 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.
Many thanks to Tom Benkart who served as recording secretary for these
meetings.
------------------------------------------------------------------------
IPSEC Working Group Roster 28th IETF - November 2 and 3 1993
Garrett D. Alexander gda@tycho.ncsc.mil
Ran Atkinson atkinson@itd.nrl.navy.mil
Ali Bahreman bahreman@bellcore.com
Steve Bellovin smb@research.att.com
Tom Benkart teb@saturn.acc.com
Larry Blunk larryljb@merit.edu
Ken Carlberg carlburg@cseic.saic.com
Cheng Chen chen@accessworks.com
Richard Colella colella@nist.gov
Steve Crocker crpcker@tis.com
Waychi Doo wcd@berlioz.nsc.com
Bob Downs bob@combinet.com
Donald E. Eastlake, III dee@lkg.dec.com
Antonio Fernandez afa@bellcore.com
Rich Fox rfox@metricom.com
Dan Frommer frommer@isv.dec.com
Vince Gebes vgebes@spin.ad(i?)p
Rob Glenn glenn@osi.ncsl.nist.gov
M. J. Goh goh@mpr.ca
Chris Gorsuch chrisg@lobby.ti.com
Jisoo Greiter geiter@mitre.org
Phill Gross pgross@ans.net
Robert Hagens hagens@ans.net
Phil Karn karn@qualcomm.com
Charlie Kaufman kaufman@zk3.dec.com
Elizabeth Kaufman kaufman-elizabeth@yale.edu
Steve Kent kent@bbn.com
Ed King eek@atc.boeing.com
Michael L. Kornegay mlk@bnr.com
David Kristol dmk@research.att.com
Paul Lambert lambert@email.mot.com
John Linn linn@security.ov.com
Brian Lloyd brian@lloyd.com
Kanckei Loa loa@nddsunz.sps.mot.com
Steve Lunt lunt@bellcore.com
Gary Malkin gmalkin@xylogics.com
Glenn McGregor ietf_ipsec@lloyd.com
Mike Michnikov mbmg@mitre.org
Greg Minshall minshall@wc.novell.com
Sandra Murphy murphy@tis.com
Andrew Myles andrew@mpre.mg.edu.au
Mike O'Dell mo@uunet.uu.net
Steve Parker sparket@ossi.com
Hanning Schalzinre hgs@research.att.com
Vincent Shekher vin@sps.mot.com
Frank Solensky solenksy@ftp.net
Bill Simpson bsimpson@um.cc.umich.edu
David Solo solo@bbn.com
Jim Solomon solomon@comm.mot.com
Don Stephenson dons@eng.sun.com
Mike StJohns StJohns@arpa.mil
Richard Thomas rjthomas@bnr.com
Sue Thomson set@bellcore.com
Dean Throop throop@dg-rtp.dg.com
Jerry Toporek jt@mentat.com
Paul Traina pst@cisco.com
Ted Ts'o tytso@mit.edu
Tony Valle valle@huntsville.sparta.com
Chuck Warlick warlick@pscni.nasa.gov
David Woodgate davidw@its.csiro.au
Ruixi Yuan yuan@syl.dl.nec.com
Peter Yee yee@atlas.arc.nasa.gov
Jim Zmuda zmuda@mls.hac.com