PPP Working Group                                          Pat R. Calhoun
INTERNET DRAFT                                           3Com Corporation
Category: Internet Draft                                 W. Mark Townsley
Title: draft-ietf-pppext-l2tp-sec-01.txt                  IBM Corporation
Date: July 1997



                  Layer Two Tunneling Protocol "L2TP"
               Security Extensions for Non-IPSEC networks


Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working doc-
   uments of the Internet Engineering Task Force (IETF), its areas, and
   its working groups.  Note that other groups may also distribute work-
   ing 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 ``work-
   ing draft'' or ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
   munnari.oz.au.

Abstract

   The L2TP document [1] defines the base protocol which describes the
   method of tunneling PPP [2] data. The L2TP document states that the
   security mechanism used over an IP network is to use the IETF's IPSEC
   protocols.

   L2TP was designed in such a way as to be able to run over any
   underlying layer (i.e. Frame Relay, ATM, etc.). This document
   specifies extensions to the L2TP protocol in order to provide
   authentication and integrity of individual packets in a tunneled
   session over a network where IPSEC or another suitable security
   protocol is not available.

Table of Contents

      1.0 Introduction
      1.1 Conventions



Calhoun, Townsley        expires Janurary 1998                  [Page 1]


INTERNET DRAFT                                                 July 1997


      2.0 L2TP Security Header Format
      3.1 Denial of Service Attacks
      3.2 Replay Attacks
      3.3 Compromise of the Master Key
      4.0 Security Association Negotiation
      4.1 New Start-Control-Connection-Request/-Reply AVPs
      4.2 Renegotiate-Security-Association Message
      5.0 Acknowledgments
      6.0 Contacts
      7.0 References
      Appendix A: Additional Recommendations for secure L2TP implementations

1.0 Introduction

   The L2TP protocol specification states that the IPSEC protocols MUST
   be used over an IP network for L2TP to operate in a secure manner.
   However, L2TP may be run on a link layer that does not have a
   security mechanism such as IPSEC available. In this case it becomes
   necessary for L2TP to provide its own mechanism for packet level
   security.

   This document will describe how authentication and integrity of L2TP
   packets will be handled over networks where IPSEC or another suitable
   security protocol does not exist. It does not intend to provide a
   mechanism for encryption of packets. If data encryption is necessary,
   then the user may utilize ECP or another form of end to end
   encryption.

   The security extensions defined here also provide the added
   flexibility to negotiate security separately over the control and
   data channels. This may be desirable in some situations, particularly
   where processing power may be at a minimum, but some level of
   security is still desired.

   By design, several of the constructs used here draw upon those being
   developed in the IPSEC working group.

1.1 Conventions

   The following language conventions are used in the items of specifi-
   cation in this document:

         o  MUST, SHALL, or MANDATORY -- This item is an absolute
            requirement of the specification.

         o  SHOULD or RECOMMEND -- This item should generally be followed
            for all but exceptional circumstances.




Calhoun, Townsley        expires Janurary 1998                  [Page 2]


INTERNET DRAFT                                                 July 1997


         o  MAY or OPTIONAL -- This item is truly optional and may be
            followed or ignored according to the needs of the
            implementor.
















































Calhoun, Townsley        expires Janurary 1998                  [Page 3]


INTERNET DRAFT                                                 July 1997


2.0 L2TP Security Header Format

   The L2TP Header has been modified as follows in order to accommodate
   the new security extension.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |T|1|1|1|1|K|0|0|         | Ver |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tunnel ID           |            Call ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Ns              |               Nr              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Initialization Vector                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Initialization Vector                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Initialization Vector                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Initialization Vector                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Security Parameters Index                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Message Integrity Check                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Message Integrity Check                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Message Integrity Check                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Message Type AVP...                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ... (8 bytes)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The 'K' bit MUST be set to one (1) when the security extension is
   present. The behavior of the 'K' bit is identical on both the control
   and data channel.

Initialization Vector (IV)

   This field MUST contain a cryptographically random 128 bit value [5].

Security Parameters Index (SPI)

   The SPI is an arbitrary four octet value. It is an unstructured
   opaque index which is used in conjunction with the Tunnel ID to



Calhoun, Townsley        expires Janurary 1998                  [Page 4]


INTERNET DRAFT                                                 July 1997


   identify a particular Security Association. The behavior of the SPI
   is identical on the control and data channel.

   Message Integrity Check (MIC)

   The MIC contains the result of the HMAC-MD5-96 algorithm [3][4] as
   applied over the entire L2TP packet. The behavior of the MIC is
   identical on the control and data channel.

