home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 95jul / area.security.95jul.txt < prev    next >
Text File  |  1995-10-18  |  10KB  |  248 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.  Send a message to
  39. saag-request@tis.com to join the list.
  40.  
  41. During the SAAG meeting, the activities of the Security Area, including
  42. the Directorate, are reported and discussed.  In addition, the SAAG
  43. meeting provides an opportunity 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. Documents Approved as Proposed Standards
  53.  
  54. The IESG approved the advancement of five of the IPSEC documents to
  55. Proposed Standards.  With the advancement of these documents the IPSEC
  56. Working Group will focus on issues related to key management.
  57.  
  58. The IESG approved the advancement of the two MOSS documents to Proposed
  59. Standards.  With the advancement of these documents the PEM Working
  60. Group has completed its charter and will be closed.
  61.  
  62.  
  63. Domain Name System Security
  64.  
  65. The last revision of the enhancements for the DNS to support security
  66. has been released.  It will enter working group last call very soon; no
  67. issues are expected to be raised.  At the end of the working group last
  68. call the document will be submitted to the IESG to be considered for
  69. publication as a Proposed Standard.  An implementation of the
  70. specification is available to U.S. and Canadian sites and individuals
  71. via anonymous FTP (see ftp://ftp.tis.com/pub/DNSSEC/README for details).
  72.  
  73.  
  74. Key Management
  75.  
  76. It was noted that the Internet needs two kinds of key management:  one
  77. for short-term keys and one for long-term keys.  The expected usage of
  78. short-term keys would be on a per connection or per message basis.
  79. Long-term keys, on the other hand, would probably be used to exchanged
  80. short-term keys.
  81.  
  82. The distribution and management of long-term keys requires the existence
  83. of a global infrastructure.  There are two options for the global
  84. infrastructure today:  Secure DNS or The Directory (X.500).  It is also
  85. possible that something completely different will be needed and
  86. developed.
  87.  
  88. Key management is expected to get increasing attention in the IETF.
  89.  
  90.  
  91. Internet Security Architecture
  92.  
  93. Steve Crocker gave an abbreviated version of his presentation to the IAB
  94. the previous evening.  He posed a challenge to the community to improve
  95. the network security at IETF meetings.  The specific proposal is to have
  96. IPSEC available with manual keying, which would be enough to make a
  97. difference when compared to the current configuration.  This should be
  98. available for use in the IETF terminal room by both the
  99. terminals/workstations and laptops.  In addition, we should install a
  100. demonstration firewall that is IPSEC friendly.  The goal is to make it
  101. available at the next IETF meeting in Dallas (December 4-8, 1995).
  102.  
  103.  
  104.  
  105. The activity of the following working groups and birds of a feather
  106. sessions was reported.
  107.  
  108.  
  109. Internet Secure Payments Protocol BOF (ISPP)
  110.  
  111.  
  112. This BOF met two times with more than a dozen technology presentations.
  113. Fortunately, the various technologies are much more similar than they
  114. are different.
  115.  
  116. The consensus was that the IETF should have one or more working groups
  117. in this area.  Charters will be proposed and submitted to the Area
  118. Director for consideration.
  119.  
  120.  
  121.  
  122. Secure Socket Layer BOF (SSL)
  123.  
  124.  
  125. A consensus developed for the need for a session layer security
  126. protocol.  This was predicated on observing that IPSEC is below the
  127. transport layer and the session layer is above it, and that implementing
  128. security in the transport or network layer would require changes to
  129. operating systems.  In contrast, session layer security could be
  130. implemented and added non-invasively to existing systems, thus making
  131. security services available to a broad range of application protocols.
  132.  
  133. As a result, a working group called Session Layer Security will be
  134. proposed.  The Secure Socket Layer specification will serve as the
  135. starting point for the new working group.
  136.  
  137.  
  138.  
  139. Simple Key Management for IP BOF (SKIP)
  140.  
  141.  
  142. SKIP is Sun's proposal for key management on the Internet.  It is a
  143. competitor to the Photouris specification being discussed in IPSEC. It
  144. is still undecided as to whether this specification should be discussed
  145. as part of the IPSEC Working Group or within its own working group.
  146.  
  147. Although there appeared to be consensus to move the SKIP specification
  148. onto the standards track, the authors will need to discuss the process
  149. and relationship to IPSEC with the Area Director and the chairs of the
  150. IPSEC Working Group before this can be done.
  151.  
  152. [Note:  Since the IETF meeting took place, discussions between the
  153. various parties are proceeding.  The likely outcome will be for the SKIP
  154. work to take place within the IPSEC Working Group.]
  155.  
  156.  
  157.  
  158. Authenticated Firewall Traversal Working Group (AFT)
  159.  
  160.  
  161. There are currently four implementations underway with interoperability
  162. testing expected to begin shortly.  If the testing is successful three
  163. documents will be submitted to the IESG to be considered for publication
  164. as Proposed Standards before the next IETF meeting in Dallas.
  165.  
  166.  
  167.  
  168. Common Authentication Technology Working Group (CAT)
  169.  
  170.  
  171. The CAT working group discussed topics related to active documents,
  172. including GSS-V2 (to receive another set of specific revisions at the
  173. Internet-Draft level, and then to be recommended for advancement to
  174. Proposed Standards), IDUP (where revised interface specifications and a
  175. new mechanism specification were discussed, with standards advancement
  176. to be considered at the Dallas IETF), GSS-API Negotiation (new draft
  177. discussed), Kerberos mechanism and extensions (status and comments
  178. discussed, new drafts to follow), FTP Security (to be recommended for
  179. advancement to Proposed Standard after inclusion of clarifying
  180. revisions), and a presentation of a new mechanism based on FIPS PUB JJJ
  181. cryptography.  Presentations on work in progress included GSS-API
  182. integration into World Wide Web browsers and servers, loadable GSS-API
  183. multi-mechanism support, and discussion of the use of RFC 1731 as a
  184. generic framework for integration of security tokens into text-based
  185. applications.  The group also discussed a range of candidate follow-on
  186. topic areas related to authorization, and identified a subset with
  187. apparent common value and feasibility for proposals and work by group
  188. members.
  189.  
  190.  
  191.  
  192. IP Security Protocol Working Group (IPSEC)
  193.  
  194.  
  195. The interoperability testing of the recently approved Proposed Standards
  196. was discussed.  The majority of the meeting was devoted to discussing
  197. Internet key management and the two working documents on Photouris and
  198. ISAKMP.
  199.  
  200.  
  201.  
  202. Site Security Handbook Working Group (SSH)
  203.  
  204.  
  205. Two documents are expected to be available by the first week of
  206. November, which will allow for final revisions to be proposed during the
  207. next IETF meeting in Dallas followed by advancing the documents onto the
  208. standards track as quickly as possible.
  209.  
  210.  
  211.  
  212. Web Transaction Security Working Group (WTS)
  213.  
  214. There were three short presentations on related subjects and a review of
  215. the two documents being developed by the working group.  With respect to
  216. the requirements specification, several new issues were raised at this
  217. meeting and most, but not all, were resolved.  There was consensus to
  218. resolve the remaining issues on the list and then submit the document to
  219. the IESG to be considered for publication as an Informational RFC.
  220.  
  221. Recent changes to the SHTTP document were reviewed and no objections
  222. were raised.  An outstanding issue is coordinating SHTTP with MOSS,
  223. which is dependent on the harder (and outside our scope) problem of
  224. coordinating HTTP with MIME. We remain hopeful that we will reach
  225. consensus on a document to propose to advance to Proposed Standard by
  226. the next IETF meeting Dallas.
  227.  
  228.  
  229. The Security Area Directorate met on Monday afternoon for a two hour
  230. meeting.  In addition to all of the above, the following was noted.
  231.  
  232.  
  233. Intellectual Property Rights (IPR)
  234.  
  235. The purpose of the discussion was information exchange.  Several
  236. protocols are pending in the IESG as a result of unresolved IPR issues
  237. and several protocols from the security area are about to be submitted
  238. to the IESG with unresolved IPR issues.  It is uncertain exactly what
  239. the outcome will be of any specific case.
  240.  
  241.  
  242. Key-ed MD5
  243.  
  244. Key-ed MD5 is being used in a variety of protocols for authentication.
  245. The IETF needs an applicability statement which includes advice on how
  246. often to change the secrets.
  247.  
  248.