home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / INET / IETF / IPSEC / 94JUL.MIN < prev    next >
Encoding:
Text File  |  1994-08-20  |  12.9 KB  |  238 lines

  1. Editor's note:  These minutes have not been edited.
  2.  
  3. From: Paul Lambert <Paul_Lambert@poncho.phx.sectel.mot.com>
  4. Date: Wed, 10 Aug 1994 8:43:12 MST    
  5. Subject: IPSEC Minutes - July 94 
  6.  
  7.                       IPSEC Minutes - July 94
  8.                                Minutes of the IP Security (IPSEC) WG
  9.                                                at the Thirtieth IETF
  10.                                                  (July 27 and 28, 1994)
  11.  
  12. The IP Security (IPSEC) Working Group met twice during the Thirtieth IETF in
  13. Toronto. On Wednesday July 27, the IPSEC working group met and discussed the
  14. IP Security Protocol (IPSP). On Thursday July 28, the working group
  15. discussed IPSEC key management and possible algorithms and embodiments of
  16. the Internet Key Management Protocol (IKMP).
  17.  
  18. Wednesday July 27, IPSEC Working Group Meeting (IPSP)
  19.  
  20. A brief summary of the working group status, charter, goals, and related
  21. work was presented. The IPSEC Working Group will develop a security protocol
  22. in the network layer to provide cryptographic security services to protect
  23. client protocols of IP (IPv4 and IPv6). The protection shall support
  24. combinations of authentication, integrity, access control, and
  25. confidentiality services. The IP Security Protocol (IPSP) shall be
  26. independent of the cryptographic algorithm and support host-to-host
  27. security, and subnet-to-subnet and host-to-subnet topologies.
  28.  
  29. Many implementations and specification of network exist. The swIPe protocol
  30. has recently been released as a freely available software. A brief summary
  31. of swIPe was provided by Perry Metzger. Paul Lambert gave a brief overview
  32. of the Secure Data Network System (SDNS) protocol SP3. Many implementations
  33. of SP3 or SP3-like devices exist, but none are freely available. Few of
  34. these implementations interoperate (a feature?). It was noted that SP3 can't
  35. directly protect TCP without a selector of some sort.The SP3 SAID controlled
  36. formats inside the packets: permits I sandwich or a non-IP sandwich. The SP3
  37. features provided a little of anything. The problems with SP3 include a
  38. difficult to read specification, unnecessary fields in the clear header
  39. (very minor problem), closely tied to ISO TP (makes support of TCP and other
  40. Internet protocol slightly harder).
  41.  
  42. Rob Glenn, of NIST discussed NLSP and his recent enhanced proposals. He felt
  43. that NLSP was not a bad place to start, but was difficult to understand,
  44. overly complex, had an inefficient packet structure, was flexible and
  45. extensible, but too much so. NLSP was rejected by the IPSEC working group.
  46. Rob has documented two proposals that have evolved from his work with NLSP.
  47. He has an implementation of I-NLSP done in BSD 4.4. kernel and has offered
  48. to release the code.
  49.  
  50. The working group has defined a baseline approach and format for IPSP based
  51. on the lessons learned from existing implementations. The approach is to
  52. define a simple cryptographic encapsulation protocol that supports algorithm
  53. independence through the use of a Security Association Identifier (SAID).
  54. The baseline consists of a single field in the Rclear headerS - the SAID.
  55. The SAID is pre-established and is used to determine the algorithm, key, and
  56. protocol formats for the Rsecurity transformationS. The only information
  57. that must be carried (besides the protected data) in the protected portion
  58. of the PDU is a Next Protocol field.
  59.  
  60. At least two security transformations will be defined in the base
  61. specification. Currently the group seems to favor including DES-CBC-MD5 (for
  62. confidentiality and integrity) and Keyed-MD5 (for integrity and
  63. authentication only). Additional transformations may include facilities for
  64. sequence integrity (without recovery), and additional algorithms (IDEA,
  65. triple DES, etc.).
  66.  
  67. A version number was proposed for inclusion in the first three or four bits
  68. of the clear header of the protocol (or as the first bits of the SAID). 
  69.  
  70. Steve Bellovin described authentication in IPng. Authentication is required,
  71. encryption will not be used everywhere. Packet filters may need to filter
  72. data encapsulated within a authentication header. SIPP defined a separate
  73. payload type for the authentication only header.
  74.  
  75. Summary of IPSP Issues
  76.  
  77. Protocol numbers need to be assigned for IPSP. A proposal to use one of the
  78. SIPP/IPng numbers was made and will be investigated. The relationship of
  79. IPSP to the SIPP authentication only header needs additional investigation.
  80. More documentation of IPSP is required (Perry Metzger has volunteered to
  81. edit). The use of SAIDs with multicast needs to be clarified. Key management
  82. attributes need to be defined for IPSP for use in the negotiation by key
  83. management.
  84.  
  85. Thursday July 28, IPSEC Working Group Meeting (IKMP)
  86.  
  87. IPSEC key management is an application layer protocol that will be developed
  88. independently of IPSP. It is coupled loosely to IPSP via the SAID. The
  89. Internet Key Management Protocol (IKMP) is expected to handle negotiation of
  90. cryptographic algorithms, protocol format, and protocol options. The
  91. functional requirements for IPSP include SAID assignment, key
  92. generation/distribution, attribute negating, terminate/delete association,
  93. SAID maintenance, peer discovery and authentication, recovery, multiparty
  94. associations, etc. Multiparty associations are important for multicast.
  95.  
  96. Phil Karn has been building an experimental protocol. He has introduced a
  97. goal of eliminating ReasyS denial of service attacks. His RphoturisS system
  98. currently uses Diffie-Hellman techniques. Other design goal is to hide as
  99. much identity information as possible in the protocol. 
  100.  
  101. Numerous key management specifications and implementations exist that could
  102. be leveraged to help create IKMP. These include: SDNS KMP, SAMP, IEEE
  103. 802.10C, GULS (sense is that ISO specification is too ugly) PEM might
  104. provide certificates, or perhaps pgp. DNS security work may be a good source
  105. for certificates. SAEP is connected to NLSP but may have some good
  106. components. Kerberos was mentioned as a key management approach, but does
  107. not meet current requirements.
  108.  
  109. John Linn gave a presentation on the relationship of GSS/CAT API to IPSEC.
  110. The CAT work is focusing on providing callable services to application
  111. protocols, which use RcredentialsS to produce security contexts.
  112. Applications shouldn't care about what mechanism is used. IKMP could be one
  113. of these mechanisms. Implementations of variety of underlying mechanisms
  114. exist. SOme of these existing mechanisms could also be used to establish
  115. keys for IPSP (like kerberos).
  116.  
  117. Ashar Aziz presented SKIP - simple key management for IP. Hugo Krawczyk
  118. presented a Secure Tunnel Establishment Protocol (see proceedings).  Amir
  119. Herzberg presented ideas on ideas on key look-ahead for key management.
  120. Steve Bellovin discussed his personal key management requirements. He feels
  121. that excessive options are a bad thing -- negotiation should be as simple as
  122. possible, as minimal as possible. Note - presenters are now encouraged to
  123. publish postscript versions of viewgraphs to the IPSEC ftp archive. Jim
  124. Hughes (hughes@network.com) has established a ftp archive for IPSEC at
  125. Ftp.Network.Com:IETF/IPSEC.
  126.  
  127. Summary of IKMP Issues
  128.  
  129. How does the IPSEC IKMP relate to other IETF key management related
  130. activities? How are shared keys established (e.g. for multicast)? What name
  131. and certificate structures should the IKMP support? Need to work quickly to
  132. field workable solutions.
  133.  
  134. An interim IPSEC meeting for key management was proposed. This meeting will
  135. occur before the next IETF plenary and the agenda and location will be
  136. posted to the IPSEC mailing list.
  137.  
  138. Attendees
  139.  
  140. Jim Hughes                            Hughes@network.com
  141. Rob Shirey                            Shirey@mitre.org
  142. Perry Metzger                         Perry@gnu.ai.mit.edu
  143. Ward Bathrick                         Ward@mis.hac.com
  144. Rob Glenn                             Glenn@osi.ncsi.nist.gov
  145. Lisa Carnahan                         LCarnahan@nist.gov
  146. Ashar Aziz                            ashar.aziz@eng.sun.com
  147. Dick Brackney                         Brackned@cc.ims.disa.mil
  148. Dan Frommer                           danf@radmail.rad.co.il
  149. Charlie Kaufman                       kaufman@zk3.dec.com
  150. Tim Dean                              dean@hydra.ora.mmg.gb
  151. Antony Martin                         Martn@ccint1.rsre.mod.uk
  152. Jim Mahon                             mahonj@hfsi.com
  153. Shane Davis                           Shane@delphi.com
  154. David Beyer                           d.beyer@ieee.org
  155. Jeffrey Weiss                         jaw@magna.telco.com
  156. Stuart Starley                        StuartS@Apertus.com
  157. Steve Bellovin                        smb@research.att.com
  158. Jerry Freedman                        jfjr@mbunix.mitre.org
  159. Mike Michnikov                        mbmg@mitre.org
  160. Cynthia Martin                        martin@spica.disa.mil
  161. Todd Wittbold                         jtw@mitre.org
  162. Anne Bennett                          anne@alcor.concordia.ca
  163. Craig Fox                             craig@ftp.com
  164. Piers McMahon                         p.v.mcmahon@rea0802.wins.icl.6.uk
  165. Don Stephenson                        dons@eng.sun.com
  166. Steve Feldman                         feldman@mfsdatanet.com
  167. Kazu Yamamoto                         kazu@is.aist-nara.ac.jp
  168. Carl Smith                            cs@eng.sun.com
  169. Louis A. Mamakos                      louie@alter.net
  170. Carlisle Adams                        cadams@bnr.ca
  171. Doug Rosenthal                        rosenthal@mcc.com
  172. Craig Labovitz                        labovit@merit.edu
  173. Lee Chastain                          lee@huachuca-jitcosi.army.mil
  174. Doug Schrauf                          dhs@cccl.com
  175. Ran Atkinson                          atkinson@itd.nrl.navy.mil
  176. Mikt St. Johns                        StJohns@arpa.mil
  177. Howard Weiss                          hsw@columbia.sparta.com
  178. Masataka Ohen                         mohen@necom830.cc.fltech.ac.jp
  179. John Flick                            johnf@hpmd.rose.hp.com
  180. Marcus Leech                          Mleech@bnr.ca
  181. Tom Arons                             arons@ece.ucdavis.edu
  182. Steve Kent                            kent@bbn.com
  183. John Lowry                            jlowry@bbn.com
  184. Winston Chung                         wchung@vnet.ibm.com
  185. Anish Bhimani                         anish@ctt.bellcore.com
  186. Walter Wiebe                          wwiebe@nsf.gov
  187. Chris Garsuch                         chrisg@lobby.ti.com
  188. Amir Herzberg                         amir@watson.lbm.com
  189. Hugo Krawczyk                         hugo@watson.ibm.com
  190. Chris Seabrook                        cds@ossi.com
  191. Shin Yoshida                          yoshida@sumitomo.com
  192. Bill Owens                            owens@utd.rochester.edu
  193. Richard Graveman                      rfg@ctt.bellcore.com
  194. Neil Haller                           nmh@thumper.bellcore.com
  195. Antonio Fernandez                     Afa@thumper.bellcore.com
  196. Dale Gessey                           gessey_dale@bah.com
  197. Henry Sinnreich                       hsinnreich@mcimail.com
  198. David Gaon                            Gaond@cc.ims.disa.miz
  199. Uri Blumenthal                        uri@watson.ibm.com
  200. Cheryl Madson                         cmadson@wellfleet.com
  201. David Woodgate                        davidw@its.csiro.au
  202. Phil Karn                             karn@qualcomm.com
  203. David Carrel                          carrel@cisco.com
  204. Con Healy                             con@sprinthawk.com
  205. Dragan Grebovich                      dragan@bnt.ca
  206. Jerry Toporek                         jt@mentat.com
  207. Antony Martin                         martin@ccin1.rsre.mod.uk
  208. Tim Dean                              dean@hydra.dra.hmg.gb
  209. Dan Frommer                           danf@radmail.rad.co.il
  210. Phil Nesser                           pjnesser@rocket.com
  211. p. Rajaram                            rajaram@ctt.bellcore.com
  212. Barbara Fraser                        byf@cert.org
  213. Charles Perkins                       perk@watson.ibm.com
  214. David Beyer                           d.beyer@ieee.org
  215. Bill Owens                            owens@utd.rochester.edu
  216. Carl Muckenhirn                       cfm@columbia.sparta.com
  217. Walter Cuilarte                       guilarte@wg.com
  218. David Kristol                         dmk@research.att.com
  219. Cyrus Chow                            cchow@ames.arc.nasa.gov
  220. Mark Oliver                           oli@hyperk.com
  221. James M. Galvin                       galvin@tis.com
  222. Glenn Davis                           davis@realtime.als.ca
  223. Richard Carlson                       racarlson@anl.gov
  224. Tom Lyon                              pugs@mdv.com
  225. James Carlson                         carlson@xylogies.com
  226. John Hawkinson                        jhawk@panix.com
  227. Steve Kent                            kent@bbr.com
  228. Kenneth Kung                          ken@mls.hac.com
  229. Jeff Schiller                         jis@mit.edu
  230. Laurene J. Wolf                       wolf@instinet.com
  231. John Linn                             linn@cam.ov.com
  232. Peter Kirstein                        kirstein@cs.ucl.ac.uk
  233. Michael Sam Chee                      mschell@bnr.ca
  234. Richard R. Moore                      Moorerr@msu.edu
  235. Dave Johnson                          dsj@cs.cmu.edu
  236. Paul Lambert                          Paul_Lambert@email.mot.com
  237.  
  238.