Internet Standards/CD1.mdf/INET/IETF/IPSEC/93NOV.MIN

Text File | 1994-02-08 | 15.4 KB | 451 lines

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        [e-mail]
Randall Atkinson         [e-mail]
Alireza Bahreman         [e-mail]
Steven Bellovin          [e-mail]
Tom Benkart              [e-mail]
Larry Blunk              [e-mail]
Ken Carlberg             [e-mail]
Cheng Chen               [e-mail]
Richard Colella          [e-mail]
Stephen Crocker          [e-mail]
Waychi Doo               [e-mail]
Robert Downs             [e-mail]
Donald Eastlake          [e-mail]
Antonio Fernandez        [e-mail]
Richard Fox              [e-mail]
Dan Frommer              [e-mail]
Vincent Gebes            [e-mail]
Jisoo Geiter             [e-mail]
Robert Glenn             [e-mail]
Mei-Jean Goh             [e-mail]
Chris Gorsuch            [e-mail]
Phillip Gross            [e-mail]
Robert Hagens            [e-mail]
Phil Karn                [e-mail]
Charlie Kaufman          [e-mail]
Elizabeth Kaufman        [e-mail]
Stephen Kent             [e-mail]
Edwin King               [e-mail]
Michael Kornegay         [e-mail]
David Kristol            [e-mail]
Paul Lambert             [e-mail]
John Linn                [e-mail]
Brian Lloyd              [e-mail]
Kanchei Loa              [e-mail]
Steven Lunt              [e-mail]
Gary Malkin              [e-mail]
Glenn McGregor           [e-mail]
Michael Michnikov        [e-mail]
Greg Minshall            [e-mail]
Sandra Murphy            [e-mail]
Andrew Myles             [e-mail]
Michael O'Dell           [e-mail]
Steve Parker             [e-mail]
Henning Schulzrinne      [e-mail]
Vincent Shekher          [e-mail]
William Simpson          [e-mail]
Frank Solensky           [e-mail]
Dave Solo                [e-mail]
James Solomon            [e-mail]
Michael St.  Johns       [e-mail]
Don Stephenson           [e-mail]
Richard Thomas           [e-mail]
Susan Thomson            [e-mail]
Dean Throop              [e-mail]
Jerry Toporek            [e-mail]
Paul Traina              [e-mail]
Theodore Ts'o            [e-mail]
Anthony Valle            [e-mail]
Chuck Warlick            [e-mail]
David Woodgate           [e-mail]
Peter Yee                [e-mail]
James Zmuda              [e-mail]