[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05                                             
     PPPEXT Working Group                                       Baiju Patel
     INTERNET-DRAFT                                                   Intel
     Category: Standards Track                                Bernard Aboba
     <draft-ietf-pppext-l2tp-security-02.txt>                     Microsoft
     22 May 1998
     
     
                           Securing L2TP using IPSEC
     
     
     1.  Status of this Memo
     
     This document is an Internet-Draft.  Internet-Drafts are working docu-
     ments 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
     and  may  be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as  reference  mate-
     rial or to cite them other than as ``work in progress.''
     
     To view the entire list of current Internet-Drafts, please check
     the "1id-abstracts.txt" listing contained in the Internet-Drafts
     Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
     (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
     (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
     (US West Coast).
     
     The  distribution  of  this memo is unlimited.  It is filed as <draft-
     ietf-pppext-l2tp-security-02.txt>  and   expires  December  1,   1998.
     Please send comments to the authors.
     
     
     2.  Abstract
     
     This document discusses how L2TP may utilize IPSEC to provide for tun-
     nel authentication, privacy protection,  integrity  check  and  replay
     protection. Both the voluntary and compulsory tunneling cases are dis-
     cussed.
     
     
     3.  Requirements language
     
     In  this  document,  the  key  words  "MAY",  "MUST,    "MUST    NOT",
     "optional",  "recommended",  "SHOULD",  and  "SHOULD  NOT",  are to be
     interpreted as described in [2].
     
     
     4.  Terminology
     
     
     Voluntary Tunneling
               In voluntary tunneling, a tunnel is  created  by  the  user,
               typically  via  use  of a tunneling client. As a result, the
               user will send L2TP packets to the NAS  which  will  forward
     
     
     
     Patel & Aboba                                                 [Page 1]


     INTERNET-DRAFT                                             22 May 1998
     
     
               them on to the LNS. In voluntary tunneling, the NAS does not
               need to support L2TP,  and  the  LAC  resides  on  the  same
               machine as the user.
     
     Compulsory Tunneling
               In  compulsory  tunneling,  a  tunnel is created without any
               action from the user  and  without  allowing  the  user  any
               choice.  As  a result, the user will send PPP packets to the
               NAS/LAC, which will encapsulate them in L2TP and tunnel them
               to  the  LNS.  In the compulsory tunneling case, the NAS/LAC
               must be L2TP capable.
     
     
     5.  Introduction
     
     L2TP, described in [1], is a protocol that tunnels  PPP  traffic  over
     variety  of networks (e.g., IP, SONET, ATM). Since the protocol encap-
     sulates PPP, L2TP inherits PPP authentication,  as  well  as  the  PPP
     Encryption  Control  Protocol  (ECP) (described in [10]), and the Com-
     pression Control Protocol (CCP) (described in [9]). L2TP also includes
     support  for  tunnel  authentication,  which  can  be used to mutually
     authenticate the tunnel endpoints. However, L2TP does not define  tun-
     nel protection mechanisms.
     
     IPSEC is a protocol suite defined by IETF working group on IP security
     to secure communication at the  network  layer  between  communicating
     peers.   This  protocol is comprised of IP Security Architecture docu-
     ment [6], IKE, described in [7], IPSEC AH, described in [3] and  IPSEC
     ESP, described in [4]. IKE is the key management protocol while AH and
     ESP are used to protect IP traffic.
     
     This draft proposes use of the IPSEC  protocol  suite  for  protecting
     L2TP  traffic over IP and Non-IP networks, and discusses how IPSEC and
     L2TP should be used together. This document does not attempt to  stan-
     dardize  end-to-end security. When end-to-end security is required, it
     is recommended that additional security mechanisms (such as  IPSEC  or
     TLS) be used inside the tunnel, in addition to L2TP tunnel security.
     
     
     6.  L2TP security requirements
     
     L2TP  tunnels  PPP  traffic  over  the  IP and non-IP public networks.
     Therefore, both the control and data packets of L2TP protocol are vul-
     nerable to attack.  Examples of attacks include:
     
     1.  The adversary may try to discover user identities by snooping data
     packets.
     
     2. The adversary may try to modify packets (both control and data).
     
     3. The adversary may try to hijack the L2TP tunnel or the PPP  connec-
     tion inside the tunnel.
     
     4.  An  adversary  can launch denial of service attacks by terminating
     
     
     
     Patel & Aboba                                                 [Page 2]


     INTERNET-DRAFT                                             22 May 1998
     
     
     PPP connections, or L2TP tunnels.
     
     5. An adversary may attempt to disrupt  the  PPP  ECP  negotiation  in
     order  to  weaken or remove confidentiality protection. Alternatively,
     an adversary may wish to disrupt the PPP LCP  authentication  negotia-
     tion  so as to weaken the PPP authentication process or gain access to
     user passwords.
     
     To address these threats, the L2TP security protocol MUST be  able  to
     provide  authentication,  integrity  and replay protection for control
     packets. In addition, it SHOULD be able to protect confidentiality  of
     control  packets. It MUST be able to provide integrity and replay pro-
     tection of data packets, and MAY be able to protect confidentiality of
     data  packets.  An L2TP security protocol MUST also provide a scalable
     approach to key management.
     
     The L2TP protocol, and PPP authentication and encryption do  not  meet
     the  security  requirements  for  L2TP.  L2TP authentication typically
     mutually authenticates LAC to LNS at tunnel origination and may  peri-
     odically  re-authenticate.  Therefore, it does not protect control and
     data traffic on a per packet basis. Thus, L2TP  tunnel  authentication
     leaves  L2TP tunnel vulnerable to attack. PPP authenticates the client
     to the LNS, but also does  not  provide  per-  packet  authentication,
     integrity,  or replay protection. PPP encryption meets confidentiality
     requirements for PPP traffic  but  does  not  address  authentication,
     integrity  and key management requirements. In addition, PPP ECP nego-
     tiation, outlined in [10] does not provide for a protected ciphersuite
     negotiation.  Therefore, PPP encryption provides a weak security solu-
     tion, and in addition does not assist in securing L2TP  control  chan-
     nel.
     
     Key  management facilities are not provided by the L2TP protocol. How-
     ever, where L2TP tunnel authentication is desired, it is necessary  to
     distribute tunnel passwords.
     
     Note  that several of the attacks outlined above can be carried out on
     PPP packets sent over the link between the  client  and  the  NAS/LAC,
     prior  to  encapsulation  of  the packets within an L2TP tunnel. While
     strictly speaking these attacks are outside the scope  of  L2TP  secu-
     rity,  in  order  to protect against them, the user SHOULD provide for
     confidentiality, authentication and integrity protection for PPP pack-
     ets  sent  over the dial-up link. Authentication and integrity protec-
     tion are not currently supported by PPP encryption methods,  described
     in [11]-[13].
     
     
     6.1.  L2TP Security Protocol
     
     The  L2TP security protocol MUST provide authentication, integrity and
     replay protection for control packets. In addition, it SHOULD  protect
     confidentiality  of  control  packets.  It  MUST provide integrity and
     replay protection of data packets, and MAY protect confidentiality  of
     data  packets.  An L2TP security protocol MUST also provide a scalable
     approach to key management.
     
     
     
     Patel & Aboba                                                 [Page 3]


     INTERNET-DRAFT                                             22 May 1998
     
     
     To meet above requirements, all L2TP  security  compliant  implementa-
     tions  MUST  implement  IPSEC  ESP  for  securing L2TP control packets
     and SHOULD implement IPSEC ESP for protection of  L2Tp  data  packets.
     All  mandated  cipher  suites, including NULL encryption, of IPSEC ESP
     MUST be supported. Note that if confidentiality is not required (e.g.,
     L2TP  data traffic), ESP with NULL encryption may be used.  The imple-
     mentations MUST implement replay protection mechanisms of IPSEC.
     
     L2TP security MUST meet the key management requirements of  the  IPSEC
     protocol  suite.  IKE SHOULD be supported for authentication, security
     association negotiation, and key management using the IPSEC DOI [5].
     
     
     6.2.  Stateless compression and encryption
     
     Stateless encryption and/or compression is highly desirable when  L2TP
     is  run over IP.  Since L2TP is a connection-oriented protocol, use of
     stateful compression/encryption is feasible, but  when  run  over  IP,
     this  is  not desirable. While providing better compression, and some-
     what more secure encryption, when used without an underlying  reliable
     delivery  mechanism  stateful  methods magnify packet losses, and thus
     are problematic when used over the Internet where packet loss  can  be
     significant.  In  addition,  although L2TP is connection oriented, the
     L2TP specification [1] does not mandate  packet  ordering,  which  can
     create  difficulties in implementation of stateful compression/encryp-
     tion schemes. However, these considerations are not as important  when
     L2TP is run over non-IP media such as ATM, X.25, or Frame Relay, since
     these media guarantee ordering, and packet losses are typically low.
     
     
     6.3.  Implementation considerations for L2TP over Non-IP networks
     
     L2TP requires that a non-IP network supports packet transport, so that
     the non-IP network should be able to carry L2TP control and data pack-
     ets.
     
     Since ESP functions are defined on the IP payload  (excluding  the  IP
     header),  the presence of an IP header is not a requirement for use of
     ESP. Therefore, L2TP implemented on non-IP networks MUST  be  able  to
     transport  IPSEC ESP packets. The next payload field of the ESP header
     MUST be set to the L2TP protocol number. IANA has assigned 115 as  the
     protocol number for L2TP.
     
     IKE  messages  use  UDP transport. Therefore, in order to be compliant
     with the IKE protocol on non-IP media,  the  non-IP  media  (which  is
     capable  of  transporting packets) MUST support transport of UDP data-
     grams. Since the IP header is not present in  the  UDP  datagram  over
     non-IP  media,  the UDP checksum MUST be set to zero by the source and
     ignored by the destination.
     
     The exact mechanisms for enabling transport of  ESP  and  UDP  packets
     over  non-IP media MUST be addressed in appropriate standards for L2TP
     over specific non-IP networks.
     
     
     
     
     Patel & Aboba                                                 [Page 4]


     INTERNET-DRAFT                                             22 May 1998
     
     
     7.  L2TP/IPSEC interoperability guidelines
     
     The  following  guidelines  are  established  to  meet  L2TP  security
     requirements  using IPSEC in practical situations. Note that this sec-
     tion is not a requirement for an implementation to  be  L2TP  security
     compliant.   Its  purpose  to  make  the implementors aware of certain
     efficiency and security considerations.
     
     In the scenarios that follow, it is assumed that both L2TP clients and
     servers are able to set and get the properties of IPSEC security asso-
     ciations, as well as to influence the IPSEC security services  negoti-
     ated.   Furthermore,  it  is assumed that L2TP clients and servers are
     able to influence the negotiation process for PPP encryption and  com-
     pression.
     
     
     7.1.  Compulsory tunnel
     
     In  the  case of a compulsory tunnel, the dial-in user will be sending
     PPP packets to the LAC, and will typically not be aware that its pack-
     ets  are  being  tunneled, nor that any security services are in place
     between the LAC and LNS. From the LNS's point of view,  it  will  note
     arrival  of  a  PPP  data packet encapsulated in L2TP, which is itself
     encapsulated in an IP  packet.  Assuming  that  the  LNS  is  able  to
     retrieve  the  properties  of  the Security Association set up between
     itself and the LAC, it will have knowledge of the security services in
     place  between  the  LAC  and itself. Thus in the compulsory tunneling
     case,  the dial-in user and the LNS  have  unequal  knowledge  of  the
     security services in place between them.
     
     Since the LNS is capable of knowing whether confidentiality, authenti-
     cation, integrity and replay protection are in place between  the  LAC
     and  itself, it can use this knowledge in order to modify its behavior
     during PPP ECP and CCP negotiation.  For example, let us  assume  that
     LNS  confidentiality  policy  can be described by one of the following
     terms: "Require Encryption," "Allow Encryption" or  "Prohibit  Encryp-
     tion."  If  IPSEC  confidentiality  services are in place, then an LNS
     implementing a "Prohibit Encryption" policy will  act  as  though  the
     policy  had  been  violated. Similarly, an LNS implementing a "Require
     Encryption" or "Allow Encryption" policy  will  act  as  though  these
     policies  were  satisfied, and would not mandate use of PPP encryption
     or compression. Note however, that this is not the same  as  insisting
     that PPP encryption and compression be turned off, since this decision
     will depend on the policy of the dialin user.
     
     Since the dial-in user has no knowledge of the  security  services  in
     place  between the LAC and the LNS, and since it may not trust the LAC
     or the wire between itself and the LAC, the dial-in  user  will  typi-
     cally  want  to  ensure  sufficient security through use of end-to-end
     IPSEC or PPP encryption/compression between itself and the LNS.
     
     A dial-in user wishing to ensure security  services  over  the  entire
     travel path would not modify this behavior even if it had knowledge of
     the security services in place between the LAC and the  LNS.  This  is
     
     
     
     Patel & Aboba                                                 [Page 5]


     INTERNET-DRAFT                                             22 May 1998
     
     
     because  the  dial-in user needs to negotiate confidentiality services
     between itself and the LNS in order to provide  privacy  on  the  wire
     between itself and the LAC. Similarly, the dial-in user needs to nego-
     tiate end-to-end security between itself and the endstation  in  order
     to  ensure  confidentiality on the portion of the path between the LNS
     and the endstation.
     
     Given that the dial-in user will typically not trust the LAC and  will
     negotiate confidentiality and compression services on its own, the LAC
     may only wish to negotiate IPSEC ESP with null  encryption  (described
     in  []) with the LNS, and the LNS will request replay protection. This
     will ensure that confidentiality and compression services will not  be
     duplicated  over the path between the LAC and the LNS. This will typi-
     cally result in better scalability for the LAC, since encryption  will
     be handled by the dial-in user and the LNS.
     
     The  dial-in  user can satisfy its desire for confidentiality services
     in one of two ways. If it knows that all endstations that it will com-
     municate with are IPSEC-capable (or if it refuses to talk to non-IPSEC
     capable endstations), then it can  refuse  to  negotiate  PPP  encryp-
     tion/compression and negotiate IPSEC ESP with the endstations instead.
     If the client does not know that all endstations it will  contact  are
     IPSEC  capable  (the  most  likely  case),  then it will negotiate PPP
     encryption/compression.  This  may  result   in   duplicate   compres-
     sion/encryption   which   can  only  be  eliminated  if  PPP  compres-
     sion/encryption can be turned off on a  per-packet  basis.  Note  that
     since the LNS knows that the dial-in user's packets are being tunneled
     but the dial-in user does not, the LNS can ensure that stateless  com-
     pression/encryption  is used by offering stateless compression/encryp-
     tion methods if available in the ECP and CCP negotiations.
     
     
     7.2.  Voluntary tunnel
     
     In the case of a voluntary tunnel, the dial-in user  will  be  sending
     L2TP  packets  to  the  NAS, which will route them to the LNS.  Over a
     dialup link, these L2TP packets will be encapsulated in  IP  and  PPP.
     Assuming  that  it  is  possible  for the dial-in user to retrieve the
     properties of the Security Association between itself and the LNS, the
     dial-in  user  will have knowledge of any security services negotiated
     between itself and the LNS. It will also have knowledge of PPP encryp-
     tion/compression services negotiated between itself and the NAS.
     
     From  the  LNS's point of view, it will note a PPP packet encapsulated
     in L2TP, which is itself encapsulated in an IP frame.  This  situation
     is  identical  to the compulsory tunneling case. Assuming that the LNS
     is able to retrieve the properties of the Security Association set  up
     between  itself  and  the  dial-in user, it will have knowledge of the
     security services in place between the dial-in user and  itself.  Thus
     in  the  voluntary  tunneling  case, the dial-in user and the LNS have
     symmetric knowledge of the security services in place between them.
     
     Since the LNS is capable of knowing whether confidentiality, authenti-
     cation,  integrity  check or replay protection is in place between the
     
     
     
     Patel & Aboba                                                 [Page 6]


     INTERNET-DRAFT                                             22 May 1998
     
     
     dial-in user and itself, it is able to use this  knowledge  to  modify
     its PPP ECP and CCP negotiation stance. If IPSEC confidentiality is in
     place, the LNS can behave as though a "Require  Encryption"  directive
     had  been  fulfilled,  not mandating use of PPP encryption or compres-
     sion. Typically the LNS will not insist that  PPP  encryption/compres-
     sion be turned off, instead leaving this decision to the dial-in user.
     
     Since the dial-in user has knowledge of the security services in place
     between  itself  and  the LNS, it can act as though a "Require Encryp-
     tion" directive had been fulfilled if IPSEC ESP was already  in  place
     between  itself  and the LNS. Thus, it can request that PPP encryption
     and compression not be negotiated. Note that if  IP  compression  ser-
     vices cannot be negotiated, it will typically be desirable to turn off
     PPP compression if no stateless method is available, due to the  unde-
     sirable effects of stateful PPP compression.
     
     Thus  in  the  voluntary  tunneling case the dial-in user and LNS will
     typically be able to avoid use  of  PPP  encryption  and  compression,
     negotiating  IPSEC Confidentiality, Authentication, and Integrity pro-
     tection services instead,  as  well  as  IP  Compression   if   avail-
     able.
     
     This  may result in duplicate encryption if the dial-in user is commu-
     nicating with an IPSEC-capable endstation. In order to avoid duplicate
     encryption/compression,  the  dial-in  user may negotiate two Security
     Associations with the LNS, one with ESP with null encryption, and  one
     with  confidentiality/compression.  Packets  going to an IPSEC-capable
     endstation would run over the ESP with null encryption security  asso-
     ciation,  and packets to a non-IPSEC capable endstation would run over
     the other security association. Note that many  IPSEC  implementations
     cannot  support  this without allowing L2TP packets on the same tunnel
     to be originated from multiple UDP ports. This requires  modifications
     to the L2TP specification.
     
     Also  note  that the dial-in user may wish to put confidentiality ser-
     vices in place for non-tunneled packets travelling between itself  and
     the  NAS.  This will protect the dial-in user against eavesdropping on
     the wire between itself and the NAS. As a result, it may wish to nego-
     tiate  PPP  encryption  and compression with the NAS. As in compulsory
     tunneling, this will result in duplicate encryption and possibly  com-
     pression unless PPP compression/encryption can be turned off on a per-
     packet basis.
     
     
     8.  Security considerations
     
     This draft defines a security protocol.
     
     
     9.  Acknowledgements
     
     Thanks to Gurdeep Singh Pall, David Eitelbach,  William  Dixon,  Peter
     Ford,  and Sanjay Anand of Microsoft, John Richardson of Intel and Rob
     Adams of Cisco for many useful discussions of this problem space.
     
     
     
     Patel & Aboba                                                 [Page 7]


     INTERNET-DRAFT                                             22 May 1998
     
     
     10.  References
     
     [1] K. Hamzeh, A. Rubens, T.  Kolar,  M.  Littlewood,  B.  Palter,  A.
     Valencia,  G. S. Pall, J. Taarud, W. M. Townsley, W. Verthein.  "Layer
     Two Tunneling Protocol -- L2TP." Internet draft  (work  in  progress),
     draft-ietf-pppext-l2tp-10.txt,  April 1998.
     
     [2]  S.  Bradner.   "Key words for use in RFCs to Indicate Requirement
     Levels." RFC 2119, March 1997.
     
     [3] S. Kent, R. Atkinson.  "IP Authentication Header." Internet  draft
     (work in progress), draft-ietf-ipsec-auth-header-06.txt,  May 1998.
     
     [4]  S. Kent, R. Atkinson.  "IP Encapsulating Security Payload (ESP)."
     Internet draft  (work  in  progress),  draft-ietf-ipsec-esp-v2-05.txt,
     May 1998.
     
     [5]  D.  Piper.  "The Internet IP Security Domain of Interpretation of
     ISAKMP." Internet draft (work  in  progress),  draft-ietf-ipsec-ipsec-
     doi-09.txt, May 1998.
     
     [6] R. Atkinson, S. Kent. "Security Architecture for the Internet Pro-
     tocol." Internet  draft  (work  in  progress),  draft-ietf-ipsec-arch-
     sec-05.txt, May 1998.
     
     [7]  D. Harkins, D. Carrel.  "The Internet Key Exchange (IKE)." Inter-
     net draft (work in  progress),  draft-ietf-ipsec-isakmp-oakley-07.txt,
     March 1998.
     
     [8]  W.  Simpson.  "The Point-to-Point Protocol (PPP)". RFC 1661, July
     1994.
     
     [9] D. Rand.  "The PPP Compression Control Protocol (CCP)". RFC  1962,
     Novell, June 1996.
     
     [10] G. Meyer.  "The PPP Encryption Control Protocol (ECP)". RFC 1968,
     Spider Systems, June 1996.
     
     [11] K. Sklower, G. Meyer.  "The PPP DES Encryption Protocol  (DESE)".
     RFC 1969, UCB, Spider Systems, June 1996.
     
     [12]  K. Sklower, G. Meyer.  "The PPP DES Encryption Protocol, Version
     2 (DESE-bis)". Internet draft (work in  progress),  draft-ietf-pppext-
     des-encrypt-v2-02.txt, UC Berkeley, Shiva, March 1998.
     
     [13]  H.  Kummert.   "The PPP Triple-DES Encryption Protocol (3DESE)".
     Internet   draft   (work   in    progress),    draft-ietf-pppext-3des-
     encrypt-00.txt, Nentec GmbH, July 1997.
     
     
     11.  Authors' Addresses
     
     Baiju V. Patel
     Intel Corp
     
     
     
     Patel & Aboba                                                 [Page 8]


     INTERNET-DRAFT                                             22 May 1998
     
     
     2511 NE 25th Ave
     Hillsboro, OR 97124
     
     Phone: 503-264-2422
     Email: baiju.v.patel@intel.com
     
     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     
     Phone: 425-936-6605
     EMail: bernarda@microsoft.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Patel & Aboba                                                 [Page 9]