home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-pppext-link-negot-00.txt < prev    next >
Text File  |  1996-09-23  |  12KB  |  410 lines
  1.  
  2. Network Working Group                                         K. Culbert
  3. Internet Draft                                             Funk Software
  4. expires in six months                                 September 18, 1996
  5.  
  6.  
  7.                Proposal for LCP Authentication Option
  8.                   draft-ietf-pppext-link-negot-00.txt
  9.  
  10.  
  11.  
  12. Status of this Memo
  13.  
  14.    This document is a submission of the Point-to-Point Protocol Working
  15.    Group of the Internet Engineering Task Force (IETF).  Comments should
  16.    be submitted to the ietf-ppp@merit.edu mailing list.
  17.  
  18.    Distribution of this memo is unlimited.
  19.  
  20.    This document is an Internet Draft.  Internet Drafts are working
  21.    documents of the Internet Engineering Task Force (IETF), its Areas,
  22.    and its Working Groups.  Note that other groups may also distribute
  23.    working documents as Internet Drafts.
  24.  
  25.    Internet Drafts are draft documents valid for a maximum of six
  26.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  27.    other documents at any time.  It is not appropriate to use Internet
  28.    Drafts as reference material or to cite them other than as a
  29.    `working draft' or `work in progress.'
  30.  
  31.    Please check the 1id-abstracts.txt listing contained in the
  32.    internet-drafts Shadow Directories on nic.ddn.mil, ds.internic.net,
  33.    venera.isi.edu, nic.nordu.net, or munnari.oz.au to learn the current
  34.    status of any Internet Draft.
  35.  
  36.  
  37. Abstract
  38.  
  39.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  40.    transporting multi-protocol datagrams over point-to-point links.  PPP
  41.    is comprised of three main components:
  42.  
  43.       1. A method for encapsulating multi-protocol datagrams.
  44.  
  45.       2. A Link Control Protocol (LCP) for establishing, configuring,
  46.          and testing the data-link connection.
  47.  
  48.       3. A family of Network Control Protocols (NCPs) for establishing
  49.          and configuring different network-layer protocols.
  50.  
  51.  
  52.    This document defines an interoperable method for the authentication 
  53.    of peers during the Link negotiation phase.
  54.  
  55.  
  56.  
  57. Culbert                  expires in six months                  [Page 1]
  58.  
  59. DRAFT              PPP LCP Authentication Option         September 1996
  60.  
  61.  
  62. 1.  Introduction
  63.  
  64.    Up-to-date values of the LCP Option Type field are specified in the
  65.    most recent "Assigned Numbers" RFC [2].  This document concerns the
  66.    following values:
  67.  
  68.  
  69.    In "The Point-to-Point Protocol [1], the use of an authentication
  70.    protocol may be negotiated as part of the LCP negotiation phase.
  71.    The actual process of authentication is then performed in a 
  72.    subsequent authentication phase.
  73.  
  74.    This scheme may be unsatisfactory in situations, such as in the
  75.    negotiation of Callback [3] or Layer 2 Tunneling [4], where the 
  76.    identity and authenticity of the peer is required during the LCP 
  77.    phase.
  78.  
  79.    It is proposed that a new LCP Authentication Option be defined as a
  80.    extension to the Link Control Protocol.
  81.  
  82.  
  83. 1.1. Specification Requirements
  84.  
  85.    In this document, several words are used to signify the requirements
  86.    of the specification.  These words are often capitalized.
  87.  
  88.    MUST      This word, or the adjective "required", means that the
  89.              definition is an absolute requirement of the specification.
  90.  
  91.    MUST NOT  This phrase means that the definition is an absolute
  92.              prohibition of the specification.
  93.  
  94.    SHOULD    This word, or the adjective "recommended", means that there
  95.              may exist valid reasons in particular circumstances to
  96.              ignore this item, but the full implications must be
  97.              understood and carefully weighed before choosing a
  98.              different course.
  99.  
  100.    MAY       This word, or the adjective "optional", means that this
  101.              item is one of an allowed set of alternatives.  An
  102.              implementation which does not include this option MUST be
  103.              prepared to interoperate with another implementation which
  104.              does include the option.
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116. Culbert                  expires in six months                  [Page 2]
  117.  
  118. DRAFT              PPP LCP Authentication Option         September 1996
  119.  
  120.  
  121. 1.2 Terminology
  122.  
  123.    This document frequently uses the following terms:
  124.  
  125.    peer            An end-point of a point-to-point link.
  126.  
  127.    authenticator   The end-point that verifies the authenticity of 
  128.                    its peer.
  129.  
  130.    authenticatee   The end-point that is requesting authentication.
  131.  
  132.    silently discard
  133.                    The implementation discards the packet without 
  134.                    further processing.  The implementation SHOULD 
  135.                    provide the capability of logging the error, 
  136.                    including the contents of the silently discarded 
  137.                    packet, and SHOULD record the event in a statistics 
  138.                    counter.
  139.  
  140.  
  141. 2.0 Overview
  142.  
  143.    In the current scheme, authentication is negotiated as part of the 
  144.    LCP phase, while authentication is actually carried out in a 
  145.    subsequent authentication phase.  This document extends this scheme 
  146.    by adding a new option to the Link Control Protocol (LCP) which
  147.    enables authentication to be carried out during the LCP
  148.    negotiation phase.
  149.  
  150.  
  151.    The LCP-Authentication option works differently than the current 
  152.    Authentication option in that the authenticatee includes the option
  153.    in its Configuration-Request, and the authenticator indicates the
  154.    success or failure of authentication in its response (Config-Ack
  155.    or Config-Rej).
  156.  
  157.    Rejection of the LCP-Authentication option does not preclude
  158.    negotiation of an authentication protocol using the current
  159.    Authentication option.
  160.  
  161.    An authenticatee MAY offer the LCP-Authentication option in an 
  162.    initial Configure-Request or may wait for an authenticator to 
  163.    request its use by including it in a Config-Nak.  An authenticator
  164.    MAY include it in a Config-Nak in order to request its use by its 
  165.    peer; a peer which does not support the option MAY then send a 
  166.    Config-Nak including the current Authentication option or may simply
  167.    wait for the authenticator to include the current Authentication 
  168.    option in a Config-Request.
  169.  
  170.  
  171.  
  172.  
  173.  
  174. Culbert                  expires in six months                  [Page 3]
  175.  
  176. DRAFT              PPP LCP Authentication Option         September 1996
  177.  
  178.  
  179. 2.1 Description
  180.  
  181.    A maximum of one LCP-Authentication option MAY be included in an LCP
  182.    frame.  
  183.  
  184.    The LCP-Authentication option may be initiated by either the 
  185.    authenticator or authenticatee.  Here is an example of such a dialog:
  186.  
  187.  
  188.         Authenticator                                     Authenticatee
  189.         -------------                                     -------------
  190.  
  191.                             Config-Request
  192.            <--------------------------------------------------
  193.                authentication type / authenticatee id
  194.  
  195.  
  196.                               Config-Nak
  197.            -------------------------------------------------->
  198.             authentication type / authenticator id / challenge
  199.  
  200.  
  201.                             Config-Request
  202.            <--------------------------------------------------
  203.             authentication type / authenticatee id / response
  204.  
  205.                        Config Ack or Config-Rej
  206.            -------------------------------------------------->
  207.                   authentication type / authenticator id / message        
  208.  
  209.  
  210.  
  211.    Each end-point includes its identity (username) in every packet; an
  212.    advantage of so doing is that both peers can then access their
  213.    databases to determine which LCP options may be appropriate for
  214.    its peer, such as Callback.  Therefore, this option could be used
  215.    merely to provide identity, leaving authentication to be carried out
  216.    using the current scheme.
  217.  
  218.    If an authenticatee fails authentication based on the 
  219.    LCP-Authentication option, the authenticator MAY terminate the 
  220.    connection with a Terminate-Request.  If an authenticatee does not
  221.    negotiate any authentication scheme, the authenticator MAY terminate
  222.    the connection.
  223.  
  224.    An implementation MAY choose to not implement any or all 
  225.    authentication types.
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232. Culbert                  expires in six months                  [Page 4]
  233.  
  234. DRAFT              PPP LCP Authentication Option         September 1996
  235.  
  236.                           
  237.    The LCP Authentication option employs a challenge-handshake 
  238.    technique, similar to CHAP [5].  The authenticator includes a 
  239.    Challenge value in the Value field of the LCP-Authentication option 
  240.    included in a Configuration-Nak.  The authenticator then performs an 
  241.    MD5 hash over a stream of octets consisting of the concatentation of 
  242.    the Configuration-Request identifier, the "secret" (password), and 
  243.    the challenge value.  The length of the Value field for the LCP
  244.    Authentication option in both Configuration-Naks and 
  245.    Configuration-Acks is 16.
  246.  
  247.    The challenge value SHOULD change if the LCP Authentication option
  248.    is sent in a Configuration-Nak with a different Identifier.
  249.  
  250.    If the authenticatee fails authentication, the authenticator MUST
  251.    send a Configuration-Rej, and MAY terminate the link by issuing a 
  252.    Terminate-Request.
  253.  
  254.    If the authenticatee succeeds, the authenticator MUST send a 
  255.    Configuration-Ack.
  256.  
  257.    A summary of the LCP-Authentication option format is shown below.  
  258.    The fields are transmitted from left to right.
  259.  
  260.     0                   1                   2                   3
  261.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  262.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  263.    |     Type      |   Length      |   Id-Length   |Identification...
  264.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  265.    |     Value ...
  266.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  267.  
  268.    Type
  269.  
  270.       to be determined
  271.  
  272.    Length
  273.  
  274.       >= 3
  275.  
  276.  
  277.    Id-Length
  278.  
  279.       The Id-Length field is one octet and indicates the length of the 
  280.       Identification field.
  281.  
  282.  
  283.    Identification 
  284.  
  285.       The Identification field is zero or more octets and indicates the
  286.       identity of the sending peer.
  287.  
  288.  
  289.  
  290. Culbert                  expires in six months                  [Page 5]
  291.  
  292. DRAFT              PPP LCP Authentication Option         September 1996
  293.  
  294.  
  295.    Value
  296.  
  297.       The Value field is zero or more octets and MAY contain a Challenge
  298.       value in the case of a Configuration-Request, a Response value in
  299.       the case of a Configuration-Response, or a message in the case of
  300.       a Configuration-Ack or Configuration-Rej.
  301.  
  302.  
  303.  
  304. 3.0 Security Considerations
  305.  
  306.    Security issues are the primary topic of this draft.
  307.  
  308.  
  309. 4.0 References
  310.  
  311.    [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC
  312.          1548, Daydreamer, December 1993.
  313.  
  314.    [2]   Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
  315.          RFC 1340, USC/Information Sciences Institute, July 1992.
  316.  
  317.    [3]   Simpson, W., Editor, "PPP LCP Extensions", RFC 1570,
  318.          Daydreamer, January 1994.
  319.  
  320.    [4]   Valencia, A. J., and G. S. Pall, "Layer Two Tunneling 
  321.          Protocol "L2TP"", work in progress, Cisco Systems, August 
  322.          1996.
  323.  
  324.    [5]   Lloyd, B., and W. Simpson, "PPP Authentication", RFC 1334,
  325.          L & A, October 1992.
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348. Culbert                  expires in six months                  [Page 6]
  349.  
  350. DRAFT              PPP LCP Authentication Option         September 1996
  351.  
  352.  
  353. Acknowledgments
  354.  
  355.    Thanks to Vernon Schryver for his assistance in developing this draft.
  356.  
  357.  
  358.  
  359. Chair's Address
  360.  
  361.    The working group can be contacted via the current chair:
  362.  
  363.       Karl F. Fox
  364.       Ascend Communications
  365.       3518 Riverside Dr., Suite 101
  366.       Columbus, OH  43221
  367.  
  368.       EMail: karl@ascend.com
  369.  
  370.  
  371. Author's Address
  372.  
  373.    Questions about this memo can also be directed to:
  374.  
  375.       Ken Culbert
  376.       Funk Software, Inc.
  377.       222 Third Street
  378.       Cambridge, MA 02142
  379.  
  380.       +1 617 497-6339    
  381.       EMail: ken@funk.com
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406. Culbert                  expires in six months                  [Page 7]
  407.  
  408.  
  409.  
  410.