3.0 Protection Against Attacks

   This section will define certain methods of protecting against
   specific known types of attacks.

3.1 Denial of Service Attacks

   There currently exists a Denial of Service Attack whereby a malicious
   host can issue a stream of Start-Control-Connection- Request messages
   to an L2TP host on a network.

   Although an implementation MUST time-out when a Start-Control-
   Connection-Connected has not been received within a given window,
   there is still a possibility that if the messages were received fast
   enough the L2TP host would deplete its Control Connection Control
   Blocks. This form of attack is aggravated when the malicious host
   sends the packets with a random source IP address.

   One form of protection against this attack is to have a local list of
   trusted hosts, however this does not scale very well when providing a
   roaming service from anywhere on the Internet.  Furthermore,
   enforcing a security policy based on a source address is a very weak
   form of protection.

   Another method of protecting against this form of attack is to have
   the 'K' bit set in the initial Start-Control-Connection-Request
   message. The message would be signed with the common secret (or key,
   see below for more details). This scheme will ensure that only
   authenticated Start-Control-Connection-Requests will be accepted,
   making this type of attack very inconvenient for a malicious user to
   create.

   In order for this scheme to be successful, it is imperative that the
   base specification require that a base implementation which does not
   support any extensions MUST reject a Start-Control-Connection-Request
   message with a 'K' bit set.

3.2 Replay Attacks




Calhoun, Townsley        expires Janurary 1998                  [Page 5]


INTERNET DRAFT                                                 July 1997


   One common attack is the replay attack. This requires that a
   malicious user gain access to the network where packets are routed.

   There are two different types of replay attacks in the current L2TP
   protocol. The first takes advantage of the fact that since a secret
   is a long lived key (known as the master key), a malicious user can
   retrieve the Stop-Control-Connection-Request message from two L2TP
   peers and replay it at a later date when an L2TP tunnel is active
   between both peers.

   This form of attack is further complicated by the fact that the
   malicious user must inject the packet when the sequence number in the
   replayed packet is within the window of the receiver. This can be
   achieved using a brute force type attack by constantly sending the
   packet until the L2TP host accepts it. One more complication for the
   malicious user is the fact that the Tunnel and Call identifiers MUST
   be the same in the new session being attacked. This is possible, but
   improbable if the Tunnel and Call IDs are selected in a sufficiently
   random manner (while L2TP does not specify a method for selecting
   Tunnel and Call IDs, we reccommend choosing a method that is as
   unpredictable as possible to help guard against replay attacks,
   regardless if a security protocol is being utilized over the link).

   The second type of attack occurs when a user attempts to replay data
   packets being tunneled. An example of a malicious packet to replay
   would be a LCP Terminate Request message from a previous session. In
   this case, again, the Tunnel and the Call IDs MUST be identical for
   the L2TP peer to accept the packet.

   However, if a malicious user was to simply snoop the network and
   replay valid data packets from the current session it could
   potentially create some form of denial of service for the user. A
   good example of such a packet would be a TCP FIN packet (which are
   very common when using the WEB which have many short-lived
   connections). Since most TCP implementations do not have random
   initial sequence numbers, this is a very simple attack.

   In order to protect against such an attack it is recommended that the
   L2TP flow control mechanism be enabled on the data path. This will
   offer protection since a replay packet would only be accepted once
   the window "rolled" over.

3.3 Compromise of the Master Key

   Since tunnels may be long-lived and frequent, it is possible for the
   master key to be compromised. A malicious user could gain many valid
   samples and given enough resources could guess the master key. This
   is a very serious problem which must be addressed.



Calhoun, Townsley        expires Janurary 1998                  [Page 6]


INTERNET DRAFT                                                 July 1997


   One simple and effective method to protect against this is to have
   both L2TP peers generate a session key when a tunnel is created.
   This key would be transmitted in the Start-Control-Connection-Request
   and the appropriate -Reply message. Furthermore, an L2TP peer could
   generate a new key whenever its sequence number "rolls" over. This
   would create a new security association between both peers, and
   protect against compromise of the master key.

   This scheme would also protect against the replay of the data packet
   described above since the key would be changed once the Sequence
   number reached zero, making the replayed packet non- authenticated.

4.0 Security Association Negotiation

   This section will define the new message type and AVPs which are
   required for the security extensions of the L2TP protocol. The AVPs
   allow designation of a Key for control messages, payload messages, or
   both. The Keys may or may not be the same for each.

