rfc3193.txt

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

   The port numbers would be either I-Port/1701 or 1701/1701 for the
   initial SCCRQ.  The quick mode IDs sent by the initiator will be a
   subset of the Inbound-1 filter at the responder.  As a result, the
   quick mode exchange will finish and IKE should inject a specific
   filter set into the IPsec filter database and associate this filter
   set with the phase 2 SA established between the peers.  These filters
   should persist as long as the L2TP tunnel exists.  The new filter set
   at the responder will be:

      Responder Filters:
         Outbound-1: From R-IPAddr1, to I-IPAddr,  UDP, src 1701,
         dst I-Port

         Inbound-1:  From I-IPAddr,  to R-IPAddr1, UDP, src I-Port,
         dst 1701
         Inbound-2:  From Any-Addr,  to R-IPAddr1, UDP, src Any-Port,
         dst 1701

   Mechanisms SHOULD exist between L2TP and IPsec such that L2TP is not
   retransmitting the SCCRQ while the SA is being established.  L2TP's
   control channel retransmit mechanisms should start once the SA has
   been established.  This will help avoid timeouts which may occur as
   the result of slow SA establishment.

   Once the phase 2 SA has been established between the peers, the SCCRQ
   should be sent from the initiator to the responder.

   If the responder does not choose a new IP address or a new port
   number, the L2TP tunnel can now proceed to establish.

4.2.3.  Responder chooses new IP Address

   This step describes the process which should be followed when the
   responder chooses a new IP address.  The only opportunity for the
   responder to change its IP address is after receiving the SCCRQ but
   before sending a SCCRP.

   The new address the responder chooses to use MUST be reflected in the
   result and error code AVP of a STOPCCN message.  The Result Code MUST
   be set to 2 (General Error) and the Error Code MUST be set to 7 (Try



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


   Another).  The optional error message MUST be present and the
   contents MUST contain the IP address (ASCII encoded) the Responder
   desires to use for subsequent communications.  Only the ASCII encoded
   IP address should be present in the error message.  The IP address is
   encoded in dotted decimal format for IPv4 or in RFC 2373 [17] format
   for IPv6.

   The STOPCCN Message MUST be sent using the same address and UDP port
   information which the initiator used to send the SCCRQ.  This message
   will be protecting using the initial SA bundle setup to protect the
   SCCRQ.

   Upon receiving the STOPCCN, the initiator MUST parse the IP address
   from the Result and Error Code AVP and perform the necessary sanity
   checks to verify this is a correctly formatted address.  If no errors
   are found L2TP should inject a new set of filters into the IPsec
   filter database.  If using pre-shared key authentication, L2TP MAY
   request IKE to bind the new IP address to the pre-shared key which
   was used for the original IP address.

   Since the IP address of the responder changed, a new phase 1 and
   phase 2 SA must be established between the peers before the new SCCRQ
   is sent.

   Assuming the initial tunnel has been torn down and the filters needed
   to create the tunnel removed, the new filters for the initiator and
   responder will be:

      Initiator Filters:
         Outbound-1: From I-IPAddr,  to R-IPAddr2, UDP, src I-Port,
         dst 1701

         Inbound-1:  From R-IPAddr2, to I-IPAddr,  UDP, src 1701,
         dst I-Port
         Inbound-2:  From R-IPAddr2, to I-IPAddr,  UDP, src Any-Port,
         dst I-Port

   Once IKE phase 2 completes, the new filter set at the responder will
   be:

      Responder Filters:
         Outbound-1: From R-IPAddr2, to I-IPAddr,  UDP, src 1701,
         dst I-Port

         Inbound-1:  From I-IPAddr,  to R-IPAddr2, UDP, src I-Port,
         dst 1701
         Inbound-2:  From Any-Addr,  to R-IPAddr1, UDP, src Any-Port,
         dst 1701



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


   If the responder chooses not to move to a new port number, the L2TP
   tunnel setup can now complete.

4.2.4.  Responder chooses new Port Number

   The responder MAY choose a new UDP source port to use for L2TP tunnel
   traffic.  This decision MUST be made before sending the SCCRP.  If a
   new port number is chosen, then L2TP must inject new filters into the
   IPsec filter database.  The responder must start new IKE phase 2
   negotiations with the initiator.

   The final filter set at the initiator and responder is as follows.

      Initiator Filters:
         Outbound-1: From I-IPAddr, to R-IPAddr, UDP, src I-Port,   dst
         R-Port
         Outbound-2: From I-IPAddr, to R-IPAddr, UDP, src I-Port,   dst
         1701


         Inbound-1:  From R-IPAddr, to I-IPAddr, UDP, src R-Port,   dst
         I-Port
         Inbound-2:  From R-IPAddr, to I-IPAddr, UDP, src 1701,     dst
         I-Port
         Inbound-3:  From R-IPAddr, to I-IPAddr, UDP, src Any-Port, dst
         I-Port

         The Inbound-1 filter for the initiator will be injected by IKE
         upon successful completion of the phase 2 negotiations
         initiated by the peer.

      Responder Filters:
         Outbound-1: From R-IPAddr, to I-IPAddr,  UDP, src R-Port,   dst
         I-Port
         Outbound-2: From R-IPAddr, to I-IPAddr,  UDP, src 1701,     dst
         I-Port

         Inbound-1:  From I-IPAddr, to R-IPAddr,  UDP, src I-Port,   dst
         R-Port
         Inbound-2:  From I-IPAddr, to R-IPAddr,  UDP, src I-Port,   dst
         1701
         Inbound-3:  From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst
         1701

   Once the negotiations have completed, the SCCRP is sent and the L2TP
   tunnel can complete establishment.  After the L2TP tunnel has been
   established, any residual SAs and their associated filters may be
   deleted.



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


