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-l2tp-sec-02.txt < prev    next >
Text File  |  1997-10-10  |  25KB  |  647 lines
  1.  
  2.  
  3. PPP Working Group                                          Pat R. Calhoun
  4. INTERNET DRAFT                                           3Com Corporation
  5. Category: Internet Draft                                 W. Mark Townsley
  6. Title: draft-ietf-pppext-l2tp-sec-02.txt                  IBM Corporation
  7. Date: October 1997
  8.  
  9.  
  10.  
  11.                          Layer Two Tunneling Protocol "L2TP"
  12.                        Security Extensions for Non-IP networks
  13.  
  14.  
  15. Status of this Memo
  16.  
  17.    This  document  is  an  Internet-Draft.  Internet-Drafts  are  working
  18.    documents  of  the  Internet Engineering Task Force (IETF), its areas,
  19.    and its working groups.  Note that other groups  may  also  distribute
  20.    working documents as Internet-Drafts.
  21.  
  22.    Internet-Drafts are draft documents valid for a maximum of six months.
  23.    Internet-Drafts  may  be  updated,  replaced,  or  obsoleted  by other
  24.    documents at any time.  It is not appropriate to  use  Internet-Drafts
  25.    as  reference  material  or  to  cite  them  other than as a ``working
  26.    draft'' or ``work in progress.''
  27.  
  28.    To learn the current status of any Internet-Draft,  please  check  the
  29.    1id-abstracts.txt  listing  contained  in  the  Internet-Drafts Shadow
  30.    Directories on ds.internic.net,  nic.nordu.net,  ftp.nisc.sri.com,  or
  31.    munnari.oz.au.
  32.  
  33. Abstract
  34.  
  35.    The L2TP document [1] defines the base protocol  which  describes  the
  36.    method  of  tunneling  PPP [2] data. The L2TP document states that the
  37.    security mechanism used over an IP network is to use the IETF's  IPSEC
  38.    protocols.
  39.  
  40.    L2TP was designed in such a  way  as  to  be  able  to  run  over  any
  41.    underlying   layer  (i.e.  Frame  Relay,  ATM,  etc.).  This  document
  42.    specifies  extensions  to  the  L2TP  protocol  in  order  to  provide
  43.    authentication  and  integrity  of  individual  packets  in a tunneled
  44.    session over a  network  where  IPSEC  or  another  suitable  security
  45.    protocol is not available.
  46.  
  47. Table of Contents
  48.  
  49.       1.0 Introduction
  50.       1.1 Conventions
  51.       2.0 L2TP Security Header Format
  52.       3.0 Protection Against Attacks
  53.  
  54.  
  55. Calhoun, Townsley           expires April 1998                   [Page 1]
  56.  
  57.  
  58.  
  59. INTERNET DRAFT                                               October 1997
  60.  
  61.  
  62.       3.1 Denial of Service Attacks
  63.       3.2 Replay Attacks
  64.       3.3 Compromise of the Master Key
  65.       4.0 AVP Hiding
  66.       5.0 Security Association Negotiation
  67.       5.1 Renegotiate-Security-Association Message
  68.       5.2 Encoded Message Key
  69.       5.3 Message Security Parameter Index
  70.       6.0 Acknowledgments
  71.       7.0 Contacts
  72.       8.0 References
  73.       Appendix   A:   Additional   Recommendations   for   secure   L2TP
  74.    implementations
  75.  
  76. 1.0 Introduction
  77.  
  78.    The L2TP protocol specification states that the IPSEC  protocols  MUST
  79.    be  used  over  an  IP network for L2TP to operate in a secure manner.
  80.    However, L2TP may be run on a link layer that does not have a security
  81.    mechanism  such  as IPSEC available. In this case it becomes necessary
  82.    for L2TP to provide its own mechanism for packet level security.
  83.  
  84.    This document will describe how authentication and integrity  of  L2TP
  85.    packets  will be handled over networks where IPSEC or another suitable
  86.    security protocol does not exist. It does  not  intend  to  provide  a
  87.    mechanism  for encryption of packets. If data encryption is necessary,
  88.    then the  user  may  utilize  ECP  or  another  form  of  end  to  end
  89.    encryption.
  90.  
  91.    The  security  extensions  defined  here  also   provide   the   added
  92.    flexibility to negotiate security separately over the control and data
  93.    channels. This may be desirable in some situations, particularly where
  94.    processing  power  may  be at a minimum, but some level of security is
  95.    still desired.
  96.  
  97.    By design, several of the constructs used here draw upon  those  being
  98.    developed in the IPSEC working group.
  99.  
  100. 1.1 Conventions
  101.  
  102.    The following language conventions are used in the items  of  specifi-
  103.    cation in this document:
  104.  
  105.          o  MUST, SHALL, or MANDATORY -- This item is an absolute
  106.             requirement of the specification.
  107.  
  108.          o  SHOULD or RECOMMEND -- This item should generally be followed
  109.             for all but exceptional circumstances.
  110.  
  111.          o  MAY or OPTIONAL -- This item is truly optional and may be
  112.  
  113.  
  114. Calhoun, Townsley           expires April 1998                   [Page 2]
  115.  
  116.  
  117.  
  118. INTERNET DRAFT                                               October 1997
  119.  
  120.  
  121.             followed or ignored according to the needs of the
  122.             implementor.
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173. Calhoun, Townsley           expires April 1998                   [Page 3]
  174.  
  175.  
  176.  
  177. INTERNET DRAFT                                               October 1997
  178.  
  179.  
  180. 2.0 L2TP Security Header Format
  181.  
  182.    The L2TP Header has been modified as follows in order  to  accommodate
  183.    the new security extension.
  184.  
  185.     0                   1                   2                   3
  186.     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
  187.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  188.    |T|1|1|1|1|K|0|0|         | Ver |             Length            |
  189.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  190.    |           Tunnel ID           |            Call ID            |
  191.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  192.    |               Ns              |               Nr              |
  193.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  194.    |                     Initialization Vector                     |
  195.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  196.    |                     Initialization Vector                     |
  197.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  198.    |                     Initialization Vector                     |
  199.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  200.    |                     Initialization Vector                     |
  201.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  202.    |                   Security Parameters Index                   |
  203.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  204.    |                    Message Integrity Check                    |
  205.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  206.    |                    Message Integrity Check                    |
  207.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  208.    |                    Message Integrity Check                    |
  209.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  210.    |          Message Type AVP...                                  |
  211.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  212.    |                          ... (8 bytes)                        |
  213.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  214.  
  215. K Bit
  216.  
  217.    The 'K' bit MUST be set to one (1)  when  the  security  extension  is
  218.    present.  The behavior of the 'K' bit is identical on both the control
  219.    and data channel.
  220.  
  221. Initialization Vector (IV)
  222.  
  223.    This field MUST contain a cryptographically random 128 bit value [5].
  224.  
  225. Security Parameters Index (SPI)
  226.  
  227.    The SPI is an arbitrary four octet value. It is an unstructured opaque
  228.    index  which  is  used in conjunction with the Tunnel ID to identify a
  229.    particular Security Association. The behavior of the SPI is  identical
  230.  
  231.  
  232. Calhoun, Townsley           expires April 1998                   [Page 4]
  233.  
  234.  
  235.  
  236. INTERNET DRAFT                                               October 1997
  237.  
  238.  
  239.    on the control and data channel.
  240.  
  241.    The value inserted in this field is the locally  generated  SPI  value
  242.    which  references  the  key  used  in generating the Message Integrity
  243.    Check.
  244.  
  245.    Message Integrity Check (MIC)
  246.  
  247.    The MIC contains the result of the  HMAC-MD5-96  algorithm  [3][4]  as
  248.    applied  over  the  entire  L2TP  packet.  The  behavior of the MIC is
  249.    identical on the control and data channel.
  250.  
  251. 3.0 Protection Against Attacks
  252.  
  253.    This  section  will  define  certain  methods  of  protecting  against
  254.    specific known types of attacks.
  255.  
  256. 3.1 Denial of Service Attacks
  257.  
  258.    There currently exists a Denial of Service Attack whereby a  malicious
  259.    host  can issue a stream of Start-Control-Connection- Request messages
  260.    to an L2TP host on a network.
  261.  
  262.    Although  an  implementation  MUST  time-out  when  a   Start-Control-
  263.    Connection-Connected  has  not  been  received  within a given window,
  264.    there is still a possibility that if the messages were  received  fast
  265.    enough  the  L2TP  host  would  deplete its Control Connection Control
  266.    Blocks. This form of attack is  aggravated  when  the  malicious  host
  267.    sends the packets with a random source IP address.
  268.  
  269.    One form of protection against this attack is to have a local list  of
  270.    trusted  hosts, however this does not scale very well when providing a
  271.    roaming service from anywhere on the Internet.  Furthermore, enforcing
  272.    a  security  policy  based  on a source address is a very weak form of
  273.    protection.
  274.  
  275.    Another method of protecting against this form of attack  is  to  have
  276.    the  'K'  bit  set  in  the  initial  Start-Control-Connection-Request
  277.    message. The message would be signed with the common secret  (or  key,
  278.    see  below  for  more  details).  This  scheme  will  ensure that only
  279.    authenticated  Start-Control-Connection-Requests  will  be   accepted,
  280.    making  this  type of attack very inconvenient for a malicious user to
  281.    create.
  282.  
  283.    In order for this scheme to be successful, it is imperative  that  the
  284.    base  specification  require that a base implementation which does not
  285.    support any extensions MUST reject a  Start-Control-Connection-Request
  286.    message with a 'K' bit set.
  287.  
  288. 3.2 Replay Attacks
  289.  
  290.  
  291. Calhoun, Townsley           expires April 1998                   [Page 5]
  292.  
  293.  
  294.  
  295. INTERNET DRAFT                                               October 1997
  296.  
  297.  
  298.    One common attack is the replay attack. This requires that a malicious
  299.    user gain access to the network where packets are routed.
  300.  
  301.    There are two different types of replay attacks in  the  current  L2TP
  302.    protocol. The first takes advantage of the fact that since a secret is
  303.    a long lived key (known as the  master  key),  a  malicious  user  can
  304.    retrieve  the  Stop-Control-Connection-Request  message  from two L2TP
  305.    peers and replay it at a later date when  an  L2TP  tunnel  is  active
  306.    between both peers.
  307.  
  308.    This form of attack is  further  complicated  by  the  fact  that  the
  309.    malicious  user must inject the packet when the sequence number in the
  310.    replayed packet is within the window of  the  receiver.  This  can  be
  311.    achieved  using  a  brute  force type attack by constantly sending the
  312.    packet until the L2TP host accepts it. One more complication  for  the
  313.    malicious  user  is the fact that the Tunnel and Call identifiers MUST
  314.    be the same in the new session being attacked. This is  possible,  but
  315.    improbable  if  the Tunnel and Call IDs are selected in a sufficiently
  316.    random manner (while L2TP does not  specify  a  method  for  selecting
  317.    Tunnel  and  Call  IDs,  we  reccommend  choosing  a method that is as
  318.    unpredictable as  possible  to  help  guard  against  replay  attacks,
  319.    regardless if a security protocol is being utilized over the link).
  320.  
  321.    The second type of attack occurs when a user attempts to  replay  data
  322.    packets  being  tunneled.  An  example of a malicious packet to replay
  323.    would be a LCP Terminate Request message from a previous  session.  In
  324.    this  case,  again,  the Tunnel and the Call IDs MUST be identical for
  325.    the L2TP peer to accept the packet.
  326.  
  327.    However, if a malicious user was  to  simply  snoop  the  network  and
  328.    replay   valid   data  packets  from  the  current  session  it  could
  329.    potentially create some form of denial of service for the user. A good
  330.    example  of  such  a  packet would be a TCP FIN packet (which are very
  331.    common when using the WEB which have  many  short-lived  connections).
  332.    Since  most  TCP  implementations  do not have random initial sequence
  333.    numbers, this is a very simple attack.
  334.  
  335.    In order to protect against such an attack it is recommended that  the
  336.    L2TP  flow  control  mechanism  be enabled on the data path. This will
  337.    offer protection since a replay packet would only be accepted once the
  338.    window "rolled" over.
  339.  
  340. 3.3 Compromise of the Master Key
  341.  
  342.    Since tunnels may be long-lived and frequent, it is possible  for  the
  343.    master  key  to be compromised. A malicious user could gain many valid
  344.    samples and given enough resources could guess the master key. This is
  345.    a very serious problem which must be addressed.
  346.  
  347.    One simple and effective method to protect against  this  is  to  have
  348.  
  349.  
  350. Calhoun, Townsley           expires April 1998                   [Page 6]
  351.  
  352.  
  353.  
  354. INTERNET DRAFT                                               October 1997
  355.  
  356.  
  357.    both L2TP peers generate a session key when a tunnel is created.  This
  358.    key  would  be transmitted in the Start-Control-Connection-Request and
  359.    the appropriate  -Reply  message.  Furthermore,  an  L2TP  peer  could
  360.    generate  a  new  key  whenever its sequence number "rolls" over. This
  361.    would create a  new  security  association  between  both  peers,  and
  362.    protect against compromise of the master key.
  363.  
  364.    This scheme would also protect against the replay of the  data  packet
  365.    described  above  since  the  key  would  be changed once the Sequence
  366.    number reached zero, making the replayed packet non- authenticated.
  367.  
  368. 4.0 AVP Hiding
  369.  
  370.    Document [1] states that a  shared  secret  that  exists  between  the
  371.    tunnel  peers is used for the AVP Hiding algorithm. However when using
  372.    this extension on the control channel, the shared secret is only  used
  373.    to "hide" the initial control and payload channel key.
  374.  
  375.    All subsequent AVP hiding uses the  key  instead  of  the  shared  (or
  376.    master)  key  (including  any  other  AVPs  in  the  SCCRQ  and  SCCRP
  377.    messages). This means that the key renegotiation  procedure  uses  the
  378.    old key to hide the new key.
  379.  
  380. 5.0 Security Association Negotiation
  381.  
  382.    This section will define the new  message  type  and  AVPs  which  are
  383.    required  for  the  security extensions of the L2TP protocol. The AVPs
  384.    allow designation of a Key for control messages, payload messages,  or
  385.    both. The Keys may or may not be the same for each.
  386.  
  387. 5.1 Renegotiate-Security-Association (RSA)
  388.  
  389.    The  Renegotiate-Security-Association  message  type  is  a  new  L2TP
  390.    control  message  used  to renegotiate a new security association.  It
  391.    MAY be sent periodically while the control connection is  established.
  392.    To  avoid certain replay attacks It SHOULD be sent before the sequence
  393.    number of a control or call queue "rolls" back to 0.
  394.  
  395.    If the CallId field in the L2TP header was set to a  zero  value,  the
  396.    key is being renegotiated for the control channel. If a non-zero value
  397.    was found the key is being renegotiated for the payload channel.
  398.  
  399.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  400.    |    L2TP Control Message Header      |
  401.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  402.    |  Renegotiate-Security-Association   |
  403.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  404.    |  Encoded Control Message Key  |
  405.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  406.    |  Control Message SPI          |
  407.  
  408.  
  409. Calhoun, Townsley           expires April 1998                   [Page 7]
  410.  
  411.  
  412.  
  413. INTERNET DRAFT                                               October 1997
  414.  
  415.  
  416.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  417.    |  Encoded Payload Packet Key   |
  418.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  419.    |  Payload Packet SPI           |
  420.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  421.  
  422.    Renegotiate-Security-Association
  423.  
  424.        0                   1                   2                   3
  425.        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
  426.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  427.       |1|0|0|0|        8              |               0               |
  428.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  429.       |                0              |               17              |
  430.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  431.  
  432.       The Message Type AVP contains a Value of 17, mandatory,  indicating
  433.       Renegotiate-Security-Association.   This AVP MUST be present.  This
  434.       message type indicates that the peer wishes to negotiate a new  key
  435.       for the payload stream or control stream. If the message contains a
  436.       new key for the control channel  the  message  digest  function  is
  437.       calculated  using  the  decrypted  form of the key found within the
  438.       Encoded Message Key AVP found in this message.
  439.  
  440. 5.2 Encoded Message Key
  441.  
  442.    The Encoded Message Key AVP may be  present  in  SCCRQ,  SCCRP,  OCRQ,
  443.    OCRP, ICRQ and ICRP. This message is used to inform the tunnel peer of
  444.    a key to be used for the generation of the MIC (shown above)  as  well
  445.    as the hiding of all attributes [1].
  446.  
  447.    The presence of this attribute in the SCCRQ and SCCRP  indicates  that
  448.    the  key  is  being  setup  for the control channel. When found in the
  449.    OCRQ, OCRP, ICRQ or the ICRP, the key is to be used  for  the  payload
  450.    channel which is referenced by the Assigned CallId AVP.
  451.  
  452.    Note that there is a direct relationship between this key and the  SPI
  453.    value passed in the same message.
  454.  
  455.    When a key is being negotiated on the control channel, any AVP  hiding
  456.    MUST use the decrypted form of this key as the shared secret [1].
  457.  
  458.        0                   1                   2                   3
  459.        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
  460.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  461.       |1|1|0|0|        Length         |               0               |
  462.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  463.       |               38              |    Encoded Message Key...     |
  464.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  465.  
  466.  
  467.  
  468. Calhoun, Townsley           expires April 1998                   [Page 8]
  469.  
  470.  
  471.  
  472. INTERNET DRAFT                                               October 1997
  473.  
  474.  
  475.       This AVP MAY be present in the messages shown above. It is  encoded
  476.       as  the attribute 38, mandatory, with the indicated number of bytes
  477.       representing the encoded message key. This AVP MUST be  hidden  and
  478.       is  optional.  When  present,  the  L2TP  peer  is  indicating that
  479.       authentication is required on all control or payload packets.
  480.  
  481. 5.3 Message Security Parameter Index
  482.  
  483.       The SPI is used as a  reference  to  a  session  key.  The  locally
  484.       generated  SPI  value MUST be inserted in the SPI field of the L2TP
  485.       header to reference the  appropriate  KEY  (found  in  the  Encoded
  486.       Message Key AVP).
  487.  
  488.       When renegotiating a new key,  a  new  SPI  MUST  be  generated  to
  489.       correctly identify the key. The old key MUST become invalidated. On
  490.       the payload channel, the peer MAY retain the old SPI  for  a  short
  491.       time  in  order  to  authenticate packets which are received out of
  492.       order.
  493.  
  494.        0                   1                   2                   3
  495.        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
  496.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  497.       |1|0|0|0|          10           |               0               |
  498.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  499.       |               39              |     Control Message SPI...    |
  500.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  501.       |  .... (4 bytes)               |
  502.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  503.  
  504.       This AVP MUST be present if the Encoded Message Key AVP is present.
  505.       It is encoded as the attribute 29, mandatory, with length 10.  This
  506.       AVP is optional and contains the security parameters index for  the
  507.       control or the payload channel.
  508.  
  509.  
  510. 6.0 Acknowledgments
  511.  
  512.    We would like to thank Baiju Patel from Intel  Coproration  and  Sumit
  513.    Vakil from 3COM Corporation for their assistance.
  514.  
  515. 7.0 Contacts
  516.  
  517.    Pat R. Calhoun
  518.    3Com Corporation
  519.    1800 Central Ave.
  520.    Mount Prospect, Il, 60056
  521.    pcalhoun@usr.com
  522.    (847) 342-6898
  523.  
  524.    W. Mark Townsley
  525.  
  526.  
  527. Calhoun, Townsley           expires April 1998                   [Page 9]
  528.  
  529.  
  530.  
  531. INTERNET DRAFT                                               October 1997
  532.  
  533.  
  534.    IBM Corporation
  535.    700 Park Office Drive
  536.    Research Triangle Park, NC 27709
  537.    wmt@raleigh.ibm.com
  538.    (919) 543-7522
  539.  
  540. 8.0 References
  541.  
  542.    [1] K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J. Taarud,
  543.        A. J. Valencia, W. Verthein, W.M. Townsley, B. Palter,
  544.        A. Rubens "Layer Two Tunneling Protocol (L2TP)",
  545.        Internet draft, October 1997
  546.  
  547.    [2] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661,
  548.        07/21/1994
  549.  
  550.    [3] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for
  551.        Message Authentication", RFC 2104, February 1997
  552.  
  553.    [4] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321,
  554.        04/16/1992
  555.  
  556.    [5] D. Eastlake III, S. Crocker, J. Schiller, "Randomness
  557.        Recommendations for Security", RFC 1750, December 1994
  558.  
  559.  
  560. Appendix A: Additional Recommendations for secure L2TP implementations
  561.  
  562.    This appendix identifies some potential  security  problems  with  the
  563.    L2TP  and  includes  reccommendations for ways to avoid the associated
  564.    risks. We do not identify  any  new  protocol  entities  here,  rather
  565.    provide implementation advice for greater security when using L2TP.
  566.  
  567. A.1 Proxy CHAP
  568.  
  569.    While proxy CHAP provides a useful method of forwarding the  challenge
  570.    issued  by  the  LAC  and  the response from the client to the LNS for
  571.    final processing, there is a potential security risk if  the  operator
  572.    of  the  LNS  does  not  FULLY trust the operator of the LAC. Granted,
  573.    there must be some level of trust between these two entities to  setup
  574.    billing  practices,  etc.  However,  allowing  the  LAC to control the
  575.    challenge gives the operator of the LAC a  very  simple  (and  perhaps
  576.    tempting)  way to impersonate any user which has been tunneled through
  577.    her system in the past (given that the user's password has not changed
  578.    in  the home network). By simply replaying the challenge/response pair
  579.    to the LNS in the proxy CHAP AVP, a malicious user can gain access  as
  580.    that  user  on  the  home  network  via  the  LNS  at  any  time. This
  581.    impersonated call can  continue  to  exist  undetected  until  a  CHAP
  582.    rechallenge  is sent from the LNS to the client at which time the fake
  583.    client will presumably fail to answer the challege  correctly  and  be
  584.  
  585.  
  586. Calhoun, Townsley          expires April 1998                   [Page 10]
  587.  
  588.  
  589.  
  590. INTERNET DRAFT                                               October 1997
  591.  
  592.  
  593.    disconnected.
  594.  
  595.    Neither the protocol specified in this document nor IPSEC can  counter
  596.    against  this  kind  of  attack  by  a  malicious,  yet "trusted" LAC.
  597.    However, the LNS can remedy this problem  by  simply  issuing  a  CHAP
  598.    rechallenge so that the challenge is issued by the LNS rather than the
  599.    LAC. This makes it much more difficult for the LAC operator  to  spoof
  600.    the  CHAP  authentication  phase  at  your  LNS, reducing vulnerabilty
  601.    considerably.
  602.  
  603.    To implement this security feature, a CHAP rechallenge MUST be  issued
  604.    from  the  LNS  in lieu of sending a CHAP SUCCESS based upon the proxy
  605.    CHAP values sent from the LAC. If the proxy CHAP values sent from  the
  606.    LAC  result  in  a CHAP FAILURE, there is no compelling reason to send
  607.    the rechallenge unless you wish to give the client another "chance" at
  608.    answering the challenge correctly.
  609.  
  610. A.2 Tunnel ID and Call ID selection
  611.  
  612.    As suggested in section  2.2,  Tunnel  IDs  and  Call  IDs  SHOULD  be
  613.    selected  in  a sufficiently random manner rather than sequentially or
  614.    any other predictable order. Doing so helps prevent a  malicious  user
  615.    who  otherwise does not have access to packet traces to and from a LAC
  616.    or LNS to guess the ID of an active session and attempt to hijack it.
  617.  
  618.    However, when using the L2TP Security extensions this  requirement  is
  619.    no  longer  required  since the level of authentication this extension
  620.    provides does not allow a malicious user to simply guess a Tunnel  and
  621.    Call Id.
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645. Calhoun, Townsley          expires April 1998                   [Page 11]
  646.  
  647.