[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                    L. Dondeti, Ed.
Internet-Draft                                         V. Narayanan, Ed.
Intended status: Best Current                             QUALCOMM, Inc.
Practice                                                October 18, 2006
Expires: April 21, 2007


                  Guidelines for using IPsec and IKEv2
                     draft-dondeti-useipsec-430x-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working 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
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 21, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   IPsec encapsulation can be used to provide a secure channel between
   two entities, to enforce controlled access to a network, or to
   provide any combination of integrity protection, confidentiality,
   replay protection, and traffic flow confidentiality of data being
   transmitted between two or more endpoints over untrusted transmission
   media or networks.  Whereas various assortments of the protections
   are possible to provide, it is not always safe to use some of the



Dondeti & Narayanan      Expires April 21, 2007                 [Page 1]

Internet-Draft             Use IKEv2 and IPsec              October 2006


   combinations.  Next, IPsec SAs are established either manually or
   using a key management protocol such as IKEv2 with entity
   authentication verified locally or with the assistance of a third
   party.  This document specifies when and how to use IPsec and IKEv2
   and what combinations of protections afforded by those protocols are
   safe and when.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Why is this document needed? . . . . . . . . . . . . . . . . .  3
     3.1.  On the types of use cases of IPsec . . . . . . . . . . . .  4
   4.  What IPsec provides  . . . . . . . . . . . . . . . . . . . . .  5
   5.  Why use IPsec and where to use IPsec?  . . . . . . . . . . . .  6
   6.  How to use IPsec to establish secure channel(s) between
       network entities?  . . . . . . . . . . . . . . . . . . . . . .  6
     6.1.  Identify the Requirements and Constraints  . . . . . . . .  6
       6.1.1.  Requirements and Constraints on the use of IPsec
               encapsulation  . . . . . . . . . . . . . . . . . . . .  6
       6.1.2.  Constraints and Requirements associated with
               Selection of Key Management Protocol . . . . . . . . .  8
   7.  Key management for IPsec:IKEv2 . . . . . . . . . . . . . . . .  9
     7.1.  IKEv2 usage guidelines . . . . . . . . . . . . . . . . . .  9
     7.2.  Guidelines for using Traffic Selectors . . . . . . . . . .  9
     7.3.  IKEv2 support for network access control: IKEv2-EAP  . . .  9
   8.  Group Key management for IPsec . . . . . . . . . . . . . . . .  9
   9.  IPsec and mobility . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  IKEv2 support for mobility . . . . . . . . . . . . . . . .  9
     9.2.  MOBIKE applicability . . . . . . . . . . . . . . . . . . .  9
   10. Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     13.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 12












Dondeti & Narayanan      Expires April 21, 2007                 [Page 2]

Internet-Draft             Use IKEv2 and IPsec              October 2006


1.  Introduction

   It is often a good idea to use an existing security encapsulation
   protocol rather than inventing a new one every time a protocol needs
   security guarantees such as integrity protection, message
   authentication, confidentiality, replay protection or traffic flow
   confidentiality of data in transit.  IPsec is a natural candidate in
   many instances.  However, it is not sufficient to simply say "use
   IPsec."  For interoperability and effective use it is necessary to
   specify in detail what aspects of IPsec are used.

   IPsec is the IP layer security encapsulation protocol used to create
   a secure channel between any combination of end hosts and security
   gateways, or to enforce network access control, or to provide any
   combination of integrity protection, confidentiality, replay
   protection, and traffic flow confidentiality of data being
   transmitted between two or more endpoints over untrusted transmission
   media or networks.  While it is possible to enable any combination of
   the protections available, it is not always safe to use some of the
   combinations.  For instance, encryption without integrity protection
   may not be safe in most usage scenarios, and especially when counter
   mode encryption is used.

   This document has three overall goals: The first is to explain
   briefly what IPsec does and the second to make the case for IPsec as
   the protocol of choice to establish a secure channel or to enforce
   access control, and finally explain that just saying "use IPsec" is
   not sufficient and describe what needs to be specified to correctly
   use IPsec.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

   This document reuses the terminology of the IPsec and IKEv2
   specifications.


3.  Why is this document needed?

   Protocols defined in the IETF and in other standards bodies often
   need a security encapsulation protocol or an access control
   mechanism.  In those cases, it is plausible to design a new protocol,
   which is a rather difficult thing to do.  It is quite easy to get
   things wrong in designing a security protocol: simple oversights may



Dondeti & Narayanan      Expires April 21, 2007                 [Page 3]

Internet-Draft             Use IKEv2 and IPsec              October 2006


   result in the entire process being useless.  The other option is to
   reuse an existing security protocol, IPsec being one of them.
   However, simply stating that use IPsec is in most cases insufficient
   for interoperability and more importantly for effective use.  Once
   again, it is plausible that careless employment of IPsec may result
   in unneeded processing or overhead or worse in the whole process
   being ineffective.

   To that end, a BCP [6] was written to provide guidance on how to use
   IPsecv2.  Since then, the IPsecv3 suite of specifications were
   written to make it easier to use IPsec.  Let us consider the two
   primary types of employment of IPsec and motivate the need for this
   document.

3.1.  On the types of use cases of IPsec

   For instance, in many networks, including the Internet itself, the
   transmission path between two infrastructure entities cannot be
   trusted: the data may be sensitive and needs to be protected from
   eavesdroppers or from packet modification or replay attacks.  In
   those instances, network architects or protocol designers simply
   state that there needs to be an IPsec secure channel between those
   entities.  In most cases, that is insufficient.  It is often the case
   that there are several types of sensitive data to be sent between the
   entities: some need confidentiality and integrity protection, others
   may need integrity protection alone etc.  Despite assumptions to the
   contrary, with key management protocols such as IKEv2, it is
   plausible to establish and maintain multiple secure channels or
   tunnels quite easily.  ESPv3, AHv3 and IKEv2 specifications were
   developed primarily to bring IPsec more inline with the security
   requirements of the various protocols and to make it easy to specify
   which traffic needs what kind of protection via the key management
   protocol.

   Next, access control enforcement is another application of IPsec.
   There are at least two types of access control for which IPsec is
   best suited and commonly used.  The first is "remote" access to
   enterprise networks.  The second is controlled access to a service
   provider's network.  In this model, there is a client attempting to
   access the network and a server authenticating the client and
   enforcing access control to the enterprise or the service provider's
   network.  The extensible authentication protocol (EAP) [7] allows
   most flexibility for client authentication.  The IKEv2 [2] protocol
   enables the use of IPsec for access control with EAP for client
   authentication.  The catch here is that access control is only
   effective with a proper security policy database.  The need for
   security policy enforcement is identified in other specifications
   employing controlled access to networks: the IEEE 802.1X



Dondeti & Narayanan      Expires April 21, 2007                 [Page 4]

Internet-Draft             Use IKEv2 and IPsec              October 2006


   specification identifies "port control" as an essential part of
   enforcing access control.  In brief, port control and security policy
   databases specify which traffic, e.g., EAP traffic in case of 802.1X,
   and key management traffic in case of IPsec, can bypass security
   encapsulation -- which provides a guarantee that the entity that
   established the SA is in fact sending the traffic -- requirements.

   IPsec is also used for secure communication between end hosts.
   Transport mode is typically used for either secure unicast or
   multicast communication.  IPsec encapsulation is also used for access
   control enforcement of data being broadcast or multicast.

   In the rest of this document, we explain what IPsec does, make a case
   for using IPsec as a secure channel or an access control enforcement
   protocol and finally provide guidance on how to use IPsec.


4.  What IPsec provides

   IPsec SAs may be established manually or by way of a key management
   protocol: ESPv3 [3] or AHv3 [4] unicast SAs are established using
   IKEv2 [2] and Group SAs are established using GDOI [8] or GSAKMP.
   Manual keying has some limitations and must be employed with care.
   However, it may be better to use manual keyed IPsec SAs than
   inventing a new security encapsulation protocol.

   Two different types of IPsec encapsulations have been specified in
   [5]: with the first, the Encapsulating Security Payload (ESP), a
   number of security properties can be provided, including integrity
   protection, confidentiality, replay protection, and traffic flow
   confidentiality.  The second type of encapsulation, Authentication
   Header (AH), provides integrity and replay protection, and unlike ESP
   affords integrity protection of IP headers.

   IPsec can be used in transport mode or a tunnel mode: transport mode
   is employed when two endpoints require ESP or AH protection for next
   layer protocol headers and the payload.  Tunnel mode is employed
   between a host and a security gateway or between security gateways by
   encapsulating the entire IP packet and introducing an IP header for
   routing the packet to the appropriate IPsec entity on route to the
   final destination.

   IPsec, especially when used to enforce access control, is associated
   with a security policy database (SPD) that dictates the types of
   traffic that needs what kind of IPsec protection and those that do
   not need any protection.  When specifications require the use of
   IPsec, it is often useful to provide guidelines on SPD contents as
   well for proper use of the protections afforded by IPsec.



Dondeti & Narayanan      Expires April 21, 2007                 [Page 5]

Internet-Draft             Use IKEv2 and IPsec              October 2006


5.  Why use IPsec and where to use IPsec?


6.  How to use IPsec to establish secure channel(s) between network
    entities?

   IPsec may be used as the security encapsulation protocol between two
   or more network infrastructure entities in many cases, including

   o  to protect routing protocol messages, for instance, OSPF, BGP

   o  to protect AAA messages between a AAA client and a server,
      typically in a hop-by-hop fashion

   o  to protect context transfer messages between two edge entities in
      a service provider's network

   o  to provide a blanket secure channel between two network entities.

   o  more ...

6.1.  Identify the Requirements and Constraints

   The first step of course is to take stock of the constraints and the
   requirements.  The following questionnaire might help; note however
   that each situation is unique and may have requirements and
   constraints that may not be listed here.

6.1.1.  Requirements and Constraints on the use of IPsec encapsulation

   First we examine the requirements on the security encapsulation
   itself.

   o  Type of protection --

      *  Specifically, is confidentiality a requirement for all traffic?

      *  Would integrity protection alone be sufficient?  Note that it
         is plausible to use ESP with NULL encryption, effectively
         providing integrity protection alone.

      *  Does the outermost IP header need integrity protection?  Note
         that AH mode of protection of headers implies that modification
         of headers en route is prohibited.

      *  Is replay protection required?  Note that IPsec specifications
         mandate the inclusion of a sequence number in the header.
         Turning off sequence number verification at the receiver only



Dondeti & Narayanan      Expires April 21, 2007                 [Page 6]

Internet-Draft             Use IKEv2 and IPsec              October 2006


         saves the overhead of maintenance of a replay window and some
         associated packet processing.  However, it is plausible that
         replay protection is provided through other means, breaks other
         aspects of higher layer protocols or simply not needed.

         +  If replay protection is being employed, is an extended
            sequence number (ESN) required?  ESN is typically needed for
            high data rate communication to avoid frequent rekeying.
            IPsecv3 assumes automatic use of ESN, unless it is
            explicitly turned off via a key management protocol.

      *  Is traffic flow confidentiality a requirement?  When using ESP
         with non-NULL encryption, IPsec allows the sender to provide
         traffic flow confidentiality (TFC).  TFC protects from entities
         observing the traffic over the air or a wire from making
         intelligent assessments about the contents of the traffic,
         based on the length of IP packets.  TFC padding is in addition
         to the encryption related padding, and must be signaled.

   o  Granularity of protection or number of SAs between the same
      entities --

      *  Does all traffic between the network entities need protection?
         If so, is the protection required the same in all cases?

   o  Origin and destination of traffic being protection or selection of
      tunnel vs transport mode --

      *  Is the traffic originating and destined for the IPsec
         endpoints?  This might imply the use of transport mode IPsec.

      *  Is the traffic originating or destined for entities beyond/
         behind the IPsec endpoints?  This generally implies the use of
         tunnel mode IPsec.  However, if traffic were already in-IP
         tunneled it may be plausible to use transport mode IPsec.  Care
         must be taken however in employing transport in this way as the
         SPD capabilities may be limited as described in Page 13 of [5]

   o  Unicast or Group SAs --

   o  Security Policy Database (SPD) and associated enforcement --

   The next step is to identify any constraints in specifying the
   details of the security encapsulation needed.

   o  Is there a constraint that requires the design to turn off
      integrity protection?  Note that if confidentiality is needed,
      integrity protection is automatically assumed to be needed in most



Dondeti & Narayanan      Expires April 21, 2007                 [Page 7]

Internet-Draft             Use IKEv2 and IPsec              October 2006


      cases.  The following process may help analyze whether an
      exception of turning off integrity protection is even necessary:

      *  Is overhead the reason to not use integrity protection?

      *  Would the use of Counter mode encryption help alleviate the
         per-packet overhead concerns?  With CBC mode encryption, an IV
         of length 16 octets is required.  With counter mode, a counter
         of length of 4 octets needs to be included in each packet.  The
         counter serves as part of the per-packet IV as well as the
         sequence number for replay protection.

      *  Was MAC truncation considered?  Use of an 8-octet MAC is well
         within the recommendation of AES-CMAC specification.  An even
         shorter MAC, as short as 4 octets is better than no integrity
         protection at all.

   o

6.1.2.  Constraints and Requirements associated with Selection of Key
        Management Protocol

   The second part of the exercise is to identify the requirements and
   constraints associated with key management.

   o  Key management protocol -- Is a key management protocol required?
      If so, which one?

      *  The choice of key management protocol depends very much on
         whether unicast or group SAs are to be established.  For
         unicast SA establishment, IKEv2 is the only key management
         protocol specified and for group IPsecv3 SA establishment, GKDP
         is the only key management protocol specified at the time of
         this writing.

   o  Entity authentication -- If a key management protocol is used, the
      first step is to figure out how the IPsec endpoints are
      authenticated to each other.  In the use case under discussion,
      the two endpoints are infrastructure entities: in this case
      certificate based authentication or PSK-based authentication are
      two viable choices.  Requirements analysis would need to determine
      if one of the options is better than the other.

   o  Security policy database reconciliation or Traffic selector
      negotiation --

   o




Dondeti & Narayanan      Expires April 21, 2007                 [Page 8]

Internet-Draft             Use IKEv2 and IPsec              October 2006


   The next step as in case of investigating the use of the security
   encapsulation is to investigate any constraints.

   o  Manual keying is definitely an option to establish IPsecv3 SAs.
      However manual keying has several inherent limitations.  It is
      important to investigate whether the constraints forcing the use
      of manual keying are weighed against the following limitations of
      manual keying:

      *  Rekeying is also manual and if manually keyed IPsec SAs are
         used to protect high data rate flows, key reuse might occur.
         Note that key reuse may result in compromising the protections
         afforded by IPsec.

      *  Algorithm agility is not supported.

      *  Replay protection is not supported.


7.  Key management for IPsec:IKEv2

7.1.  IKEv2 usage guidelines

7.2.  Guidelines for using Traffic Selectors

7.3.  IKEv2 support for network access control: IKEv2-EAP


8.  Group Key management for IPsec


9.  IPsec and mobility

9.1.  IKEv2 support for mobility

9.2.  MOBIKE applicability


10.  Security Considerations


11.  IANA Considerations


12.  Acknowledgments


13.  References



Dondeti & Narayanan      Expires April 21, 2007                 [Page 9]

Internet-Draft             Use IKEv2 and IPsec              October 2006


13.1.  Normative References

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

   [2]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
        December 2005.

   [3]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
        December 2005.

   [4]  Kent, S., "IP Authentication Header", RFC 4302, December 2005.

   [5]  Kent, S. and K. Seo, "Security Architecture for the Internet
        Protocol", RFC 4301, December 2005.

13.2.  Informative References

   [6]   Bellovin, S., "Guidelines for Mandating the Use of IPsec",
         draft-bellovin-useipsec-05 (work in progress), August 2006.

   [7]   Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
         Levkowetz, "Extensible Authentication Protocol (EAP)",
         RFC 3748, June 2004.

   [8]   Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
         Domain of Interpretation", RFC 3547, July 2003.

   [9]   Housley, R. and B. Aboba, "Guidance for AAA Key Management",
         draft-housley-aaa-key-mgmt-04 (work in progress), October 2006.

   [10]  Aboba, B., "Extensible Authentication Protocol (EAP) Key
         Management Framework", draft-ietf-eap-keying-14 (work in
         progress), June 2006.


Authors' Addresses

   Lakshminath Dondeti (editor)
   QUALCOMM, Inc.
   5775 Morehouse Dr
   San Diego, CA
   USA

   Phone: +1 858-845-1267
   Email: ldondeti@qualcomm.com





Dondeti & Narayanan      Expires April 21, 2007                [Page 10]

Internet-Draft             Use IKEv2 and IPsec              October 2006


   Vidya Narayanan (editor)
   QUALCOMM, Inc.
   5775 Morehouse Dr
   San Diego, CA
   USA

   Phone: +1 858-845-2483
   Email: vidyan@qualcomm.com











































Dondeti & Narayanan      Expires April 21, 2007                [Page 11]

Internet-Draft             Use IKEv2 and IPsec              October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Dondeti & Narayanan      Expires April 21, 2007                [Page 12]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/