4.2.5.  Gateway-gateway and L2TP Dial-out considerations

   In the gateway-gateway or the L2TP dial-out scenario, either side may
   initiate L2TP.  The process outlined in the previous steps should be
   followed with one addition.  The initial filter set at both sides
   MUST include the following filter:

      Inbound Filter:
         1: From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst 1701

   When either peer decides to start a tunnel, L2TP should inject the
   necessary inbound and outbound filters to protect the SCCRQ.  Tunnel
   establishment then proceeds exactly as stated in the previous
   sections.

5.  Security Considerations

5.1.  Authentication issues

   IPsec IKE negotiation MUST negotiate an authentication method
   specified in the IKE RFC 2409 [7].  In addition to IKE
   authentication, L2TP implementations utilize PPP authentication
   methods, such as those described in [15]-[16].  In this section, we
   discuss authentication issues.

5.1.1.  Differences between IKE and PPP authentication

   While PPP provides initial authentication, it does not provide per-
   packet authentication, integrity or replay protection.  This implies
   that the identity verified in the initial PPP authentication is not
   subsequently verified on reception of each packet.

   With IPsec, when the identity asserted in IKE is authenticated, the
   resulting derived keys are used to provide per-packet authentication,
   integrity and replay protection.  As a result, the identity verified
   in the IKE conversation is subsequently verified on reception of each
   packet.

   Let us assume that the identity claimed in PPP is a user identity,
   while the identity claimed within IKE is a machine identity.  Since
   only the machine identity is verified on a per-packet basis, there is
   no way to verify that only the user authenticated within PPP is using
   the tunnel.  In fact, IPsec implementations that only support machine
   authentication typically have no way to enforce traffic segregation.
   As a result, where machine authentication is used, once an L2TP/IPsec
   tunnel is opened, any user on a multi-user machine will typically be
   able to send traffic down the tunnel.




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


   If the IPsec implementation supports user authentication, this
   problem can be averted.  In this case, the user identity asserted
   within IKE will be verified on a per-packet basis.  In order to
   provide segregation of traffic between users when user authentication
   is used, the client MUST ensure that only traffic from that
   particular user is sent down the L2TP tunnel.

5.1.2.  Certificate authentication in IKE

   When X.509 certificate authentication is chosen within IKE, the LNS
   is expected to use an IKE Certificate Request Payload (CRP) to
   request from the client a certificate issued by a particular
   certificate authority or may use several CRPs if several certificate
   authorities are trusted and configured in its IPsec IKE
   authentication policy.

   The LNS SHOULD be able to trust several certificate authorities in
   order to allow tunnel client end-points to connect to it using their
   own certificate credential from their chosen PKI.  Client and server
   side certificate revocation list checking MAY be enabled on a per-CA
   basis, since differences in revocation list checking exist between
   different PKI providers.

   L2TP implementations MAY use dynamically assigned ports for both
   source and destination ports only if security for each source and
   destination port combination can be successfully negotiated by IKE.

5.1.3.  Machine versus user certificate authentication in IKE

   The certificate credentials provided by the L2TP client during the
   IKE negotiation MAY be those of the machine or of the L2TP user.
   When machine authentication is used, the machine certificate is
   typically stored on the LAC and LNS during an enrollment process.
   When user certificates are used, the user certificate can be stored
   either on the machine or on a smartcard.

   Since the value of a machine certificate is inversely proportional to
   the ease with which an attacker can obtain one under false pretenses,
   it is advisable that the machine certificate enrollment process be
   strictly controlled.  For example, only administrators may have the
   ability to enroll a machine with a machine certificate.

   While smartcard certificate storage lessens the probability of
   compromise of the private key, smartcards are not necessarily
   desirable in all situations.  For example, some organizations
   deploying machine certificates use them so as to restrict use of
   non-approved hardware.  Since user authentication can be provided




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


   within PPP (keeping in mind the weaknesses described earlier),
   support for machine authentication in IPsec makes it is possible to
   authenticate both the machine as well as the user.

   In circumstances in which this dual assurance is considered valuable,
   enabling movement of the machine certificate from one machine to
   another, as would be possible if the machine certificate were stored
   on a smart card, may be undesirable.

   Similarly, when user certificate are deployed, it is advisable for
   the user enrollment process to be strictly controlled.  If for
   example, a user password can be readily used to obtain a certificate
   (either a temporary or a longer term one), then that certificate has
   no more security value than the password.  To limit the ability of an
   attacker to obtain a user certificate from a stolen password, the
   enrollment period can be limited, after which password access will be
   turned off.  Such a policy will prevent an attacker obtaining the
   password of an unused account from obtaining a user certificate once
   the enrollment period has expired.

5.1.4.  Pre-shared keys in IKE

   Use of pre-shared keys in IKE main mode is vulnerable to man-in-the-
   middle attacks when used in remote access situations.  In main mode
   it is necessary for SKEYID_e to be used prior to the receipt of the
   identification payload.  Therefore the selection of the pre-shared
   key may only be based on information contained in the IP header.
   However, in remote access situations, dynamic IP address assignment
   is typical, so that it is often not possible to identify the required
   pre-shared key based on the IP address.

   Thus when pre-shared keys are used in remote access scenarios, the
   same pre-shared key is shared by a group of users and is no longer
   able to function as an effective shared secret.  In this situation,
   neither the client nor the server identifies itself during IKE phase
   1; it is only known that both parties are a member of the group with
   knowledge of the pre-shared key.  This permits anyone with access to
   the group pre-shared key to act as a man-in-the-middle.

   This vulnerability does not occur in aggressive mode since the
   identity payload is sent earlier in the exchange, and therefore the
   pre-shared key can be selected based on the identity.  However, when
   aggressive mode is used the user identity is exposed and this is