home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / cat / cat-minutes-93mar.txt < prev    next >
Text File  |  1993-05-10  |  9KB  |  209 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by John Linn/Geer Zolot Associates and Sam Sjogren/TGV
  6.  
  7. Minutes of the Common Authentication Technology Working Group (CAT)
  8.  
  9. The Common Authentication Technology Working Group (CAT) met for two
  10. sessions at the Columbus IETF. The primary Agenda item was integration
  11. of security features into FTP, a topic for which Sam Sjogren is acting
  12. as task leader and on which Steve Lunt has generated a working document
  13. which will shortly be released as an Internet-Draft.  Additional
  14. discussion topics were the advancement status of currently active CAT
  15. Internet-Drafts (GSS-API, GSS-API C bindings, and Kerberos V5), and a
  16. working proposal by Ted Ts'o for a CATS stream-oriented protocol overlay
  17. to be used in conjunction with GSS-API.
  18.  
  19. Status Of Specifications
  20.  
  21. The CAT Internet-Drafts have been pending administrative action for some
  22. time, and an action plan was evolved for their advancement
  23. recommendation.  An updated Kerberos V5 specification was produced by
  24. Cliff Neuman; comments received from its review list by April 10th will
  25. be reflected in an Internet-Draft to be issued by April 17th.  Primary
  26. late-breaking changes include added detail on an encrypted timestamp
  27. preauthentication type, and a new message type for credential exchange
  28. when proxies are being provided to an end server.
  29.  
  30. Concurrently with the Kerberos specification review, an advancement memo
  31. will be prepared for the set of Internet-Drafts (GSS-API, GSS-API C
  32. bindings, Kerberos V5).  Intended follow-on documents will include a CAT
  33. mechanism definition (with token format) based on Kerberos V5.  It was
  34. determined that use of the mechanism tagging recommended in GSS-API
  35. Appendix B should be adopted as mandatory, and message stream facilities
  36. were strongly desired within GSS-API mechanisms in order to satisfy FTP
  37. functional and integration requirements; a new appendix to the GSS-API
  38. specification has been drafted and distributed to the CAT mailing list
  39. codifying the results of this discussion.
  40.  
  41. CATS Stream Protocol
  42.  
  43. The CATS proposal, presented by Ted Ts'o, was engendered by a desire to
  44. provide prospective protocol integrators with a subprotocol
  45. specification for security, along with a stream-oriented API. An
  46. explicit CATS goal is that it be implementable quickly and without
  47. kernel modifications (unlike, e.g., IP- level security).  CATS presents
  48. an alternative, generic form for protocol integration, contrasting with
  49. the protocol-specific integration being employed in Telnet options and
  50. FTP commands.  Submission of a revised CATS specification as an
  51. Internet-Draft is planned.
  52.  
  53. In evolving CATS, Ted observed that the status of the tagging scheme in
  54. GSS- API Appendix B as a recommendation to mechanism designers led to
  55.  
  56.                                    1
  57.  
  58.  
  59.  
  60.  
  61.  
  62. undesirable ambiguity, and suggested making it mandatory; this
  63. suggestion was adopted and would be integrated into the Kerberos V5
  64. implementation.  Among other discussion, it was suggested that the CATS
  65. protocol be extended in order to exchange preamble tokens in advance of
  66. context establishment for mechanism type negotiation, and this prospect
  67. will be examined.
  68.  
  69. FTP Security
  70.  
  71. Sam Sjogren began the FTP part of the meeting by describing the goals
  72. for the FTP security work, as initiated at a BOF during the previous
  73. IETF and to be continued under the CAT Working Group framework.  Support
  74. for authentication, as well as integrity verification and privacy, via
  75. any of a number of different mechanisms will be provided by this work.
  76.  
  77. Steve Lunt presented his proposal for extensions to the FTP protocol
  78. (additional commands) to implement the security goals; he intends to
  79. make an FTP security implementation publicly available.  An overhead
  80. presentation supplemented the draft that had previously been posted to
  81. the Group's mailing list.  Lively discussion occurred during and after
  82. this presentation, to the point that an additional evening meeting was
  83. scheduled to continue the discussions.  The resulting FTP security
  84. discussions were quite fruitful, both in terms of providing feedback for
  85. improving the draft proposal for FTP as well as fine tuning the GSS-API
  86. requirements and specifications.  It was decided that the case of a
  87. three-party FTP interaction is sufficiently complex and rarely enough
  88. used that specification of how to do it securely will be deferred,
  89. probably to a separate document to be produced later.
  90.  
  91. Once peer entity authentication has been completed (and a session key is
  92. available), the proposed FTP security approach protects all subsequent
  93. FTP commands for at least integrity (encapsulation of base-64 encoding
  94. of gss_seal() output within MIC command), and optionally for
  95. confidentiality as well as integrity (encapsulation within ENC command,
  96. gss_seal() conf_flag TRUE). It was observed that underlying GSS-API
  97. mechanisms must represent and protect the conf_avail flag value and
  98. other service availability indicators within their tokens to prevent
  99. active attacks; the to-be-written ``Kerberos Vn for GSS-API'' and other
  100. mechanism design documents will describe how this protection is
  101. provided.  (These indicator protection requirements apply independently
  102. of whether GSS-API is employed.)  To protect against active attackers
  103. corrupting a data or control stream by changing the order of data or
  104. commands in the stream, protection via sequence numbers or some other
  105. such technique must be provided by the FTP security standard or the
  106. underlying mechanisms.
  107.  
  108. Given that the FTP control connection is a Telnet stream, questions
  109. arose about the rationale for not using the Telnet authentication option
  110. as an approach for FTP. Steve cited two reasons:  (1) because the Host
  111. Requirements RFC precludes use of Telnet options on the FTP control
  112. connection, and (2) because of a desire to provide data integrity, which
  113. Telnet security does not offer.
  114.  
  115.  
  116.                                    2
  117.  
  118.  
  119.  
  120.  
  121.  
  122. There was discussion of the fact that no facility was exposed at the
  123. level of the FTP security commands for negotiating the type and strength
  124. of cryptography to be used for data protection.  However, it was
  125. recognized that such features can exist within underlying mechanisms yet
  126. remain transparent at the level of FTP. The ordering of USER and AUTH
  127. commands will be made such that an FTP server may make a decision on
  128. what authentication and encryption mechanisms are acceptable based on
  129. who the user is.
  130.  
  131. Kerberos ticket granularity and naming issues were discussed.  For
  132. Kerberos V4, the form of a target FTP server's name should be
  133. ``ftp.<simple-host>'', and for Kerberos V5,
  134. ``ftp/<domain-qualified-host>''.  It was noted that use of different
  135. target names for different server processes within a host is not
  136. primarily an access control measure, but does permit the servers to run
  137. in different protection domains (as might be desirable for an FTP server
  138. available to casual remote users).
  139.  
  140. Areas to be revised in the FTP draft based on discussion include:
  141.  
  142.  
  143.    o Additional discussion of requirements.
  144.  
  145.    o Approach for transfer of arbitrarily long tokens from client to
  146.      server.
  147.  
  148.    o Alignment of base-64 encoding technique with RFC1421.
  149.  
  150.    o Statements regarding mechanism negotiation (including a statement
  151.      that an FTP server may refuse to accept anything less than suitably
  152.      strong authentication).
  153.  
  154.    o Further work on the data stream protection approach.
  155.  
  156.  
  157. Attendees
  158.  
  159. Steve Alexander          stevea@lachman.com
  160. John Campbell            jrcamp@nosc.mil
  161. William Chung            whchung@watson.ibm.com
  162. Stephen Crocker          crocker@tis.com
  163. Dave Cullerot            cullerot@ctron.com
  164. Antonio Fernandez        afa@thumper.bellcore.com
  165. James Galvin             galvin@tis.com
  166. Jisoo Geiter             geiter@mitre.org
  167. Richard Graveman         rfg@ctt.bellcore.com
  168. Frank Kastenholz         kasten@ftp.com
  169. David Katinsky           dmk@pilot.njin.net
  170. Charles Kaufman          kaufman@zk3.dec.com
  171. Stephen Kent             kent@bbn.com
  172. Zbigniew Kielczewski     zbig@eicon.qc.ca
  173. Andrew Knutsen           andrewk@sco.com
  174.  
  175.                                    3
  176.  
  177.  
  178.  
  179.  
  180.  
  181. Paul Lambert             paul_lambert@email.mot.com
  182. John Linn                linn@gza.com
  183. James Mahon              mahonj@honfsi1.att.com
  184. Cynthia Martin           martin@spica.disa.mil
  185. Evan McGinnis            bem@3com.com
  186. P.V. McMahon             p.v.mcmahon@rea0803.wins.icl.co.uk
  187. Bob Morgan               morgan@networking.stanford.edu
  188. Clifford Neuman          bcn@isi.edu
  189. Emmanuel Pasetes         ekp@enlil.premenos.sf.ca.us
  190. Christopher Provenzano   proven@csi.compuserve.com
  191. Steven Richardson        sjr@merit.edu
  192. April Richstein          amr@tycho.ncsc.mil
  193. Shawn Routhier           sar@epilogue.com
  194. Jeffrey Schiller         jis@mit.edu
  195. Wolfgang Schneider       schneider@gmd.de
  196. Sam Sjogren              sjogren@tgv.com
  197. Stuart Stanley           stuarts@apertus.com
  198. Bob Stewart              rlstewart@eng.xyplex.com
  199. Stuart Stubblebine       stubblebine@isi.edu
  200. Louisa Thomson           louisa@whitney.hac.com
  201. Klaus Truoel             truoel@gmd.de
  202. Theodore Ts'o            tytso@mit.edu
  203. James Weatherford        weatherf@nosc.mil
  204. Peter Wilson             peter_wilson@3com.com
  205.  
  206.  
  207.  
  208.                                    4
  209.