home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 93mar / area.security.93mar.txt < prev    next >
Encoding:
Text File  |  1993-05-19  |  9.0 KB  |  262 lines
  1.  
  2. Security Area
  3.  
  4. Director(s):
  5.  
  6.  
  7.    o Steve Crocker:  crocker@tis.com
  8.  
  9.  
  10. Area Summary reported by Steve Crocker/TIS 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. Much of the work of the Security Area is performed in coordination with
  17. working groups in other areas.  The Security Area Advisory Group (SAAG)
  18. is a group of security experts which provides both consulting help to
  19. other areas and direct management of working groups within the security
  20. area.
  21.  
  22. The main bulk of the work for the SAAG consists of a set of formal work
  23. items.  These work items correspond to working groups within the IETF
  24. Security Area, security relevant developments within working groups in
  25. areas other than security, and internal SAAG work items which do not
  26. merit the creation of formal working groups but which do need some level
  27. of attention.
  28.  
  29. Below is the status of each of the Working Groups and/or BOFs officially
  30. chartered or initiated within the Security Area.  Immediately following
  31. those reports is an update on other security issues as well as security
  32. related work in other IETF areas.
  33.  
  34. Authorization and Access Control BOF (AAC)
  35.  
  36. A Charter has been submitted to the IESG. Its official ratification is
  37. waiting for a statement indicating its relationship to other security
  38. related activities in the IETF.
  39.  
  40. The Authorization and Access Control BOF met on Wednesday afternoon.
  41. Common characteristics of several distributed authorization mechanisms
  42. were discussed.  The Group will compile a common list of restrictions
  43. and/or privilege attributes sufficient to support DCE, ECMA/Sesame, and
  44. restricted proxies, as well as the needs of applications.  The
  45. specification for an authorization API was refined with the form of
  46. several arguments defined, and others sketched.  Work items were
  47. assigned to further refine these definitions and to specify the form of
  48. access control list entries themselves.
  49.  
  50. Common Internet Protocol Security Option Working Group (CIPSO)
  51.  
  52. The CIPSO Working Group meets principally under the auspices of the
  53. Trusted Systems Interoperability Group.  A revised Internet-Draft was
  54.  
  55.                                    1
  56.  
  57.  
  58.  
  59.  
  60.  
  61. posted for discussion at the Columbus IETF meeting.  A few changes were
  62. discussed, that were primarily structural with some additions to provide
  63. more detail.
  64.  
  65. The majority of the Working Group believes its work is done.  Steve
  66. Crocker will coordinate a team of experts to review the current
  67. specification prior to its submission to the IESG for publication as a
  68. Proposed Standard.
  69.  
  70. Common Authentication Technology Working Group (CAT)
  71.  
  72. The GSS-API base specification, GSS-API C Language Bindings, and
  73. Kerberos Version 5 documents are to be submitted for consideration as
  74. Proposed Standards.
  75.  
  76. The DASS document is to be submitted for consideration as an
  77. Experimental Protocol.
  78.  
  79. The CAT Working Group met for two sessions at the Columbus IETF. The
  80. primary agenda item was integration of security features into FTP, a
  81. topic for which Sam Sjogren is acting as task leader and on which Steve
  82. Lunt has generated a working document shortly to be released as an
  83. Internet-Draft.  The FTP security discussions were quite fruitful, both
  84. in terms of providing feedback for improving the draft proposal for FTP
  85. as well as fine tuning the GSS-API requirements and specifications.
  86.  
  87. Internet Protocol Security Protocol Working Group (IPSEC)
  88.  
  89. A Charter has been submitted to the IESG. Its official ratification is
  90. waiting for a statement indicating its relationship to other security
  91. related activities in the IETF.
  92.  
  93. A review of initial experimental implementations was conducted.  A
  94. preliminary list of IPSEC protocol features/requirements was discussed
  95. and will be posted to the mailing list.  There was a brief discussion of
  96. key management issues but it was deferred to be conducted on the mailing
  97. list.
  98.  
  99. Privacy Enhanced Mail Working Group (PEM)
  100.  
  101. The PEM specifications have been published as RFCs 1421, 1422, 1423, and
  102. 1424.  This work item was officially closed at the Columbus IETF
  103. meeting.
  104.  
  105. SNMP Security Working Group (SNMPSEC)
  106.  
  107. In conjunction with the SNMPv2 Working Group, twelve documents have been
  108. completed and adopted by the IESG as Proposed Standards.  They are
  109. currently in the hands of the RFC editor for processing for publication.
  110.  
  111. By agreement with the new Network Management Area Director, Marshall
  112.  
  113.                                    2
  114.  
  115.  
  116.  
  117.  
  118.  
  119. Rose, further work on SNMP security will be carried within the existing
  120. SNMP Working Group with assistance provided by the Security Area.
  121.  
  122. TCP Client Identity Protocol Working Group (IDENT)
  123.  
  124. The protocol specification has been published in RFC 1413 as a Proposed
  125. Standard.  A network management MIB document was published in parallel
  126. as RFC1414.  Using this MIB, a SNMP client can ascertain the same
  127. information that an Indent client can, thereby giving clients two
  128. options for implementing this service.
  129.  
  130. This work item was officially closed at the Columbus IETF meeting.
  131.  
  132. OSI Directory Services Working Group (OSIDS) - Applications
  133.  
  134. There is no security activity in this area at this time.  This work item
  135. was officially closed at the Columbus IETF meeting.
  136.  
  137. TELNET Working Group (TELNET) - Applications
  138.  
  139. A document specifying a combination authentication-encryption option was
  140. discussed, including replacing the individual option documents with this
  141. one document.  A revised Internet-Draft will be posted.
  142.  
  143. A Kerberos version 5 sub-option document was also discussed.  A revised
  144. Internet-Draft will be posted.
  145.  
  146. Router Requirements Working Group (RREQ) - Internet
  147.  
  148. The previous single document has been split into four documents and a
  149. number auxiliary documents.  Philip Almquist has responsibility for
  150. finishing the documents and submitting them to the IESG for publication.
  151.  
  152. Mobile IP Security Working Group (MOBILEIP) - Routing
  153.  
  154. If there existed an IP security option Mobile IP would not have to
  155. create its own.  This raises the question of what the relationship
  156. between this security work item and the IP security work item is.  This
  157. will be addressed in a document to be posted to internet-drafts.
  158.  
  159. Audio/Video Transport Working Group (AVT) - Transport
  160.  
  161. This activity will be reviewed to identify the security issues for the
  162. Amsterdam meeting.
  163.  
  164. Domain Name System Working Group (DNS) - Transport
  165.  
  166. A subcommittee will be created to deal with security issues.  A mailing
  167. list will be created for use by the subcommittee.
  168.  
  169.  
  170.                                    3
  171.  
  172.  
  173.  
  174.  
  175.  
  176. Trusted Network File System Working Group (TNFS) - Transport
  177.  
  178. The TNFS Working Group meets principally under the auspices of the
  179. Trusted Systems Interoperability Group.
  180.  
  181. No progress to report.
  182.  
  183. Integrated Directory Services Working Group (IDS) - User Services
  184.  
  185. This activity will be reviewed to identify the security issues for the
  186. Amsterdam meeting.
  187.  
  188. Export Control Issues
  189.  
  190. Vint Cerf and Steve Crocker need to press forward on drafting a
  191. document.
  192.  
  193. IP: The Next Generation
  194.  
  195. A plan for processing a security review of the competing next generation
  196. proposals will be drafted for the Amsterdam meeting.
  197.  
  198. ITAR Publication
  199.  
  200. An on-line version of the U.S. International Traffic in Arms Regulations
  201. (ITAR) will be created.  In addition, it was noted that the ISSA
  202. published a summary of U.S. export law that would be useful to include.
  203.  
  204. Key Management Strategies
  205.  
  206. A review of key management strategies and activities will be drafted for
  207. the Amsterdam meeting.
  208.  
  209. Network Database Privacy
  210.  
  211. There is no activity in this area.  This work item was officially closed
  212. at the Columbus IETF meeting.
  213.  
  214. PEM and MIME Integration
  215.  
  216. The meeting began with discussions of implementation status' and
  217. deployment strategies.  There will soon be PEM implementations available
  218. in the UK and Germany as a result of work under the EC PASSPORT program.
  219. Interoperability testing is in progress.  In support of the Internet
  220. certification hierarchy RSADSI and TIS announced the availability of
  221. PCAs.
  222.  
  223. In addition to the PEM and MIME integration, the use of email addresses
  224. in distinguished names and the relaxation of the trust model for the
  225.  
  226.  
  227.                                    4
  228.  
  229.  
  230.  
  231.  
  232.  
  233. current hierarchy were discussed, but no consensus was reached.  The PEM
  234. and MIME integration was also not settled since there was a fair amount
  235. of disagreement about the issues.  A revised Internet-Draft will be
  236. posted.
  237.  
  238. Random Number Generation Issues
  239.  
  240. A document has been posted as an Internet-Draft that identifies the
  241. issues to be concerned about when generating random numbers.  However,
  242. the document does not have a conclusion on how to generate random
  243. numbers given a set of requirements.  A revision will be prepared.
  244.  
  245. Routing Security Plan
  246.  
  247. Radia Perlman will submit a brief white paper identifying the issues.
  248.  
  249. Security Area Architecture
  250.  
  251. A short description of the relationship between the IETF security
  252. activities will be drafted for the Amsterdam meeting.
  253.  
  254. Working Group Liaison Checklist
  255.  
  256. A checklist for use by security liaisons to working groups that will
  257. assist in tracking progress will be drafted for the Amsterdam IETF.
  258.  
  259.  
  260.  
  261.                                    5
  262.