4.1 New Start-Control-Connection-Request/-Reply AVPs

   The following additional AVPs are defined for the existing Start-
   Control-Connection-Request and Start-Control-Connection-Reply
   messages.

   Encoded Control Message Key

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|        Length         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               ?               | Encoded Control Message Key...|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This AVP MAY be present in the control connection initiation
      messages. It is encoded as the attribute ?, mandatory, with the
      indicated number of bytes representing the encoded control message
      key. This AVP is optional. When present, the L2TP peer is
      indicating that authentication is required on all control message
      packets. The Control Message Key is to be used to perform the
      control message digest functions is encoded within the AVP as
      follows:

      encodedCtrlMsgKey = MD5( IV | masterKey ) Xor ctrlMsgKey

      and decoded as follows:




Calhoun, Townsley        expires Janurary 1998                  [Page 7]


INTERNET DRAFT                                                 July 1997


      ctrlMsgKey = MD5( IV | masterKey ) Xor encodedCtrlMsgKey

   Control Message SPI

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|          10           |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               ?               |     Control Message SPI...    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  .... (4 bytes)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This AVP MUST be present if the Encoded Control Message Key AVP is
      present. It is encoded as the attribute ?, mandatory, with length
      10.  This AVP contains the security parameters index for the
      control channel security association defined within this message.

   Encoded Payload Packet Key

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|        Length         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               ?               | Encoded Payload Packet Key... |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This AVP MAY be present in the control connection initiation
      messages. It is encoded as the attribute ?, mandatory, with the
      indicated number of bytes representing the encoded payload packet
      key. This AVP is optional. When present, the L2TP peer is
      indicating that authentication is required on all payload packets.
      The Payload Packet Key to be used to perform the payload packet
      digest functions is encoded within the AVP as follows:

      encodedPayloadPktKey = MD5( IV | masterKey ) Xor payloadPktKey

      and decoded as follows:

      payloadPktKey = MD5( IV | masterKey ) Xor payloadPktKey

   Payload Packet SPI

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Calhoun, Townsley        expires Janurary 1998                  [Page 8]


INTERNET DRAFT                                                 July 1997


      |1|0|0|0|          10           |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               ?               |      Payload Packet SPI...    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  .... (4 bytes)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This AVP MUST be present if the Encoded Payload Packet Key AVP is
      present. It is encoded as the attribute ?, mandatory, with length
      10.  This AVP contains the security parameters index for the
      payload security association defined within this message.

4.2 Renegotiate-Security-Association Message

   The Renegotiate-Security-Association message type is a new L2TP
   control message used to renegotiate a new security association.  It
   MAY be sent periodically while the control connection is established.
   To avoid certain replay attacks It SHOULD be sent when the sequence
   number of a control or call queue "rolls" back to 0.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    L2TP Control Message Header      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Renegotiate-Security-Association   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Encoded Control Message Key  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Control Message SPI          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Encoded Payload Packet Key   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Payload Packet SPI           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Renegotiate-Security-Association

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|        8              |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                0              |               ?               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Message Type AVP contains a Value of ?, mandatory, indicating
      Renegotiate-Security-Association.  This AVP MUST be present.  This
      message type indicates that the peer wishes to negotiate a new key
      for the payload stream, control stream, or both. If the message



Calhoun, Townsley        expires Janurary 1998                  [Page 9]


INTERNET DRAFT                                                 July 1997


      contains a new control message key AVP, then the message digest
      function is calculated using this new key for the renegotiation
      message itself.

   Encoded Control Message Key

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|        Length         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               ?               | Encoded Control Message Key...|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This AVP MAY be present. It is encoded as the attribute ?,
      mandatory, with the indicated number of bytes representing the
      encoded control message key. This AVP is optional. When present,
      the L2TP peer is indicating that the control message security
      association is being renegotiated. The new control message key to
      be used to perform the control message digest function is encoded
      with the previous control message key as follows:

      encodedCtrlMsgKey = MD5( IV | previousKey ) Xor ctrlMsgKey

      and decoded as follows:

      ctrlMsgKey = MD5( IV | previousKey ) Xor encodedCtrlMsgKey

   Control Message SPI

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|          10           |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               ?               |     Control Message SPI...    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  .... (4 bytes)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This AVP MUST be present if the Encoded Control Message Key AVP is
      present. It is encoded as the attribute ?, mandatory, with length
      10.  This AVP contains the security parameters index for the
      control channel security association defined within this message.

   Encoded Payload Packet Key

       0                   1                   2                   3



Calhoun, Townsley        expires Janurary 1998                 [Page 10]


