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-00.txt < prev    next >
Text File  |  1997-06-24  |  17KB  |  425 lines
  1.      
  2. PPP Working Group                                          Pat R. Calhoun 
  3. INTERNET-DRAFT                                           3Com Corporation 
  4. Category: Internet Draft                                 W. Mark Townsley 
  5. Title: draft-ietf-pppext-l2tp-sec-00.txt                  IBM Corporation 
  6. Date: June 1997
  7. Expires: December 1997     
  8.      
  9.                   Layer Two Tunneling Protocol "L2TP"
  10.                  Security Extensions for Non-IP 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 spec states that the 
  35.    security mechanism used over an IP network is to use the IETF's 
  36.    IPSEC 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 specifies 
  40.    extensions to the L2TP protocol in order to provide authentication
  41.    and integrity of individual packets in a tunneled session over a 
  42.    non-IP network. It does not intend to provide a mechanism for 
  43.    encryption of packets. 
  44.      
  45.      
  46.      
  47.      
  48.      
  49.      
  50.      
  51.      
  52. Calhoun                    expires January 1997                  [Page 1] 
  53.  
  54. INTERNET DRAFT                                                  June 1997
  55.      
  56. 1.0 Introduction
  57.      
  58.    The L2TP protocol specification describes that the IPSEC protocols 
  59.    MUST be used over an IP network. However, since L2TP can work over 
  60.    ANY link layer, there is no method of ensuring security over those 
  61.    links (if that link layer does not in turn provide its own security 
  62.    protocol).
  63.      
  64.    This document will describe how authentication of L2TP packets will 
  65.    be handled over non-IP networks. 
  66.      
  67.      
  68. 1.1 Conventions
  69.      
  70.    The following language conventions are used in the items of specifi- 
  71.    cation in this document:
  72.      
  73.       o   MUST, SHALL, or MANDATORY -- This item is an absolute
  74.          requirement of the specification.
  75.      
  76.       o   SHOULD or RECOMMEND -- This item should generally be followed
  77.          for all but exceptional circumstances.
  78.      
  79.       o   MAY or OPTIONAL -- This item is truly optional and may be
  80.          followed or ignored according to the needs of the implementor.
  81.      
  82.      
  83.      
  84.      
  85.      
  86.      
  87.      
  88.      
  89.      
  90.      
  91.      
  92.      
  93.      
  94.      
  95.      
  96.      
  97.      
  98.      
  99.      
  100.      
  101.      
  102.      
  103.      
  104.      
  105. Calhoun                    expires January 1997                  [Page 2] 
  106.  
  107. INTERNET DRAFT                                                  June 1997
  108.      
  109.      
  110. 2.0 L2TP Security Header Format
  111.      
  112.    The L2TP Header has been modified in order to accommodate the new
  113.    Authentication extension. The header has a 'K' bit which indicates
  114.    that the authentication extension is present in the header. This 
  115.    header is formatted:
  116.    
  117.     0                   1                   2                   3
  118.     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
  119.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  120.    |T|1|1|1|1|K|0|           | Ver |             Length            | 
  121.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  122.    |           Tunnel ID           |            Call ID            | 
  123.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  124.    |               Ns              |               Nr              | 
  125.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  126.    |                     Initialization Vector                     | 
  127.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  128.    |                     Initialization Vector                     | 
  129.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  130.    |                     Initialization Vector                     | 
  131.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  132.    |                     Initialization Vector                     | 
  133.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  134.    |                    Message Integrity Check                    | 
  135.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  136.    |                    Message Integrity Check                    | 
  137.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  138.    |                    Message Integrity Check                    | 
  139.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  140.    |          Message Type AVP...                                  | 
  141.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  142.    |                          ... (8 bytes)                        | 
  143.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  144.    
  145.    In order for the Authentication Extension to be present, the 'K'
  146.    bit MUST be 1. The Initialization Vector field MUST contain a 
  147.    random 128 bit value. The MIC (Message Integrity Check) contains 
  148.    the most significant 96 bits of the HMAC-MD5 algorithm [3][4].
  149.    
  150.    The behavior of the 'K' bit is identical on both the control and
  151.    data channel.
  152.      
  153.      
  154.      
  155.      
  156.      
  157.      
  158. Calhoun                    expires January 1997                  [Page 3] 
  159.  
  160. INTERNET DRAFT                                                  June 1997
  161.      
  162.      
  163. 2.0 Protection Against Attacks
  164.      
  165.    This section will define certain methods of protecting against 
  166.    specific known types of attacks.
  167.      
  168.    2.1 Denial of Service Attacks
  169.      
  170.       There currently exists a Denial of Service Attack whereby a 
  171.       malicious host can issue a stream of 
  172.       Start-Control-Connection-Request messages to an L2TP host on a 
  173.       network.
  174.      
  175.       Although an implementation MUST time-out when a 
  176.       Start-Control-Connection-Connected has not been received within a
  177.       given window, there is still a possibility that if the messages 
  178.       were received fast enough the L2TP host would deplete its Control 
  179.       Connection Control Blocks. This form of attack is aggravated when 
  180.       the malicious host sends the packets with a random source IP 
  181.       address.
  182.      
  183.       One form of protection against this attack is to have a local list
  184.       of trusted hosts, however this does not scale very well when 
  185.       providing a roaming service from anywhere on the Internet. 
  186.       Furthermore, enforcing a security policy based on a source address 
  187.       is a very weak form of protection.
  188.      
  189.       Another method of protecting against this form of attack is to have
  190.       the 'K' bit set in the initial Start-Control-Connection-Request 
  191.       message. The message would be signed with the common secret (or 
  192.       key, see below for more details). This scheme will ensure that 
  193.       only authenticated Start-Control-Connection-Requests will be 
  194.       accepted, making this type of attack very inconvenient for a 
  195.       malicious user to create.
  196.      
  197.       In order for this scheme to be successful, it is imperative that 
  198.       the base specification require that a base implementation which 
  199.       does not support any extensions MUST reject a 
  200.       Start-Control-Connection-Request message with a 'K' bit set.
  201.      
  202.      
  203.    2.2 Replay Attacks
  204.      
  205.       One common attack is the replay attack. This requires that a 
  206.       malicious user gain access to the network where packets are routed. 
  207.      
  208.      
  209.      
  210.      
  211. Calhoun                    expires January 1997                  [Page 4] 
  212.  
  213. INTERNET DRAFT                                                  June 1997
  214.      
  215.      
  216.       There are two different types of replay attacks in the current L2TP
  217.       protocol. The first is that since a secret is a long lived key 
  218.       (known as the master key), a malicious user can retrieve the 
  219.       Stop-Control-Connection-Request message from two L2TP peers and 
  220.       replay it at a later date when an L2TP tunnel is active between 
  221.       both peers. 
  222.      
  223.       This form of attack is further complicated by the fact that the 
  224.       malicious user must inject the packet when the sequence number in 
  225.       the replayed packet is within the window of the receiver. This can 
  226.       be achieved using a brute force type attack by constantly sending 
  227.       the packet until the L2TP host accepts it. One more complication 
  228.       for the malicious user is the fact that the Tunnel and Call 
  229.       identifiers MUST be the same in the new session being attacks. This 
  230.       is not impossible, but improbable if the Tunnel and Call IDs are 
  231.       randomly generated.
  232.      
  233.       The second type of attack occurs when a user attempts to replay
  234.       data packets being tunneled. One good example of a packet to 
  235.       replay would be a LCP Terminate Request message from a previous 
  236.       session. In this case, again, the Tunnel and the Call IDs MUST be 
  237.       identical for the L2TP peer to accept the packet.
  238.      
  239.       However, if a malicious user was to simply snoop the network and
  240.       replay valid data packets from the current session it could 
  241.       potentially create some form of denial of service for the user. A 
  242.       good example of such a packet would be a TCP FIN packet (which are 
  243.       very common when using the WEB which have many short-lived 
  244.       connections). Since most TCP implementations do not have random 
  245.       initial sequence numbers, this is a very simple attack.
  246.      
  247.       In order to protect against such an attack it is recommended that
  248.       the L2TP flow control mechanism be enabled on the data path. This 
  249.       will offer protection since a replay packet would only be accepted 
  250.       once the window "rolled" over.
  251.      
  252.    2.3 Compromise of the Master Key
  253.      
  254.       Since tunnels may be long-lived and frequent, it is possible for 
  255.       the master key to be compromised. A malicious user could gain many
  256.       valid samples and given enough resources could guess the master 
  257.       key. This is a very serious problem which must be addressed.
  258.      
  259.       One possible and simple method to protect against this is to have
  260.       both L2TP peers generate a session key when a tunnel is created. 
  261.       This key would be transmitted in the 
  262.      
  263.      
  264. Calhoun                    expires January 1997                  [Page 5] 
  265.  
  266. INTERNET DRAFT                                                  June 1997
  267.      
  268.      
  269.       Start-Control-Connection-Request and the appropriate -Reply 
  270.       message. Furthermore, a L2TP host would generate a new key 
  271.       whenever it's Sn value would "roll" over. This would create a new 
  272.       security association between both peers, and protect against 
  273.       compromise of the master key.
  274.      
  275.       This scheme would also protect against the replay of the data 
  276.       packet described above since the key would be changed once the 
  277.       Sequence number reached zero, making the replayed packet non- 
  278.       authenticated.
  279.      
  280. 3.0 Security Association Negotiation
  281.      
  282.    This section will define the new message type and AVP which are 
  283.    required for the security extensions of the L2TP protocol.
  284.  
  285.    3.1 Start-Control-Connection-Request/-Reply
  286.  
  287.       Session Key 
  288.  
  289.       0                   1                   2                   3
  290.       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 
  291.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  292.       |1|0|0|0|        Length         |               0               | 
  293.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  294.       |               ?               |    Encoded Session Key...     | 
  295.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  296.      
  297.       A new AVP MAY be present in the tunnel initiation messages. When
  298.       present, the L2TP peer is indicating that a session key is to be
  299.       used to perform the message digest functions.
  300.  
  301.       It is encoded as the Attribute ?, Mandatory, with the indicated 
  302.       number of bytes representing the session key.  This AVP is 
  303.       optional.
  304.      
  305.       When present the MIC in the L2TP header is computed using the 
  306.       decoded Session Key and the key is encoded as follows:
  307.      
  308.       encodedKey = MD5( IV | Master Key ) Xor Session Key
  309.  
  310.       and decoded as follows:
  311.  
  312.       decodedKey = MD5( IV | Master Key ) Xor encodedKey
  313.  
  314.      
  315.  
  316.  
  317. Calhoun                    expires January 1997                  [Page 6] 
  318.  
  319. INTERNET DRAFT                                                  June 1997
  320.  
  321.  
  322.    3.1 Renegotiate-Security-Association
  323.      
  324.       The Renegotiate-Security-Association message type is an L2TP 
  325.       control message used to renegotiate a new security association. 
  326.       It can be sent after establishment of the control connection. 
  327.      
  328.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  329.       |    L2TP Control Message Header      | 
  330.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  331.       |  Renegotiate Security Association   | 
  332.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  333.       | Session Key   |
  334.       +-+-+-+-+-+-+-+-+
  335.      
  336.       Renegotiate-Security-Association
  337.      
  338.        0                   1                   2                   3
  339.        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
  340.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  341.       |1|0|0|0|        8              |               0               | 
  342.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  343.       |                0              |               ?               | 
  344.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  345.      
  346.       The Message Type AVP contains a Value of ?, indicating 
  347.       Renegotiate-Security-Association.  The Flags indicate a mandatory 
  348.       option.  Details associated with this security renegotiation 
  349.       session follow in additional AVP's within the packet.
  350.    
  351.      
  352.       Session Key 
  353.      
  354.      
  355.       0                   1                   2                   3
  356.       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 
  357.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  358.       |1|0|0|0|        Length         |               0               | 
  359.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  360.       |               ?               |    Encoded Session Key...     | 
  361.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  362.      
  363.       The Session Key AVP contains a new session key for a control 
  364.       channel. It is encoded as the Attribute ?, Mandatory, with the 
  365.       indicated number of bytes representing the session key.  This AVP 
  366.       is mandatory.
  367.  
  368.  
  369.  
  370. Calhoun                    expires January 1997                  [Page 7] 
  371.  
  372. INTERNET DRAFT                                                  June 1997
  373.  
  374.  
  375.       When present the MIC in the L2TP header is computed using the 
  376.       decoded Session Key and the key is encoded as follows:
  377.      
  378.       encodedKey = MD5( IV | Previous Key ) Xor Session Key
  379.  
  380.       and decoded as follows:
  381.  
  382.       decodedKey = MD5( IV | Previous Key ) Xor encodedKey
  383.      
  384.      
  385. 4.0 Acknowledgments
  386.      
  387.    I would like to thank Baiju Patel from Intel Corp. and Sumit Vakil 
  388.    for their assistance. 
  389.      
  390.      
  391. 5.0 Contacts
  392.      
  393.    Pat R. Calhoun
  394.    3Com Corporation
  395.    1800 Central Ave.
  396.    Mount Prospect, Il, 60056
  397.    pcalhoun@usr.com
  398.    (847) 342-6898
  399.      
  400.    W. Mark Townsley
  401.    IBM Corporation
  402.    700 Park Office Drive
  403.    Research Triangle Park, NC 27709
  404.    wmt@raleigh.ibm.com
  405.    (919) 543-7522
  406.      
  407.      
  408. 6.0 References
  409.      
  410.      
  411.    [1] K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J. Taarud, 
  412.        A. J. Valencia, W. Verthein "Layer Two Tunneling Protocol (L2TP)", 
  413.        Internet draft, March 1997
  414.      
  415.    [2] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661,
  416.        07/21/1994
  417.      
  418.    [3] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for
  419.        Message Authentication", RFC 2104, February 1997
  420.      
  421.    [4] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, 
  422.        04/16/1992
  423. Calhoun                    expires January 1997                  [Page 8] 
  424. É
  425.