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

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.