INTERNET DRAFT                                                 July 1997


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|        Length         |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               ?               | Encoded Payload Packet Key... |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This AVP MAY be present. It is encoded as the attribute ?,
      mandatory, with the indicated number of bytes representing the
      encoded payload packet key. This AVP is optional. When present,
      the L2TP peer is indicating that the payload packet security
      association is being renegotiated. The new payload packet key to
      be used to perform the payload packet digest function is encoded
      with the previous payload packet key as follows:

      encodedPayloadPktKey = MD5( IV | previousKey ) Xor payloadPktKey

      and decoded as follows:

      payloadPktKey = MD5( IV | previousKey ) Xor encodedPayloadPktKey

   Payload Packet SPI

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|          10           |               0               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               ?               |      Payload Packet SPI...    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  .... (4 bytes)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This AVP MUST be present if the Encoded Payload Packet Key AVP is
      present. It is encoded as the attribute ?, mandatory, with length
      10.  This AVP contains the security parameters index for the
      payload security association defined within this message.

5.0 Acknowledgments

   We would like to thank Baiju Patel from Intel Coproration and Sumit
   Vakil from 3COM Corporation for their assistance.

6.0 Contacts

   Pat R. Calhoun
   3Com Corporation
   1800 Central Ave.



Calhoun, Townsley        expires Janurary 1998                 [Page 11]


INTERNET DRAFT                                                 July 1997


   Mount Prospect, Il, 60056
   pcalhoun@usr.com
   (847) 342-6898

   W. Mark Townsley
   IBM Corporation
   700 Park Office Drive
   Research Triangle Park, NC 27709
   wmt@raleigh.ibm.com
   (919) 543-7522

7.0 References

   [1] K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J. Taarud,
       A. J. Valencia, W. Verthein "Layer Two Tunneling Protocol
       (L2TP)", Internet draft, June 1997

   [2] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661,
       07/21/1994

   [3] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for
       Message Authentication", RFC 2104, February 1997

   [4] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321,
       04/16/1992

   [5] D. Eastlake III, S. Crocker, J. Schiller, "Randomness
       Recommendations for Security", RFC 1750, December 1994


Appendix A: Additional Recommendations for secure L2TP implementations

   This appendix identifies some potential security problems with the
   L2TP and includes reccommendations for ways to avoid the associated
   risks. We do not identify any new protocol entities here, rather
   provide implementation advice for greater security when using L2TP.

A.1 Proxy CHAP

   While proxy CHAP provides a useful method of forwarding the challenge
   issued by the LAC and the response from the client to the LNS for
   final processing, there is a potential security risk if the operator
   of the LNS does not FULLY trust the operator of the LAC. Granted,
   there must be some level of trust between these two entities to setup
   billing practices, etc. However, allowing the LAC to control the
   challenge gives the operator of the LAC a very simple (and perhaps
   tempting) way to impersonate any user which has been tunneled through
   her system in the past (given that the user's password has not



Calhoun, Townsley        expires Janurary 1998                 [Page 12]


INTERNET DRAFT                                                 July 1997


   changed in the home network). By simply replaying the
   challenge/response pair to the LNS in the proxy CHAP AVP, a malicious
   user can gain access as that user on the home network via the LNS at
   any time. This impersonated call can continue to exist undetected
   until a CHAP rechallenge is sent from the LNS to the client at which
   time the fake client will presumably fail to answer the challege
   correctly and be disconnected.

   Niether the protocol specified in this document nor IPSEC can counter
   against this kind of attack by a malicious, yet "trusted" LAC.
   However, the LNS can remedy this problem by simply issuing a CHAP
   rechallenge so that the challenge is issued by the LNS rather than
   the LAC. This makes it much more difficult for the LAC operator to
   spoof the CHAP authentication phase at your LNS, reducing
   vulnerabilty considerably.

   To implement this security feature, a CHAP rechallenge MUST be issued
   from the LNS in lieu of sending a CHAP SUCCESS based upon the proxy
   CHAP values sent from the LAC. If the proxy CHAP values sent from the
   LAC result in a CHAP FAILURE, there is no compelling reason to send
   the rechallenge unless you wish to give the client another "chance"
   at answering the challenge correctly.

A.2 Tunnel ID and Call ID selection

   As suggested in section 2.2, Tunnel IDs and Call IDs SHOULD be
   selected in a sufficiently random manner rather than sequentially or
   any other predictable order. Doing so helps prevent a malicious user
   who otherwise does not have access to packet traces to and from a LAC
   or LNS to guess the ID of an active session and attempt to hijack it.





















Calhoun, Townsley        expires Janurary 1998                 [Page 13]