home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 94jul / ipsec-minutes-94jul.txt < prev    next >
Text File  |  1995-03-01  |  7KB  |  143 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Paul Lambert/Motorola
  5.  
  6. Minutes of the Internet Protocol Security Protocol Working Group (IPSEC)
  7.  
  8. The IP Security (IPSEC) Working Group met twice during the IETF in
  9. Toronto.  On Wednesday the IPSEC Working Group met and discussed the IP
  10. Security Protocol (IPSP). On Thursday the working group discussed IPSEC
  11. key management and possible algorithms and embodiments of the Internet
  12. Key Management Protocol (IKMP).
  13.  
  14.  
  15. Wednesday - IPSP
  16.  
  17. A brief summary of the working group status, charter, goals, and related
  18. work was presented.  The IPSEC Working Group will develop a security
  19. protocol in the network layer to provide cryptographic security services
  20. to protect client protocols of IP (IPv4 and IPv6).  The protection shall
  21. support combinations of authentication, integrity, access control, and
  22. confidentiality services.  The IP Security Protocol (IPSP) shall be
  23. independent of the cryptographic algorithm and support host-to-host
  24. security, and subnet-to-subnet and host-to-subnet topologies.
  25.  
  26. Many implementations and specification of network exist.  The swIPe
  27. protocol has recently been released as a freely available software.  A
  28. brief summary of swIPe was provided by Perry Metzger.  Paul Lambert gave
  29. a brief overview of the Secure Data Network System (SDNS) protocol SP3.
  30. Many implementations of SP3 or SP3-like devices exist, but none are
  31. freely available.  Few of these implementations interoperate (a
  32. feature?).  It was noted that SP3 cannot directly protect TCP without a
  33. selector of some sort.  The SP3 SAID controlled formats inside the
  34. packets:  permits IP sandwich or a non-IP sandwich.  The SP3 features
  35. provided a little of everything.  The problems with SP3 include a
  36. difficult to read specification, unnecessary fields in the clear header
  37. (very minor problem), and closely tied to ISO TP (makes support of TCP
  38. and other Internet protocol slightly harder).
  39.  
  40. Rob Glenn, of NIST discussed NLSP and his recent enhanced proposals.  He
  41. felt that NLSP was not a bad place to start, but was difficult to
  42. understand, overly complex, had an inefficient packet structure, was
  43. flexible and extensible, but too much so.  NLSP was rejected by the
  44. IPSEC Working Group.  Rob has documented two proposals that have evolved
  45. from his work with NLSP. He has an implementation of I-NLSP done in the
  46. BSD 4.4.  kernel and has offered to release the code.
  47.  
  48. The working group has defined a baseline approach and format for IPSP
  49. based on the lessons learned from existing implementations.  The
  50. approach is to define a simple cryptographic encapsulation protocol that
  51. supports algorithm independence through the use of a Security
  52. Association Identifier (SAID). The baseline consists of a single field
  53. in the Rclear headerS - the SAID. The SAID is pre-established and is
  54. used to determine the algorithm, key, and protocol formats for the
  55. Rsecurity transformationS. The only information that must be carried
  56. (besides the protected data) in the protected portion of the PDU is a
  57. ``next protocol'' field.
  58.  
  59. At least two security transformations will be defined in the base
  60. specification.  Currently the group seems to favor including DES-CBC-MD5
  61. (for confidentiality and integrity) and Keyed-MD5 (for integrity and
  62. authentication only).  Additional transformations may include facilities
  63. for sequence integrity (without recovery), and additional algorithms
  64. (IDEA, triple DES, etc.).
  65.  
  66. A version number was proposed for inclusion in the first three or four
  67. bits of the clear header of the protocol (or as the first bits of the
  68. SAID).
  69.  
  70. Steve Bellovin described authentication in IPng.  Authentication is
  71. required, encryption will not be used everywhere.  Packet filters may
  72. need to filter data encapsulated within an authentication header.  SIPP
  73. defined a separate payload type for the authentication-only header.
  74.  
  75.  
  76. Summary of IPSP Issues
  77.  
  78. Protocol numbers need to be assigned for IPSP. A proposal to use one of
  79. the SIPP/IPng numbers was made and will be investigated.  The
  80. relationship of IPSP to the SIPP authentication only header needs
  81. additional investigation.  More documentation of IPSP is required (Perry
  82. Metzger has volunteered to edit).  The use of SAIDs with multicast needs
  83. to be clarified.  Key management attributes need to be defined for IPSP
  84. for use in the negotiation by key management.
  85.  
  86.  
  87. Thursday - IKMP
  88.  
  89. IPSEC key management is an application layer protocol that will be
  90. developed independently of IPSP. It is coupled loosely to IPSP via the
  91. SAID. The Internet Key Management Protocol (IKMP) is expected to handle
  92. negotiation of cryptographic algorithms, protocol format and protocol
  93. options.  The functional requirements for IPSP include SAID assignment,
  94. key generation/distribution, attribute negating, terminate/delete
  95. association, SAID maintenance, peer discovery and authentication,
  96. recovery, multiparty associations, etc.  Multiparty associations are
  97. important for multicast.
  98.  
  99. Phil Karn has been building an experimental protocol.  He has introduced
  100. a goal of eliminating ReasyS denial of service attacks.  His RphoturisS
  101. system currently uses Diffie-Hellman techniques.  Other design goal is
  102. to hide as much identity information as possible in the protocol.
  103.  
  104. Numerous key management specifications and implementations exist that
  105. could be leveraged to help create IKMP. These include SDNS KMP, SAMP,
  106. IEEE 802.10C, GULS (sense is that ISO specification is too ugly) PEM
  107. might provide certificates, or perhaps PGP. DNS security work may be a
  108. good source for certificates.  SAEP is connected to NLSP but may have
  109. some good components.  Kerberos was mentioned as a key management
  110. approach, but does not meet current requirements.
  111.  
  112. John Linn gave a presentation on the relationship of GSS/CAT API to
  113. IPSEC. The CAT work is focusing on providing callable services to
  114. application protocols, which use RcredentialsS to produce security
  115. contexts.  Applications should not care about what mechanism is used.
  116. IKMP could be one of these mechanisms.  Implementations of variety of
  117. underlying mechanisms exist.  Some of these existing mechanisms could
  118. also be used to establish keys for IPSP (like Kerberos).
  119.  
  120. Ashar Aziz presented SKIP - simple key management for IP. Hugo Krawczyk
  121. presented a Secure Tunnel Establishment Protocol.  Amir Herzberg
  122. presented ideas on key look-ahead for key management.  Steve Bellovin
  123. discussed his personal key management requirements.  He feels that
  124. excessive options are a bad thing---negotiation should be as simple as
  125. possible, as minimal as possible.
  126.  
  127. Presenters are encouraged to publish PostScript versions of their
  128. viewgraphs to the IPSEC FTP archive.  Jim Hughes has established an FTP
  129. archive for IPSEC at ftp.network.com:IETF/IPSEC.
  130.  
  131.  
  132. Summary of IKMP Issues
  133.  
  134. How does the IPSEC IKMP relate to other IETF key management related
  135. activities?  How are shared keys established (e.g., for multicast)?
  136. What name and certificate structures should the IKMP support?  Need to
  137. work quickly to field workable solutions.
  138.  
  139. An interim IPSEC meeting for key management was proposed.  This meeting
  140. will occur before the next IETF plenary and the agenda and location will
  141. be posted to the IPSEC mailing list.
  142.  
  143.