home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 94dec / area.security.94dec.txt < prev    next >
Text File  |  1995-02-28  |  7KB  |  196 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@tis.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 Security Area Advisory Group (SAAG) meeting, the activities
  41. of the Security Area, including the Directorate, will be reported and
  42. discussed.  In addition, the SAAG meeting will provide an opportunity
  43. for open discussion of security 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. New Call for Action
  53.  
  54. Jeff Schiller reported that the Router Requirements Working Group has
  55. been resurrected.  The version of the document that has been languishing
  56. for years has been published and designated Historical.  Fred Baker has
  57. volunteered to edit a new version of the document which has been posted
  58. and is currently being discussed.
  59.  
  60. Volunteers are needed to give the document a security review.  It was
  61. noted that the document is just over 200 pages, so its review would
  62. require a serious commitment by one or more people.  Interested
  63. individuals are asked to contact Jeff Schiller directly.
  64.  
  65.  
  66. Telnet Encryption Option
  67.  
  68. At the last IETF, it was agreed that a document should be produced
  69. specifying the existing practice.  However a serious vulnerability has
  70. surfaced in the existing practice.  A better version of the protocol is
  71. needed.
  72.  
  73. The Security Area Director will work with the Applications Area Director
  74. to create a design team and/or working group to tightly focus on getting
  75. a better version of the Telnet Encryption Option documented.
  76.  
  77.  
  78. Key Management
  79.  
  80. At the last IETF, it had been agreed that a key management working group
  81. would be created.  However, since that time, the IPSEC Working Group has
  82. a proposal for a session key establishment protocol.  Therefore this
  83. action item has been overtaken by events.
  84.  
  85. On a more specific topic, key generation is a hard problem.  It is
  86. easier than most people realize to have poorly chosen keys.  As a topic
  87. for further discussion, Jeff Schiller suggested that perhaps the
  88. security area should consider favoring protocols that generate keys on
  89. key distribution centers.
  90.  
  91.  
  92. Other
  93.  
  94. Jeff Schiller closed the meeting by asking for opinions about the IETF
  95. meeting structure, e.g., meeting at night and whether technical
  96. presentations should be continued or reduced.  He also gave a brief
  97. overview of the IETF/IESG process and reminded everyone about the IETF
  98. Web Pages -- http://www.ietf.cnri.reston.va.us -- which include pointers
  99. to all working groups, RFCs, Internet-Drafts, charters, mailing lists
  100. and mailing list archives.
  101.  
  102.  
  103.  
  104. The activity of the following working groups and birds of a feather
  105. sessions was reported.
  106.  
  107.  
  108. HyperText Transfer Protocol Security BOF (HTTPSEC)
  109.  
  110. The purpose of the BOF was to discuss providing security services for
  111. the HTTP/WWW suite.  It began with a presentation of Secure HTTP. The
  112. consensus was to charter a working group to continue the work.  The
  113. group drafted a charter and used its remaining time to discuss
  114. requirements.
  115.  
  116.  
  117. Object/Document Security BOF (IOS)
  118.  
  119. The purpose of the BOF was to discuss adding security to documents and
  120. ``static'' objects.  Several alternative technologies were presented.
  121. The consensus was to create a working group to continue the work.  A
  122. charter will be drafted and a discussion of requirements will continue
  123. on a mailing list to be created.
  124.  
  125.  
  126. Authenticated Firewall Traversal Working Group (AFT)
  127.  
  128. This newly chartered working group met for the first time at this IETF.
  129. Its principal task is to standardize SOCKS. At this meeting, extensions
  130. to support UDP and authentication were discussed, including whether AFT
  131. or IPSEC should provide this technology.  No conclusion has been reached
  132. yet.
  133.  
  134.  
  135. Common Authentication Technology Working Group (CAT)
  136.  
  137. The CAT Working Group discussed issues related to the following
  138. Internet-Drafts:  Kerberos One-Time Passwords, Simple Public-Key
  139. Mechanisms (SPKM), draft update to RFC 1508, Windows GSS-API bindings,
  140. Interoperable Object Protection (IOP), FTP Security, and multiple
  141. overlay proposals for interfaces to layer atop GSS-API. Revised
  142. Internet-Drafts are expected for many of these documents before the next
  143. IETF. In particular, a revised FTP authentication specification is
  144. expect to be submitted for publication as a Proposed Standard by the
  145. next IETF. Also, depending on implementation experience, a version of
  146. the SPKM draft may also be submitted for advancement.
  147.  
  148.  
  149. Domain Name System Security Working Group (DNSSEC)
  150.  
  151. Consensus was reached that the working group should proceed with the
  152. Eastlake/Kaufman proposal.  Some issues were discussed and a revised
  153. specification is expected shortly.  Depending on implementation
  154. experience, the proposal may be submitted for publication as a Proposed
  155. Standard prior to the next IETF.
  156.  
  157.  
  158. IP Security Working Group (IPSEC)
  159.  
  160. Significant progress was made during this IETF: there appears to be
  161. rough consensus on the IPSP protocol.
  162.  
  163. There were several key management alternatives presented but all
  164. participants are willing to work together to arrive at a consensus
  165. proposal that meets the requirements of the working group.  In addition,
  166. we believe that all known patent issues have been resolved.  The mailing
  167. list will be used to continue the discussion of the requirements and how
  168. the proposals address them.
  169.  
  170.  
  171. Privacy Enhanced Mail Working Group (PEM)
  172.  
  173. The consensus of the working group was to submit the MIME-PEM
  174. integration documents for publication as Proposed Standards.  A Last
  175. Call will be issued on the mailing list to allow folks not in attendance
  176. to comment.
  177.  
  178.  
  179. The Security Area Directorate met on Monday afternoon for a 2 hour
  180. meeting.  The following actions were adopted.
  181.  
  182.  
  183. Keyed MD5
  184.  
  185. Ran Atkinson reported on a vulnerability in using keyed MD5 that had
  186. been brought to his attention.  Since several protocols are considering
  187. using keyed MD5 -- SNMPv2 already does -- Jim Galvin volunteered to
  188. document the issues in an Informational RFC.
  189.  
  190.  
  191. Randomness Document
  192.  
  193. A revised document discussing randomness issues has been prepared and
  194. will soon be published as an Informational RFC.
  195.  
  196.