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