home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-aft-socks-cram-00.txt < prev    next >
Text File  |  1997-03-20  |  8KB  |  226 lines
  1.  
  2. INTERNET-DRAFT                                           M. VanHeyningen
  3. <draft-ietf-aft-socks-cram-00>                      Aventail Corporation
  4. Expires 20 September 1997                                  20 March 1997
  5.  
  6.  
  7.          Challenge-Response Authentication Method for SOCKS V5
  8.  
  9. Status of this Memo
  10.  
  11.       This document is an Internet-Draft.  Internet-Drafts are working
  12.       documents of the Internet Engineering Task Force (IETF), its
  13.       areas, and its working groups.  Note that other groups may also
  14.       distribute working documents as Internet-Drafts.
  15.  
  16.       Internet-Drafts are draft documents valid for a maximum of six
  17.       months and may be updated, replaced, or obsoleted by other
  18.       documents at any time.  It is inappropriate to use Internet-
  19.       Drafts as reference material or to cite them other than as ``work
  20.       in progress.''
  21.  
  22.       To learn the current status of any Internet-Draft, please check
  23.       the ``1id-abstracts.txt'' listing contained in the Internet-
  24.       Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
  25.       (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
  26.       Coast), or ftp.isi.edu (US West Coast).
  27.  
  28. Abstract
  29.  
  30.    This document specifies a general Challenge-Response Authentication
  31.    Method (CRAM) for use with SOCKS Version 5 [RFC 1928].  It is
  32.    intended to support various challenge-response mechanisms, such as
  33.    S/KEY and OTP [RFC 1938] as well as authentication tokens.
  34.  
  35. Introduction
  36.  
  37.    The protocol specification for SOCKS Version 5 [RFC 1928] specifies a
  38.    generalized framework for the use of arbitrary authentication
  39.    protocols in the initial SOCKS connection setup.  This document
  40.    suggests a general framework for a Challenge-Response Authentication
  41.    Method (CRAM) as it fits into the SOCKS Version 5 authentication
  42.    "subnegotiation."
  43.  
  44. Initial Negotiation
  45.  
  46.    During initial SOCKS V5 negotiation, the client and server negotiate
  47.    the authenticiation method.  The METHOD for this protocol shall be
  48.    X'05'.
  49.  
  50.  
  51.  
  52.  
  53. VanHeyningen              Expires 20 Sept 1997                  [Page 1]
  54.  
  55. INTERNET-DRAFT       Challenge-Response for SOCKS V5       20 March 1997
  56.  
  57.  
  58. Challenge-Reponse Framework
  59.  
  60.    Subnegotiation begins after the client has selected the CRAM
  61.    authentication method.
  62.  
  63.  Message Format
  64.  
  65.    In general, messages exchanged consist of a version identifier and a
  66.    list of attribute-value assertions, where attributes are single
  67.    octets and values are sequences of 0-255 octets.
  68.  
  69.            +-----+-------+------+---------+------+------+---
  70.            | VER | NAVAS | ATT1 | VAL1LEN | VAL1 | ATT2 | ...
  71.            +-----+-------+------+---------+------+------+---
  72.            |  1  |   1   |   1  |    1    | 0-255|  1   | ...
  73.            +-----+-------+------+---------+------+------+---
  74.  
  75.    VER contains the current version of the subnegotiation, which is
  76.    X'01'.  NAVAS contains the number of attribute-value assertions to
  77.    follow.  Each AVA includes ATT_i, containing the attribute, VAL_iLEN,
  78.    containing the length of VAL_i, and VAL_i.  In general, robust
  79.    implementations should ignore assertions with attributes they do not
  80.    understand.  This provides a powerful and general mechanism for future
  81.    extensions while allowing backward compatibility.
  82.  
  83.    Notationally, a single message with a list of n assertions shall be
  84.    represented as:
  85.  
  86.         ATT_1(VAL_1), ATT_2(VAL_2), ... ATT_n(VAL_n)
  87.  
  88.  Attributes
  89.  
  90.    The following attribute definitions apply to all messages:
  91.  
  92.         ATT     Label           Meaning
  93.         ----------------------------------------------
  94.         X'00'   STATUS          0 = success
  95.         X'01'   TEXT-MESSAGE    Informational text
  96.         X'02'   USER-IDENTITY
  97.         X'03'   CHALLENGE
  98.         X'04'   RESPONSE
  99.         X'05'   CHARSET
  100.  
  101.    The TEXT-MESSAGE attribute may always be included in any message
  102.    (except submethod negotiation.)  Implementations should display its
  103.    contents to the user if applicable; it should be used for advisory
  104.    information (e.g. warnings of pending password expiration,
  105.    explanations accompanying a failure.) If there is no user,
  106.  
  107.  
  108.  
  109. VanHeyningen              Expires 20 Sept 1997                  [Page 2]
  110.  
  111. INTERNET-DRAFT       Challenge-Response for SOCKS V5       20 March 1997
  112.  
  113.  
  114.    implementations may log its contents.
  115.  
  116.    The CHARSET attribute provides advisory infomration about the
  117.    character set in use; it, too, may be present in any message.
  118.    Implementations should use it to guide presentation of information to
  119.    users.  The semantics are identical to that of the charset parameter
  120.    in MIME [RFC 1521]; if absent, a default of ISO-8859-1 should be
  121.    assumed.
  122.  
  123.    Submethods may also define their own additional attributes, but must
  124.    not redefine the above standard ones.
  125.  
  126. Protocol Exchange
  127.  
  128.    Generic challenge-response simply authenticates the client's identity
  129.    by sending a textual challenge from the server which the client
  130.    displays to the user.  The user somehow (e.g. by using an external
  131.    application or a security token) computes the appropriate response and
  132.    enters it.
  133.  
  134.    First, the client asserts its identity to the server:
  135.  
  136.         USER-IDENTITY(<username>)
  137.  
  138.    The server then responds with a textual challenge to be displayed to
  139.    the user:
  140.  
  141.         CHALLENGE(<challenge>)
  142.  
  143.    The client displays this challenge, prompts for a response, and sends
  144.    it:
  145.  
  146.         RESPONSE(<response>)
  147.  
  148.    The server may respond with a new challenge method, for which a new 
  149. response is
  150.    required.  Arbitrarily many challenges may be issued.
  151.    When the server finished issuing challenges, it sends a status message:
  152.  
  153.         STATUS(success|failure)
  154.  
  155.    and the subnegotiation terminates.  If the authentication did not succeed,
  156.    the server must drop the connection.
  157.  
  158. Security Considerations
  159.  
  160.    Challenge-response protocols are generally designed to provide
  161.    protection from passive attacks such as sniffing passwords.  The
  162.    security mechanisms here generally offer only limited protection from
  163.  
  164.  
  165.  
  166. VanHeyningen              Expires 20 Sept 1997                  [Page 3]
  167.  
  168. INTERNET-DRAFT       Challenge-Response for SOCKS V5       20 March 1997
  169.  
  170.  
  171.    real-time active attacks.
  172.  
  173.    In most challenge-response security mechanisms, it is important that
  174.    challenges be produced in a fashion an adversary cannot predict or
  175.    duplicate.  As with all negotiation-based security, implementations
  176.    may be vulnerable to downgrade attacks.  Clients and servers should
  177.    refuse to operate with methods and algorithms considered
  178.    insufficiently secure.
  179.  
  180. Acknowledgements
  181.  
  182.    Thanks to Dave Blob, Wei Lu, Craig Metz and William Perry for
  183.    assistance with this document.
  184.  
  185. References
  186.  
  187.    [RFC 1521] Borenstein, N, & Freed, N., "MIME (Multipurpose Internet
  188.    Mail Extensions) Part One: Mechanisms for Specifying and Describing
  189.    the Format of Internet Message Bodies," September 1993.
  190.  
  191.    [RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., &
  192.    Jones, L., "SOCKS Protocol V5," April 1996.
  193.  
  194.    [RFC 1938] Haller, N., & Metz, C., "A One-Time Password System," May
  195.    1996.
  196.  
  197.    [RFC 2058] Rigney, C., Rubens, A., Simpson, W. A., & Willens, S.,
  198.    "Remote Authentication Dial In User Service (RADIUS)", January 1997.
  199.  
  200. Author's Address
  201.  
  202.    Marc VanHeyningen
  203.    Aventail Corporation
  204.    117 S. Main Street, Suite 400
  205.    Seattle, WA   98104
  206.  
  207.    Phone: +1 206 777-5600
  208.    Fax:   +1 206 777-5656
  209.    Email: marcvh@aventail.com
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222. VanHeyningen              Expires 20 Sept 1997                  [Page 4]
  223.  
  224.  
  225.  
  226.