[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                         K. Culbert
Internet Draft                                             Funk Software
expires in six months                                 September 18, 1996


               Proposal for LCP Authentication Option
                  draft-ietf-pppext-link-negot-00.txt



Status of this Memo

   This document is a submission of the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF).  Comments should
   be submitted to the ietf-ppp@merit.edu mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   `working draft' or `work in progress.'

   Please check the 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on nic.ddn.mil, ds.internic.net,
   venera.isi.edu, nic.nordu.net, or munnari.oz.au to learn the current
   status of any Internet Draft.


Abstract

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.  PPP
   is comprised of three main components:

      1. A method for encapsulating multi-protocol datagrams.

      2. A Link Control Protocol (LCP) for establishing, configuring,
         and testing the data-link connection.

      3. A family of Network Control Protocols (NCPs) for establishing
         and configuring different network-layer protocols.


   This document defines an interoperable method for the authentication
   of peers during the Link negotiation phase.



Culbert                  expires in six months                  [Page 1]


DRAFT              PPP LCP Authentication Option         September 1996


1.  Introduction

   Up-to-date values of the LCP Option Type field are specified in the
   most recent "Assigned Numbers" RFC [2].  This document concerns the
   following values:


   In "The Point-to-Point Protocol [1], the use of an authentication
   protocol may be negotiated as part of the LCP negotiation phase.
   The actual process of authentication is then performed in a
   subsequent authentication phase.

   This scheme may be unsatisfactory in situations, such as in the
   negotiation of Callback [3] or Layer 2 Tunneling [4], where the
   identity and authenticity of the peer is required during the LCP
   phase.

   It is proposed that a new LCP Authentication Option be defined as a
   extension to the Link Control Protocol.


1.1. Specification Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.

   MUST      This word, or the adjective "required", means that the
             definition is an absolute requirement of the specification.

   MUST NOT  This phrase means that the definition is an absolute
             prohibition of the specification.

   SHOULD    This word, or the adjective "recommended", means that there
             may exist valid reasons in particular circumstances to
             ignore this item, but the full implications must be
             understood and carefully weighed before choosing a
             different course.

   MAY       This word, or the adjective "optional", means that this
             item is one of an allowed set of alternatives.  An
             implementation which does not include this option MUST be
             prepared to interoperate with another implementation which
             does include the option.











Culbert                  expires in six months                  [Page 2]


DRAFT              PPP LCP Authentication Option         September 1996


1.2 Terminology

   This document frequently uses the following terms:

   peer            An end-point of a point-to-point link.

   authenticator   The end-point that verifies the authenticity of
                   its peer.

   authenticatee   The end-point that is requesting authentication.

   silently discard
                   The implementation discards the packet without
                   further processing.  The implementation SHOULD
                   provide the capability of logging the error,
                   including the contents of the silently discarded
                   packet, and SHOULD record the event in a statistics
                   counter.


2.0 Overview

   In the current scheme, authentication is negotiated as part of the
   LCP phase, while authentication is actually carried out in a
   subsequent authentication phase.  This document extends this scheme
   by adding a new option to the Link Control Protocol (LCP) which
   enables authentication to be carried out during the LCP
   negotiation phase.


   The LCP-Authentication option works differently than the current
   Authentication option in that the authenticatee includes the option
   in its Configuration-Request, and the authenticator indicates the
   success or failure of authentication in its response (Config-Ack
   or Config-Rej).

   Rejection of the LCP-Authentication option does not preclude
   negotiation of an authentication protocol using the current
   Authentication option.

   An authenticatee MAY offer the LCP-Authentication option in an
   initial Configure-Request or may wait for an authenticator to
   request its use by including it in a Config-Nak.  An authenticator
   MAY include it in a Config-Nak in order to request its use by its
   peer; a peer which does not support the option MAY then send a
   Config-Nak including the current Authentication option or may simply
   wait for the authenticator to include the current Authentication
   option in a Config-Request.





Culbert                  expires in six months                  [Page 3]


DRAFT              PPP LCP Authentication Option         September 1996


