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]