Internet Draft PPP Working Group Pat R. Calhoun INTERNET-DRAFT 3Com Corporation Category: Internet Draft W. Mark Townsley Title: draft-ietf-pppext-l2tp-sec-00.txt IBM Corporation Date: June 1997 Expires: December 1997 Layer Two Tunneling Protocol "L2TP" Security Extensions for Non-IP 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 spec 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 non-IP network. It does not intend to provide a mechanism for encryption of packets. Calhoun expires January 1997 [Page 1] INTERNET DRAFT June 1997 1.0 Introduction The L2TP protocol specification describes that the IPSEC protocols MUST be used over an IP network. However, since L2TP can work over ANY link layer, there is no method of ensuring security over those links (if that link layer does not in turn provide its own security protocol). This document will describe how authentication of L2TP packets will be handled over non-IP networks. 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. o MAY or OPTIONAL -- This item is truly optional and may be followed or ignored according to the needs of the implementor. Calhoun expires January 1997 [Page 2] INTERNET DRAFT June 1997 2.0 L2TP Security Header Format The L2TP Header has been modified in order to accommodate the new Authentication extension. The header has a 'K' bit which indicates that the authentication extension is present in the header. This header is formatted: 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| | Ver | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ns | Nr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initialization Vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initialization Vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initialization Vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initialization Vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Integrity Check | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Integrity Check | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Integrity Check | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type AVP... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... (8 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In order for the Authentication Extension to be present, the 'K' bit MUST be 1. The Initialization Vector field MUST contain a random 128 bit value. The MIC (Message Integrity Check) contains the most significant 96 bits of the HMAC-MD5 algorithm [3][4]. The behavior of the 'K' bit is identical on both the control and data channel. Calhoun expires January 1997 [Page 3] INTERNET DRAFT June 1997 2.0 Protection Against Attacks This section will define certain methods of protecting against specific known types of attacks. 2.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. 2.2 Replay Attacks One common attack is the replay attack. This requires that a malicious user gain access to the network where packets are routed. Calhoun expires January 1997 [Page 4] INTERNET DRAFT June 1997 There are two different types of replay attacks in the current L2TP protocol. The first is 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 attacks. This is not impossible, but improbable if the Tunnel and Call IDs are randomly generated. The second type of attack occurs when a user attempts to replay data packets being tunneled. One good example of a 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. 2.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. One possible and simple 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 Calhoun expires January 1997 [Page 5] INTERNET DRAFT June 1997 Start-Control-Connection-Request and the appropriate -Reply message. Furthermore, a L2TP host would generate a new key whenever it's Sn value would "roll" 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. 3.0 Security Association Negotiation This section will define the new message type and AVP which are required for the security extensions of the L2TP protocol. 3.1 Start-Control-Connection-Request/-Reply Session 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 Session Key... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A new AVP MAY be present in the tunnel initiation messages. When present, the L2TP peer is indicating that a session key is to be used to perform the message digest functions. It is encoded as the Attribute ?, Mandatory, with the indicated number of bytes representing the session key. This AVP is optional. When present the MIC in the L2TP header is computed using the decoded Session Key and the key is encoded as follows: encodedKey = MD5( IV | Master Key ) Xor Session Key and decoded as follows: decodedKey = MD5( IV | Master Key ) Xor encodedKey Calhoun expires January 1997 [Page 6] INTERNET DRAFT June 1997 3.1 Renegotiate-Security-Association The Renegotiate-Security-Association message type is an L2TP control message used to renegotiate a new security association. It can be sent after establishment of the control connection. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Renegotiate Security Association | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Key | +-+-+-+-+-+-+-+-+ 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 ?, indicating Renegotiate-Security-Association. The Flags indicate a mandatory option. Details associated with this security renegotiation session follow in additional AVP's within the packet. Session 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 Session Key... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Session Key AVP contains a new session key for a control channel. It is encoded as the Attribute ?, Mandatory, with the indicated number of bytes representing the session key. This AVP is mandatory. Calhoun expires January 1997 [Page 7] INTERNET DRAFT June 1997 When present the MIC in the L2TP header is computed using the decoded Session Key and the key is encoded as follows: encodedKey = MD5( IV | Previous Key ) Xor Session Key and decoded as follows: decodedKey = MD5( IV | Previous Key ) Xor encodedKey 4.0 Acknowledgments I would like to thank Baiju Patel from Intel Corp. and Sumit Vakil for their assistance. 5.0 Contacts Pat R. Calhoun 3Com Corporation 1800 Central Ave. 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 6.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, March 1997 [2] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 7/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, 4/16/1992 Calhoun expires January 1997 [Page 8]