rfc3193.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,572 行 · 第 1/5 页

   often considered undesirable.

   As a result, where main mode is used with pre-shared keys, unless PPP
   performs mutual authentication, the server is not authenticated.
   This enables a rogue server in possession of the group pre-shared key



Patel, et al.               Standards Track                    [Page 17]

RFC 3193               Securing L2TP using IPsec           November 2001


   to successfully masquerade as the LNS and mount a dictionary attack
   on legacy authentication methods such as CHAP [15].  Such an attack
   could potentially compromise many passwords at a time.  This
   vulnerability is present in some existing IPsec tunnel mode
   implementations.

   To avoid this problem, L2TP/IPsec implementations SHOULD NOT use a
   group pre-shared key for IKE authentication to the LNS.  IKE pre-
   shared authentication key values SHOULD be protected in a manner
   similar to the user's account password used by L2TP.

5.2.  IPsec and PPP security interactions

   When L2TP is protected with IPsec, both PPP and IPsec security
   services are available.  Which services are negotiated depends on
   whether the tunnel is compulsory or voluntary.  A detailed analysis
   of voluntary and compulsory tunneling scenarios is included below.
   These scenarios are non-normative and do not create requirements for
   an implementation to be L2TP security compliant.

   In the scenarios below, it is assumed that both L2TP clients and
   servers are able to set and get the properties of IPsec security
   associations, as well as to influence the IPsec security services
   negotiated.  Furthermore, it is assumed that L2TP clients and servers
   are able to influence the negotiation process for PPP encryption and
   compression.

5.2.1.  Compulsory tunnel

   In the case of a compulsory tunnel, the client sends PPP frames to
   the LAC, and will typically not be aware that the frames are being
   tunneled, nor that any security services are in place between the LAC
   and LNS.  At the LNS, a data packet will arrive, which includes a PPP
   frame encapsulated in L2TP, which is itself encapsulated in an IP
   packet.  By obtaining the properties of the Security Association set
   up between the LNS and the LAC, the LNS can obtain information about
   security services in place between itself and the LAC.  Thus in the
   compulsory tunneling case, the client and the LNS have unequal
   knowledge of the security services in place between them.

   Since the LNS is capable of knowing whether confidentiality,
   authentication, integrity and replay protection are in place between
   itself and the LAC, it can use this knowledge in order to modify its
   behavior during PPP ECP [10] and CCP [9] negotiation.  Let us assume
   that LNS confidentiality policy can be described by one of the
   following terms: "Require Encryption," "Allow Encryption" or
   "Prohibit Encryption." If IPsec confidentiality services are in
   place, then an LNS implementing a "Prohibit Encryption" policy will



Patel, et al.               Standards Track                    [Page 18]

RFC 3193               Securing L2TP using IPsec           November 2001


   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.  This is not the same as
   insisting that PPP encryption and compression be turned off, since
   this decision will depend on client policy.

   Since the client 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 client will typically want
   to ensure sufficient security through use of end-to-end IPsec or PPP
   encryption/compression between itself and the LNS.

   A client 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.  The client
   negotiates confidentiality services between itself and the LNS in
   order to provide privacy on the wire between itself and the LAC.  The
   client negotiates end-to-end security between itself and the end-
   station in order to ensure confidentiality on the portion of the path
   between the LNS and the end-station.

   The client will typically not trust the LAC and will negotiate
   confidentiality and compression services on its own.  As a result,
   the LAC may only wish to negotiate IPsec ESP with null encryption
   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 results
   in better scalability for the LAC, since encryption will be handled
   by the client and the LNS.

   The client can satisfy its desire for confidentiality services in one
   of two ways.  If it knows that all end-stations that it will
   communicate with are IPsec-capable (or if it refuses to talk to non-
   IPsec capable end-stations), then it can refuse to negotiate PPP
   encryption/compression and negotiate IPsec ESP with the end-stations
   instead.  If the client does not know that all end-stations it will
   contact are IPsec capable (the most likely case), then it will
   negotiate PPP encryption/compression.  This may result in duplicate
   compression/encryption which can only be eliminated if PPP
   compression/encryption can be turned off on a per-packet basis.  Note
   that since the LNS knows that the client's packets are being tunneled
   but the client does not, the LNS can ensure that stateless
   compression/encryption is used by offering stateless
   compression/encryption methods if available in the ECP and CCP
   negotiations.





Patel, et al.               Standards Track                    [Page 19]

