home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 97aug / aaarg-agenda-97aug.txt < prev    next >
Text File  |  1997-07-27  |  5KB  |  138 lines
  1. Application Authentication/Authorization Review Group BOF (aaarg)
  2.  
  3. Wednesday, August 13 at 1930-2200
  4. =================================
  5.  
  6. Charter 
  7.  
  8. Current status: proposed working group
  9.  
  10. Chair(s):
  11.     Paul Krumviede <paul@mci.net>
  12.  
  13. Applications Area Director(s): 
  14.     Keith Moore  <moore+iesg@cs.utk.edu>
  15.     Harald Alvestrand  <Harald.T.Alvestrand@uninett.no>
  16.  
  17. Mailing lists:
  18.     General Discussion: ietf-aaarg@imc.org
  19.     To Subscribe:       ietf-aaarg-request@imc.org
  20.     Archive:            http://www.imc.org/ietf-aaarg/
  21.  
  22. Description of BOF:
  23.  
  24. The IESG/IAB security workshop concluded that plaintext passwords are
  25. no longer acceptable in new protocols.  Unfortunately, a large number
  26. of complex problems need to be solved in order for there to be a
  27. practical alternative for application protocols.  The goal of this
  28. working group is to identify or develop components for a baseline
  29. authentication/authorization system for use by Internet application
  30. protocols.  This system must have the following characteristics:
  31.  
  32. * Be as simple as possible -- specifically, baseline authentication,
  33.   authorization and integrity services must not require ASN.1 or the
  34.   deployment of a certificate infrastructure.
  35.  
  36. * Have no dependencies which require or have the effect of requiring
  37.   trade secret technology
  38.  
  39. * Have no dependencies which would prevent or unnecessarily complicate
  40.   freely available or shareware implementations.  Specifically, patents
  41.   are a serious concern.
  42.  
  43. * Provide a transition strategy for moving from current plaintext
  44.   password systems
  45.  
  46. * Allow for the existence of proxy servers in the architecture
  47.  
  48. * Avoid potential export restrictions as much as possible
  49.  
  50. The top priority deliverables are:
  51.  
  52. * A SASL mechanism intended to replace CRAM-MD5 which repairs the
  53.   weakness of MD5, the lack of an authorization identifier, and
  54.   possibly also addresses the lack of optional integrity protection
  55.   and CRAM's susceptibility to dictionary attacks by a passive
  56.   observer.  This document should include sample source code in an
  57.   appendix to assist implementors with no security experience or
  58.   references.
  59.  
  60. * A simple password changing protocol to replace the defacto standard
  61.   "poppassd" which uses plaintext passwords.
  62.  
  63. * A SASL mechanism which can be used to transition from plaintext
  64.   passwords
  65.  
  66. * A simple protocol to permit the verification of authentication
  67.   credentials against an authentication/authorization database.
  68.   RADIUS will be reviewed to determine if it is appropriate for
  69.   application level use.
  70.  
  71. * An RFC which documents the overall architecture for application
  72.   protocols and makes recommendations for how application protocol
  73.   implementors can support various security scenarios.
  74.  
  75. The second priority deliverables are:
  76.  
  77. * An Informational RFC which documents vendor support for this
  78.   architecture.  This will require an outreach effort to Internet
  79.   server vendors to determine how they can integrate a "no plaintext
  80.   passwords on the network" architecture into operating system
  81.   services such as login, change password, switch user and proprietary
  82.   secure services.
  83.  
  84. * An RFC which makes a recommendation for a small set of encryption
  85.   technologies for use in application protocols which meet the
  86.   architecture criteria listed above.  The goal is to make
  87.   interoperable encryption easier to deploy.
  88.  
  89. * An RFC which recommends a single remote login protocol for use with
  90.   this architecture.  If necessary this will repair problems in that
  91.   protocol or extend it to meet the architecture criteria.
  92.  
  93. * An RFC which documents an API for use with SASL
  94.  
  95. Goals and Milestones: 
  96.  
  97.    Jun 97       First draft of SASL password transition document
  98.  
  99.    Jul 97       First draft of password change document
  100.  
  101.    Aug 97       First draft of authentication verification protocol,
  102.                 if deemed necessary
  103.  
  104.    Aug 97       First draft of CRAM-MD5 replacement document
  105.  
  106.    Aug 97       Meet in Munich
  107.  
  108.    Sep 97       First draft of architecture document
  109.  
  110.    Sep 97       SASL transition submitted to IESG for proposed standard
  111.  
  112.    Sep 97       Password change submitted to IESG for proposed standard
  113.  
  114.    Oct 97       Auth verification submitted to IESG for proposed standard
  115.  
  116.    Nov 97       CRAM-MD5 replacement submitted to IESG for proposed standard
  117.  
  118.    Nov 97       First draft of encryption document
  119.  
  120.    Nov 97       First draft of SASL API
  121.  
  122.    Nov 97       First draft of remote login document
  123.  
  124.    Dec 97       First draft of vendor document
  125.  
  126.    Dec 97       Architecture document submitted to IESG for ?? status
  127.  
  128.    Jun 98       Conclude Working Group
  129.  
  130. Internet-Drafts:
  131.  
  132. Posted Revised       I-D Title  <Filename>
  133. ------ ------- ------------------------------------------
  134.  
  135. Request For Comments:
  136.  
  137.   None to date.
  138.