2.1 Description

   A maximum of one LCP-Authentication option MAY be included in an LCP
   frame.

   The LCP-Authentication option may be initiated by either the
   authenticator or authenticatee.  Here is an example of such a dialog:


        Authenticator                                     Authenticatee
        -------------                                     -------------

                            Config-Request
           <--------------------------------------------------
               authentication type / authenticatee id


                              Config-Nak
           -------------------------------------------------->
            authentication type / authenticator id / challenge


                            Config-Request
           <--------------------------------------------------
            authentication type / authenticatee id / response

                       Config Ack or Config-Rej
           -------------------------------------------------->
                  authentication type / authenticator id / message



   Each end-point includes its identity (username) in every packet; an
   advantage of so doing is that both peers can then access their
   databases to determine which LCP options may be appropriate for
   its peer, such as Callback.  Therefore, this option could be used
   merely to provide identity, leaving authentication to be carried out
   using the current scheme.

   If an authenticatee fails authentication based on the
   LCP-Authentication option, the authenticator MAY terminate the
   connection with a Terminate-Request.  If an authenticatee does not
   negotiate any authentication scheme, the authenticator MAY terminate
   the connection.

   An implementation MAY choose to not implement any or all
   authentication types.






Culbert                  expires in six months                  [Page 4]


DRAFT              PPP LCP Authentication Option         September 1996


   The LCP Authentication option employs a challenge-handshake
   technique, similar to CHAP [5].  The authenticator includes a
   Challenge value in the Value field of the LCP-Authentication option
   included in a Configuration-Nak.  The authenticator then performs an
   MD5 hash over a stream of octets consisting of the concatentation of
   the Configuration-Request identifier, the "secret" (password), and
   the challenge value.  The length of the Value field for the LCP
   Authentication option in both Configuration-Naks and
   Configuration-Acks is 16.

   The challenge value SHOULD change if the LCP Authentication option
   is sent in a Configuration-Nak with a different Identifier.

   If the authenticatee fails authentication, the authenticator MUST
   send a Configuration-Rej, and MAY terminate the link by issuing a
   Terminate-Request.

   If the authenticatee succeeds, the authenticator MUST send a
   Configuration-Ack.

   A summary of the LCP-Authentication option format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |   Length      |   Id-Length   |Identification...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type

      to be determined

   Length

      >= 3


   Id-Length

      The Id-Length field is one octet and indicates the length of the
      Identification field.


   Identification

      The Identification field is zero or more octets and indicates the
      identity of the sending peer.



Culbert                  expires in six months                  [Page 5]


DRAFT              PPP LCP Authentication Option         September 1996


   Value

      The Value field is zero or more octets and MAY contain a Challenge
      value in the case of a Configuration-Request, a Response value in
      the case of a Configuration-Response, or a message in the case of
      a Configuration-Ack or Configuration-Rej.



3.0 Security Considerations

   Security issues are the primary topic of this draft.


4.0 References

   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC
         1548, Daydreamer, December 1993.

   [2]   Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
         RFC 1340, USC/Information Sciences Institute, July 1992.

   [3]   Simpson, W., Editor, "PPP LCP Extensions", RFC 1570,
         Daydreamer, January 1994.

   [4]   Valencia, A. J., and G. S. Pall, "Layer Two Tunneling
         Protocol "L2TP"", work in progress, Cisco Systems, August
         1996.

   [5]   Lloyd, B., and W. Simpson, "PPP Authentication", RFC 1334,
         L & A, October 1992.






















Culbert                  expires in six months                  [Page 6]


DRAFT              PPP LCP Authentication Option         September 1996


Acknowledgments

   Thanks to Vernon Schryver for his assistance in developing this draft.



Chair's Address

   The working group can be contacted via the current chair:

      Karl F. Fox
      Ascend Communications
      3518 Riverside Dr., Suite 101
      Columbus, OH  43221

      EMail: karl@ascend.com


Author's Address

   Questions about this memo can also be directed to:

      Ken Culbert
      Funk Software, Inc.
      222 Third Street
      Cambridge, MA 02142

      +1 617 497-6339
      EMail: ken@funk.com
























Culbert                  expires in six months                  [Page 7]