RFC 3193               Securing L2TP using IPsec           November 2001


5.2.2.  Voluntary tunnel

   In the case of a voluntary tunnel, the client will be send 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 client to retrieve the
   properties of the Security Association between itself and the LNS,
   the client will have knowledge of any security services negotiated
   between itself and the LNS.  It will also have knowledge of PPP
   encryption/compression services negotiated between itself and the
   NAS.

   From the LNS point of view, it will note a PPP frame encapsulated in
   L2TP, which is itself encapsulated in an IP packet.  This situation
   is identical to the compulsory tunneling case.  If LNS retrieves the
   properties of the Security Association set up between itself and the
   client, it can be informed of the security services in place between
   them.  Thus in the voluntary tunneling case, the client and the LNS
   have symmetric knowledge of the security services in place between
   them.

   Since the LNS is capable of knowing whether confidentiality,
   authentication, integrity check or replay protection is in place
   between the client 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 compression.  Typically the LNS will not insist that
   PPP encryption/compression be turned off, instead leaving this
   decision to the client.

   Since the client has knowledge of the security services in place
   between itself and the LNS, it can act as though a "Require
   Encryption" 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.  If IP compression
   services cannot be negotiated, it will typically be desirable to turn
   off PPP compression if no stateless method is available, due to the
   undesirable effects of stateful PPP compression.

   Thus in the voluntary tunneling case the client and LNS will
   typically be able to avoid use of PPP encryption and compression,
   negotiating IPsec Confidentiality, Authentication, and Integrity
   protection services instead, as well as IP Compression, if available.

   This may result in duplicate encryption if the client is
   communicating with an IPsec-capable end-station.  In order to avoid
   duplicate encryption/compression, the client may negotiate two



Patel, et al.               Standards Track                    [Page 20]

RFC 3193               Securing L2TP using IPsec           November 2001


   Security Associations with the LNS, one with ESP with null
   encryption, and one with confidentiality/compression.  Packets going
   to an IPsec- capable end-station would run over the ESP with null
   encryption security association, and packets to a non-IPsec capable
   end-station 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 client may wish to put confidentiality services in
   place for non-tunneled packets traveling between itself and the NAS.
   This will protect the client against eavesdropping on the wire
   between itself and the NAS.  As a result, it may wish to negotiate
   PPP encryption and compression with the NAS.  As in compulsory
   tunneling, this will result in duplicate encryption and possibly
   compression unless PPP compression/encryption can be turned off on a
   per-packet basis.

6.  References

   [1]   Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and
         B. Palter, "Layer Two Tunneling Protocol L2TP", RFC 2661,
         August 1999.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [3]   Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
         November 1998.

   [4]   Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
         (ESP)", RFC 2406, November 1998.

   [5]   Piper, D., "The Internet IP Security Domain of Interpretation
         of ISAKMP", RFC 2407, November 1998.

   [6]   Atkinson, R. and S. Kent, "Security Architecture for the
         Internet Protocol", RFC 2401, November 1998.

   [7]   Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
         RFC 2409, November 1998.

   [8]   Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
         1661, July 1994.

   [9]   Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
         1962, June 1996.




Patel, et al.               Standards Track                    [Page 21]

RFC 3193               Securing L2TP using IPsec           November 2001


   [10]  Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC
         1968, June 1996.

   [11]  Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol
         (DESE)", RFC 1969, June 1996.

   [12]  Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol,
         Version 2 (DESE-bis)", RFC 2419, September 1998.

   [13]  Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)",
         RFC 2420, September 1998.

   [14]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
         2246, November 1998.

   [15]  Simpson, W., "PPP Challenge Handshake Authentication Protocol
         (CHAP)," RFC 1994, August 1996.

   [16]  Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
         Protocol (EAP)," RFC 2284, March 1998.

   [17]  Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 2373, July 1998.

Acknowledgments

   Thanks to Gurdeep Singh Pall, David Eitelbach, Peter Ford, and Sanjay
   Anand of Microsoft, John Richardson of Intel and Rob Adams of Cisco
   for useful discussions of this problem space.






















Patel, et al.               Standards Track                    [Page 22]

RFC 3193               Securing L2TP using IPsec           November 2001


Authors' Addresses

   Baiju V. Patel
   Intel Corp
   2511 NE 25th Ave
   Hillsboro, OR 97124

   Phone: [phone]
   EMail: [e-mail]


   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   Phone: [phone]
   EMail: [e-mail]


   William Dixon
   Microsoft Corporation