home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 92jul / snmpseci-minutes-92jul.txt < prev    next >
Text File  |  1993-02-17  |  7KB  |  173 lines

  1. Editor's Note: Minutes received on 7/31
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5. Reported by Keith McCloghrie/Hughes
  6.  
  7. Minutes of the SNMP Security Implementors' BOF (SNMPSECI)
  8.  
  9. A BOF session for SNMP Security Implementors was held during the Boston
  10. IETF meeting on July 13, 1992.  The BOF's purpose was to allow
  11. implementors to share their implementation experiences.  The meeting was
  12. Chaired by Keith McCloghrie.  Jim Galvin sent his apologies for not
  13. being able to attend.
  14.  
  15. The meeting began with a review of the status of SNMP Security:
  16.  
  17.  
  18.    o RFCs 1351, 1352, 1353 have been published with Proposed Internet
  19.      Standard status,
  20.  
  21.    o The RFCs have lots of editorial changes from the Internet Drafts
  22.      which the Working Group had approved, but
  23.  
  24.    o The only change affecting implementations was the assignment of
  25.      OBJECT IDENTIFIERs under the mib-2 branch.
  26.  
  27.  
  28. After reviewing the status, the meeting was opened to questions and
  29. comments from the attendees.  An informal poll of the audience indicated
  30. that at least six implementations of secure SNMP existed.  The
  31. discussion topics included:
  32.  
  33.  
  34.    o Export issues
  35.    o Clock synchronization
  36.    o Access control granularity
  37.    o MD5/DES performance overhead
  38.    o BER encoding
  39.    o Relation to SMP
  40.    o ``Next steps'' for the RFCs.
  41.  
  42.  
  43. During the discussion of export issues, some (second-hand) information
  44. was presented on a proposal being considered by NIST for an ``improved''
  45. process for U.S. export control of cryptography.
  46.  
  47. The discussion on clock synchronization raised the issue of how SNMP
  48. Security relates to the recent SMP specification, since a change to
  49. clock synchronization is proposed by the SMP specification.  Thus, each
  50. of the changes to SNMP Security being proposed as part of SMP were
  51. presented.  In particular, in the area of clock synchronization, SMP
  52. simplifies the algorithm by including both the destination party's clock
  53. as well as the source party's clock in the authInfo structure of a
  54. message; this removes the need for a SetRequest to be issued (in the
  55. ``case 1'' scenario described in RFC 1352).  Another suggestion
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63. concerning clock synchronization was the use of automatic, ``on the
  64. fly'' synchronization of clocks whenever an application requests a
  65. message be sent to an agent which it hasn't recently communicated with.
  66.  
  67. In other discussions, the impact on performing access control on MIB
  68. views with instance-level granularity was discussed, particularly the
  69. performance aspects of it.
  70.  
  71. Performance was also discussed in regard to the overhead of MD5 and DES.
  72. Feedback from newer implementations was compared to previously known
  73. information, and was found to be within the same ballpark.  David
  74. Partain's article in the July issue of ``The Simple Times'' was
  75. mentioned as a source of more information.
  76.  
  77. One implementor indicated that differences in BER encodings by different
  78. implementation could cause problems.  The authDigest value calculated on
  79. the SnmpAuthMessage by the receiving entity has to match the authDigest
  80. value contained in the message when these values are compared during
  81. authentication processing.  In particular, ISO 8825 allows multiple
  82. valid encodings of a length field.  Thus, the receiving entity must not
  83. perform an independent BER serialization/encoding, but must use the same
  84. serialized value as it received.  Not only is this necessary but it can
  85. also be beneficial, since it allows implementors to minimize the number
  86. of times BER encodings are performed in their code.
  87.  
  88. Several attendees raised questions on the ``next steps'' for secure SNMP
  89. in light of the changes outlined in the SMP documents.  There were
  90. questions on whether the SNMP Security RFCs would be updated and when.
  91. Additionally, there were questions on whether implementors should ``hold
  92. off'' on implementing SNMP Security until the status of SMP/SNMP II was
  93. known.  Attendess were urged to participate in the SMP BOF scheduled for
  94. later in the week where these issues would be discussed.
  95.  
  96. Attendees
  97.  
  98. Steve Alexander          stevea@i88.isc.com
  99. David Arneson            arneson@ctron.com
  100. Jim Barnes               barnes@xylogics.com
  101. Andy Bierman             bierman@davidsys.com
  102. Tom Brennan
  103. David Bridgham           dab@epilogue.com
  104. Theodore Brunner         tob@thumper.bellcore.com
  105. Lida Carrier             lida@apple.com
  106. Robert Ching             natadm!rching@uunet.uu.net
  107. Chris Chiotasso          chris@artel.com
  108. Tracy Cox                tacox@sabre.bellcore.com
  109. Cathy Cunningham         cmc@microcom.com
  110. James Davin              jrd@ptt.lcs.mit.edu
  111. Michael Davison          davison@cs.utk.edu
  112. David Engel              david@ods.com
  113. Michael Erlinger         mike@lexcel.com
  114. Rob Graham               robert_graham@protools.com
  115. Pria Graves              priag@nsd.3com.com
  116.  
  117.                                    2
  118.  
  119.  
  120.  
  121.  
  122.  
  123. Jeff Hughes              jeff@col.hp.com
  124. Ronald Jacoby            rj@sgi.com
  125. Frank Kastenholz         kasten@ftp.com
  126. Nick Kawaguchi           mamster@lanai.cs.ucla.edu
  127. Mark Kepke               mak@cnd.hp.com
  128. Kenneth Key              key@cs.utk.edu
  129. Deidre Kostick           dck2@sabre.bellcore.com
  130. Hock-Koon Lim            lim@po.cwru.edu
  131. John Linn                linn@erlang.enet.dec.com
  132. Arun Mahajan             axm@proteon.com
  133. Kent Malave              kent@chang.austin.ibm.com
  134. Kim Mayton               mayton@wg.com
  135. Keith McCloghrie         kzm@hls.com
  136. Thomas McGinty           mcginty_t*corp_m@msm.cdx.mot.com
  137. John McKenna             mckenna@ralvm12.vnet.ibm.com
  138. David Minnich            dwm@fibercom.com
  139. Lynn Monsanto            monsanto@sun.com
  140. Paul Moran               Paul_Moran@3com.com
  141. Rina Nathaniel           rina!rnd!rndi@uunet.uu.net
  142. Sam Nicholson            scion@pblx.knox.tn.us
  143. Bill Norton              wbn@merit.edu
  144. Steven Onishi            sonishi@wellfleet.com
  145. Andrew Patka             apatka@wellfleet.com
  146. John Payne               jop@wang.com
  147. David Perkins            dperkins@synoptics.com
  148. Richard Ramos            ramos@mtunm.att.com
  149. Ed Reeder                EREEDER@ralvm12.vnet.ibm.com
  150. Sam Roberts              sroberts@farallon.com
  151. Dan Romascanu            dan@lannet.com
  152. Marshall Rose            mrose@dbc.mtview.ca.us
  153. Michael Sapich           sapich@conware.de
  154. Koichiro Seto            seto@hitachi-cable.co.jp
  155. Timon Sloane             peernet!timon@uunet.uu.net
  156. Einar Stefferud          stefisoc@nma.com=
  157. Mark Therieau            markt@python.eng.microcom.com
  158. Dean Throop              throop@dg-rtp.dg.com
  159. Stephen Tsun             snt@nsd.3com.com
  160. Ahmet Tuncay             atuncay@synoptics.com
  161. Dono van-Mierop          dono_van_mierop@3mail.3com.com
  162. Huyen Vu                 vi@polaris.disa.mil
  163. David Waitzman           djw@bbn.com
  164. Gerard White
  165. Steven Wong              wong@took.enet.dec.com
  166. Honda Wu                 natadm!honda@uunet.uu.net
  167. Kiho Yum                 kxy@nsd.3com.com
  168. Joseph Zur               zur@fibhaifa.com
  169.  
  170.  
  171.  
  172.                                    3
  173.