home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 95apr / area.security.95apr.txt < prev    next >
Text File  |  1995-05-26  |  8KB  |  220 lines
  1.  
  2. Security Area
  3.  
  4. Director:
  5.  
  6.  
  7.    o Jeff Schiller:  jis@mit.edu
  8.  
  9.  
  10. Area Summary reported by Jeff Schiller/MIT and Jim Galvin/TIS
  11.  
  12. The Security Area within the IETF is responsible for development of
  13. security oriented protocols, security review of RFCs, development of
  14. candidate policies, and review of operational security on the Internet.
  15.  
  16. The Area Director is assisted by a Directorate, an advisory entity with
  17. no standards-setting powers.  The members of the Security Directorate
  18. are as follows.
  19.  
  20.  
  21.              Jeffrey I. Schiller jis@mit.edu
  22.              Ran Atkinson        atkinson@itd.nrl.navy.mil
  23.              Steve Bellovin      smb@research.att.com
  24.              Steve Crocker       crocker@cybercash.com
  25.              Barbara Fraser      byf@cert.org
  26.              James M. Galvin     galvin@tis.com
  27.              Phil Karn           karn@qualcomm.com
  28.              Steve Kent          kent@bbn.com
  29.              John Linn           linn@ov.com
  30.              Clifford Neuman     bcn@isi.edu
  31.              Rob Shirey          shirey@mitre.org
  32.              Ted Ts'o            tytso@mit.edu
  33.  
  34.  
  35. In addition to the Directorate, the Security Area is assisted by the
  36. Security Area Advisory Group (SAAG). The SAAG is an open group that
  37. meets at least once during each IETF meeting as well as electronically
  38. via the saag@tis.com mailing list.
  39.  
  40. During the SAAG meeting, the activities of the Security Area, including
  41. the Directorate, will be reported and discussed.  In addition, the SAAG
  42. meeting will provide an opportunity for open discussion of security
  43. issues.
  44.  
  45. Included below is a summary from those working groups and birds of a
  46. feather sessions with security relevant activities to report and the
  47. Security Directorate meeting summary.  In addition, the following topics
  48. were discussed during the SAAG meeting.
  49.  
  50.  
  51.  
  52. Encapsulating Security Payload
  53.  
  54. IPv6 requires security, specifically that authentication and encryption
  55. be available at all times and that authentication be turned on by
  56. default.  This decision received considerable attention at the open IESG
  57. meeting held after this SAAG meeting.
  58.  
  59. Jeff Schiller conducted a number of straw polls to assess some measure
  60. of the community during this meeting.  In particular:
  61.  
  62.  
  63.    o Should we require ESP or recommend it?
  64.  
  65.      The overwhelming response was to require it.
  66.  
  67.    o (1) Should we require ESP and DES or (2) should we require ESP but
  68.      leave DES optional or (3) should we leave ESP optional but if you
  69.      do it use DES or (4) should we leave ESP optional and leave DES
  70.      optional?
  71.  
  72.      The overwhelming response was in favor of requiring both ESP and
  73.      DES (1); a number approximating 25% of that response was in favor
  74.      of the third option.
  75.  
  76.    o Should we allow other transformations in addition to requiring DES?
  77.  
  78.      The overwhelming response was in favor.
  79.  
  80.  
  81.  
  82. The activity of the following working groups and birds of a feather
  83. sessions was reported:
  84.  
  85.  
  86. Common Authentication Technology Working Group (CAT)
  87.  
  88. The working group charter is being revised to include scope compatible
  89. with Independent Data Unit Protection (IDUP) and with future
  90. authorization support facilities.
  91.  
  92. The following documents are eligible for the issuance of a working group
  93. last call (as indicated) in advance of their submission to the IESG for
  94. publication as Proposed Standards.
  95.  
  96.  
  97.    o The FTP Security specification has been resurrected with a new
  98.      editor, March Horowitz.  A revised specification is expected to be
  99.      available soon.
  100.  
  101.    o A revision of Version 2 of the GSS specification and C bindings
  102.      documents is expected to be available soon.
  103.  
  104.  
  105. The Simple Public Key Mechanism is considered stable at this time,
  106. pending resolution of an identified issue concerning X9.44 replay
  107. protection, and was placed in working group last call on 5 April 1995 in
  108. advance of its submission to the IESG for publication as a Proposed
  109. Standard.
  110.  
  111. RFC 1510 (Kerberos) is now eligible for advancement to Draft Standard.
  112. One issue is relevant to advancement of the document and will be
  113. resolved on the mailing list.
  114.  
  115. A presentation on Secure Socket Layer was given by NetScape.  An
  116. Internet-Draft is expected to be available soon.
  117.  
  118. Discussion continued on the other documents and activities.
  119.  
  120.  
  121.  
  122. Domain Name System Security Working Group (DNSSEC)
  123.  
  124. This working group did not meet at this IETF. Nonetheless, it was
  125. reported that a revised specification will be released shortly in
  126. parallel with an alpha implementation.  A working group last call will
  127. be issued as soon as it is released and the document will be progressed
  128. to submission to the IESG for publication as a Proposed Standard.
  129.  
  130.  
  131.  
  132. Guidelines and Recommendations for Security Incident Processing Working
  133. Group (GRIP)
  134.  
  135. Note:  GRIP is part of the Operational Requirements Area but is tracked
  136. by the SAAG and Security Area.
  137.  
  138. This new working group has drafted guidelines for security incident
  139. response teams.  A revised draft is expected to be available soon at
  140. which time a working group last call will be issued.  The document will
  141. be submitted to the IESG for publication as a Proposed Standard by the
  142. next IETF.
  143.  
  144.  
  145.  
  146. IP Security Protocol Working Group (IPSEC)
  147.  
  148. Eight Internet-Drafts were submitted for this meeting.  Five of these
  149. specifications describe the network layer cryptographic mechanisms and
  150. are in working group last call.
  151.  
  152. The working group has reached consensus on requiring the implementation
  153. of a hybrid Diffie-Hellman key exchange for the IKMP. The ``Photuris''
  154. specification will be progressed in the working group as the baseline
  155. description of this key exchange.  Additional presentations were given
  156. on possible modifications to the Photuris exchange and on a framework
  157. for the IKMP protocol signaling.
  158.  
  159.  
  160.  
  161. Privacy-Enhanced Electronic Mail Working Group (PEM)
  162.  
  163. This working group did not meet at this IETF. Nonetheless, it was
  164. reported that the latest version of the PEM/MIME integration
  165. specification (now called MIME Object Security Services (MOSS)) is
  166. waiting for the working group chair to issue a working last call [done
  167. as of the writing of this report] and to progress the document to
  168. submission to the IESG for publication as a Proposed Standard.  Upon
  169. publication of the documents this working group is expected to go
  170. dormant.  Other working groups will be created to address related
  171. issues, e.g., the Internet certification hierarchy.
  172.  
  173.  
  174. Router Requirements Working Group (RREQ)
  175.  
  176. The Router Requirements Working Group has a document ready to be
  177. submitted to the IESG for publication as a Proposed Standard.  It will
  178. include a requirement level of SHOULD for strong remote authentication.
  179. An issue to be resolved before the document advances to Draft Standard
  180. is the use of security by routing protocols.
  181.  
  182.  
  183. Web Transport Security
  184.  
  185. A web transport security working group will be formed with Charlie
  186. Kaufman as the Chair.  It will pickup where the SHTTP BOF from the last
  187. IETF meeting left off.
  188.  
  189.  
  190. Other
  191.  
  192. The Authenticated Firewall Traversal Working Group (AFT) and the S/Key
  193. One-Time Password Standardization BOF (SKEY) also met during this IETF.
  194. The latter is expected to submit a charter to become a working group by
  195. the next IETF; Neil Haller and Ran Atkinson will be co-Chairs.
  196.  
  197.  
  198.  
  199. The Security Area Directorate met on Monday afternoon for a two-hour
  200. meeting.  In addition to all of the above, the following was noted.
  201.  
  202.  
  203. Audio/Video Transport (AVT) and ONC Remote Procedure Call (ONCRPC)
  204. Working Groups
  205.  
  206. Both of these working groups have documents ready for advancement to
  207. Proposed Standards.  Allison Mankin, the Transport Area Director, has
  208. requested a security review of their documents, as follows:
  209.  
  210.     draft-ietf-avt-cellb-profile-04.txt
  211.     draft-ietf-avt-jpeg-01.txt
  212.     draft-ietf-avt-profile-04.txt
  213.     draft-ietf-avt-rtp-07.txt
  214.     draft-ietf-avt-video-packet-04.txt
  215.     draft-ietf-oncrpc-xdr-01.txt
  216.     draft-ietf-oncrpc-rpcv2-01.txt
  217.     draft-ietf-oncrpc-bind-00.txt
  218.     draft-ietf-oncrpc-auth-00.txt
  219.  
  220.