IKEv2 Mobility and Multihoming U. Schilcher
(mobike) H. Tschofenig
Internet-Draft Siemens
Expires: August 18, 2005 February 14, 2005
MOBIKE Extensions for PF_KEY
draft-schilcher-mobike-pfkey-extension-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
PF_KEY is a generic key management API used for communication between
a trusted user level key management daemon and a key engine within
the operating sytem. With the extension of IKEv2 for mobility and
multihoming (MOBIKE) the existing capabilities of PF_KEY with regard
to the creation, maintenance and deletion of security assocations
became insufficient. This document defines an extension to update an
Schilcher & Tschofenig Expires August 18, 2005 [Page 1]
Internet-Draft MOBIKE Extensions for PF_KEY February 2005
entity in the security association database. Additionally, it is
necessary to reflect the newly offered integrity and encryption
algorithms with IKEv2 in PF_KEY.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IPsec SA Update . . . . . . . . . . . . . . . . . . . . . . 5
4. SA Extension . . . . . . . . . . . . . . . . . . . . . . . . 6
5. SPD Update . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Algorithm Types . . . . . . . . . . . . . . . . . . . . . . 12
7. Traffic Selector Extensions . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1 Normative References . . . . . . . . . . . . . . . . . . 18
11.2 Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . 20
Schilcher & Tschofenig Expires August 18, 2005 [Page 2]
Internet-Draft MOBIKE Extensions for PF_KEY February 2005
1. Introduction
PF_KEY [1] is a generic key management API used for communication
between a trusted user level key management daemon and a key engine
within the operating sytem. With the extension of IKEv2 for mobility
and multihoming (MOBIKE) [12] the existing capabilities of PF_KEY
with regard to the creation, maintenance and deletion of security
assocations became insufficient. If an IKEv2 implementation [13]
supports MOBIKE, some additional interaction with the SAD and the SPD
has to be provided. This includes additional operations on the
security policy database (SPD), such as creation, update and deletion
of SPD entries, and the possibility to update addresses for already
existing SAs in the security association database (SAD). Since the
PF_KEY interface in the current version does not support this
operations, some extensions have to be defined.
This document is partially based on PF_KEY extensions provided the
KAME stack (see also [14]), which go beyond those described in [1].
The authors think that it is necessary tou update the original RFC
2367 PF_KEY version to reflect the state-of-the-art implementations.
Schilcher & Tschofenig Expires August 18, 2005 [Page 3]
Internet-Draft MOBIKE Extensions for PF_KEY February 2005
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 [2].
Schilcher & Tschofenig Expires August 18, 2005 [Page 4]
Internet-Draft MOBIKE Extensions for PF_KEY February 2005
3. IPsec SA Update
The first extension allows an IKEv2 implementation to update the
addresses of an existing security association (SA) dynamically.
Updating IPsec SAs is one of the side-effect of the IKE-SA update, a
feature provided by MOBIKE [12]. PF_KEY defines a number of
messages, namely SADB_GETSPI, SADB_UPDATE, SADB_ADD, SADB_DELETE,
SADB_GET, SADB_ACQUIRE, SADB_REGISTER, SADB_EXPIRE, SADB_FLUSH and
SADB_DUMP, for interaction between the key management daemon and the
key engine in the operating system.
In Section 3.1.2 of [1] an SADB_UPDATE message is described for
updating all data stored for an existing SA. The only parameters,
which cannot be updated using an SADB_UPDATE message, are the
Security Parameter Index (SPI), the source and destination IP
addresses. The reason for this design decision might be based on the
IPsec SA identification, which included these parameters to uniquely
select a given security association. This aspect can, however, be
seen as historic. In IKEv2, without the use of MOBIKE, theses
parameters would not change.
To allow an IKEv2 key management daemon to change the addresses of an
existing SA, a new message type has to be introduced:
SADB_X_ADDRUPDATE. The notation of SADB_X is based on the fact of a
missing IANA registry in [1] that requires any symbols or structures
in the PF_KEYv2 name space that are not described in [1] to start
with "SADB_X_" or "sadb_x_".
The format of the SADB_X_ADDRUPDATE message is: <base, SA(*),
address(SD), new_address(SD)>
The meaning of the payloads of the message is the following: base
defines the default message header, SA identifies the security
association to be updated, where (*) indicates that the SA payload
contains only the SPI of it, address(SD) contains the source and the
destination addresses of the existing SA and new_address(SD) the new
source and destination addresses. For a more detailed description of
the payloads see [1]. For the new_address(SD) attribute new payload
types SADB_X_EXT_NEW_ADDRESS_SRC and SADB_X_EXT_NEW_ADDRESS_DST are
needed. These payloads have the same content as the
SADB_EXT_ADDRESS_SRC and SADB_EXT_ADDRESS_DST payloads.
If the kernel receives a SADB_X_ADDRUPDATE message it immediately
updates the SA identified by the SPI in the message. If more than
one SA has to be updated, several SADB_X_ADDRUPDATE messages have to
be sent since each SA payload can only contain one SPI.
Schilcher & Tschofenig Expires August 18, 2005 [Page 5]
Internet-Draft MOBIKE Extensions for PF_KEY February 2005
4. SA Extension
If a new SA is needed by the kernel, it sends a SADB_ACQUIRE message
to the IKEv2 implementation. This message contains all information
needed to create the new SA for some cases. The important
information that are missing, are the traffic selector (TS)
addresses, which are negotiated by IKEv2 using the TS payloads.
Since the TS addresses are only stored inside the SPD, they has to be
read from there (see section Section 5). For that purpose the ID,
which identifies the SPD entry, to which the new SA corresponds, has
to be known. The proposed way to pass that ID from the kernel to the
IKEv2 implementation is in using the following extension of the
PF_KEY interface.
An SA2 payload has to be included in the SADB_ACQUIRE message, which
has to following content:
struct sadb_x_sa2 {
uint16_t sadb_x_sa2_len;
uint16_t sadb_x_sa2_exttype;
uint8_t sadb_x_sa2_mode;
uint8_t sadb_x_sa2_reserved1;
uint16_t sadb_x_sa2_reserved2;
uint32_t sadb_x_sa2_sequence;
uint32_t sadb_x_sa2_reqid;
} __attribute__((packed));
/* sizeof(struct sadb_x_sa2) == 16 */
sadb_x_sa2_len:
The sadb_x_sa2_len contains the length of the structure in 8 Byte
blocks.
sadb_x_sa2_exttype:
This field contains the value identifying the SADB_X_SA2 payload.
sadb_x_sa2_mode:
The sadb_x_sa2_mode field identifies the IPsec mode (i.e., tunnel
or transport mode).
sadb_x_sa2_sequence:
The sadb_x_sa2_sequence field contains the ID of the corresponding
SPD entry.
sadb_x_sa2_reqid:
The request ID for that message.
Schilcher & Tschofenig Expires August 18, 2005 [Page 6]
Internet-Draft MOBIKE Extensions for PF_KEY February 2005
This payload can also be added to SADB_ADD and SADB_UPDATE messages
to tell the kernel whether the SA to be generated is a transport or a
tunnel mode SA. If no SADB_X_SA2 payload is present, all SAs created
will be usable only for tunnel mode.
Schilcher & Tschofenig Expires August 18, 2005 [Page 7]
Internet-Draft MOBIKE Extensions for PF_KEY February 2005
5. SPD Update
For the manipulation of the entries in the SPD some new PF_KEY
message types have to be introduced (see also the KAME IPsec
implementation).
Note that specifying SPD updates is problematic since the the KAME
IPsec extensions have never been standardized. As a consequence,
this text does not extend PF_KEY [1] itself.
These message types are quite similar to the message types used to
manipulate the entries in the SAD. The following new message types
are needed:
SADB_X_SPDADD:
To add a new entry into the SPD, the key management daemon needs
to send a SADB_X_SPDADD message to the kernel. The format of the
message is: <base, policy, address(SD), [lifetime(HS)]>
The kernel responds with a message of the form: <base, policy,
address(SD), [lifetime(HSC)]>
The meaning of the payloads, except for the policy payload, can be
found in [1]. The policy payload contains all specific
information about the new entry:
struct sadb_x_policy {
uint16_t sadb_x_policy_len;
uint16_t sadb_x_policy_exttype;
uint16_t sadb_x_policy_type;
uint8_t sadb_x_policy_dir;
uint8_t sadb_x_policy_reserved;
uint32_t sadb_x_policy_id;
uint32_t sadb_x_policy_reserved2;
} __attribute__((packed));
/* sizeof(struct sadb_x_policy) == 16 */
The sadb_x_policy_len field contains the length of the payload in
8 Byte blocks and sadb_x_policy_exttype contains the value
SADB_X_SPDADD. The type of the SA is indicated by the
sadb_x_policy_type field (e.g., IPsec SA) and the
sadb_x_policy_dir field indicates the direction of the SA (the
possibilities are IPSEC_DIR_INBOUND, IPSEC_DIR_OUTBOUND and
IPSEC_DIR_FWD). The sadb_x_policy_id field contains a value which
is unique for each SPD entry and should be filled with zero for a
SADB_X_SPDADD message since this instructs the kernel to generate
this value. This structure is followed by one or more
Schilcher & Tschofenig Expires August 18, 2005 [Page 8]
Internet-Draft MOBIKE Extensions for PF_KEY February 2005
ipsecrequest structures, one for each protocol used by the new SPD
entry:
struct sadb_x_ipsecrequest {
uint16_t sadb_x_ipsecrequest_len;
uint16_t sadb_x_ipsecrequest_proto;
uint8_t sadb_x_ipsecrequest_mode;
uint8_t sadb_x_ipsecrequest_level;
uint16_t sadb_x_ipsecrequest_reserved1;
uint32_t sadb_x_ipsecrequest_reqid;
uint32_t sadb_x_ipsecrequest_reserved2;
} __attribute__((packed));
/* sizeof(struct sadb_x_ipsecrequest) == 16 */
sadb_x_ipsecrequest_len:
The sadb_x_ipsecrequest_len again contains the length of the
structure including optional extensions, but this time in Byte.
sadb_x_ipsecrequest_proto:
The sadb_x_ipsecrequest_proto field identifies the protocol
used for the current structure (e.g., ESP or AH).
sadb_x_ipsecrequest_mode:
The sadb_x_ipsecrequest_mode field identifies the IPsec mode
(i.e., tunnel or transport mode), which can be different for
each protocol.
sadb_x_ipsecrequest_level:
The sadb_x_ipsecrequest_level field contains one of the
following values: 'default', 'use', 'require' or 'unique'. It
defines how and when a corresponding SA is used. The value use
means that an SA is used if available, otherwise the kernel
keeps its normal operation. If require is specified, it means
that an SA is required for each packet matching to the policy
entry. The value unique has the same meaning as require except
that the policy entry is bound to exactly one outbound SA.
sadb_x_ipsecrequest_reqid:
An ID for that SA can be passed to the kernel in the
sadb_x_ipsecrequest_reqid field.
If tunnel mode is specified, the sadb_x_ipsecrequest structure is
followed by two sockaddr structures that define the tunnel
endpoint addresses. In the case that transport mode is used, no
additional addresses are specified. The next payloads of the
message are the source and destination addresses of the
communication to be protected. In tunnel mode it is possible to
Schilcher & Tschofenig Expires August 18, 2005 [Page 9]
Internet-Draft MOBIKE Extensions for PF_KEY February 2005
use address ranges instead of single address pairs to protect the
traffic of whole subnets with one SPD entry. It is also possible
to specify hard and soft lifetimes for policy entries, but these
payload are optional. In the response from the kernel a hard, a
soft and a current lifetime are always present. The semantics are
the same as for SAD entries (see [1]).
SADB_X_SPDUPDATE:
If an existing SPD entry should be updated, the IKEv2
implementation sends a SADB_X_SPDUPDATE message to the kernel.
This massage has the following format: <base, policy, address(SD),
[lifetime(HS)]>
The kernel responds with a message of the form: <base, policy,
address(SD), [lifetime(HSC)]>
The meaning of the payloads is the same as for the SADB_X_SPDADD
message. All the content of a SPD entry can be changed except the
sadb_x_policy_id field and the source/destination addresses, which
are the inner addresses in tunnel mode. However, the tunnel
endpoint addresses, which only exist in tunnel mode, can be
changed using a SADB_X_SPDUPDATE message.
SADB_X_SPDDELETE:
A SADB_X_SPDDELETE message is sent to the kernel in the case that
an existing SPD entry should be deleted. The entry is identified
by the policy data and the source and destination address. The
message has the following format: <base, policy, address(SD)>
The kernel responds with a message of the form: <base, policy,
address(SD), [lifetime(HSC)]>
If no corresponding entry can be found, the kernel returns a
message containing only the base header with the errno value set
appropriately.
SADB_X_SPDGET:
If the content of an existing SPD entry is needed, a SADB_X_SPDGET
message has to be sent to the kernel. The entry is identified by
the sadb_x_policy_id entry in the sadb_x_policy structure. This
id can obtained for example from a SADB_ACQUIRE message. The
format of a SADB_X_SPDGET message is: <base, policy>
The kernel responds with a message of the form: <base, policy,
address(SD), [lifetime(HSC)]>
Schilcher & Tschofenig Expires August 18, 2005 [Page 10]
If no entry has been found, the kernel returns an errno value in
the base header.
SADB_X_SPDDUMP:
If the kernel receives a SADB_X_SPDDUMP message, it prints out all
existing SPD entries on the console. The message format is:
<base>
SADB_X_SPDFLUSH:
To delete all SPD entries a SADB_X_SPDFLUSH message has to be sent
to the kernel. The format of the message is: <base>
Schilcher & Tschofenig Expires August 18, 2005 [Page 11]
Internet-Draft MOBIKE Extensions for PF_KEY February 2005
6. Algorithm Types
This document defines an IANA registry for the IKEv2 defined
cryptographic algorithms and thereby extends the algorithms defined
by PF_KEY (see Section 3.5 of [1]). The same set of algorithms is
available to MOBIKE.
The following algorithms have been defined already in PF_KEY, Section
3.5 of [1]):
/* Integrity (Authentication) Algorithms */
PF_KEY Algorithm Name Value Description
---------------------------+---------+-----------------------
SADB_AALG_NONE | 0 | not used
SADB_AALG_MD5HMAC | 2 | HMAC-MD5-96
SADB_AALG_SHA1HMAC | 3 | HMAC-SHA-1-96
/* Encryption Algorithms */
PF_KEY Algorithm Name Value Description
---------------------------+---------+-----------------------
SADB_EALG_NONE | 0 | not used
SADB_EALG_DESCBC | 2 | DES in CBC mode
SADB_EALG_3DESCBC | 3 | TripleDES in CBC mode
SADB_EALG_NULL | 11 | NULL encryption
The algorithm for SADB_AALG_MD5_HMAC is defined in [3]. The
algorithm for SADB_AALG_SHA1HMAC is defined in [4]. The algorithm
for SADB_EALG_DESCBC is defined in [5]. SADB_EALG_NULL is the NULL
encryption algorithm, defined in [6]. The SADB_EALG_NONE value is
not to be used in any security association except those which have no
possible encryption algorithm in them (e.g. IPsec AH).
This document enhances this list with the following algorithms:
Schilcher & Tschofenig Expires August 18, 2005 [Page 12]
Internet-Draft MOBIKE Extensions for PF_KEY February 2005
/* Integrity (Authentication) Algorithms */
PF_KEY Algorithm Name Value Description
---------------------------+---------+-----------------------
SADB_AALG_AESXCBCMAC | 4 | AES-XCBC-MAC-96
SADB_X_AALG_SHA2_256HMAC | 5 | SHA2-HMAC-256
SADB_X_AALG_SHA2_384HMAC | 6 | SHA2-HMAC-384
SADB_X_AALG_SHA2_512HMAC | 7 | SHA2-HMAC-512
SADB_X_AALG_RIPEMD160HMAC | 8 | HMAC-RIPEMD-160-96
/* Encryption algorithms */
PF_KEY Algorithm Name Value Description
---------------------------+---------+-----------------------
SADB_EALG_AESCBC128 | 12 | AES with
| | 128-bit keys in CBC mode
SADB_X_EALG_CASTCBC | 6 | CAST in CBC mode
SADB_X_EALG_BLOWFISHCBC | 7 | BLOWFISH in CBC mode
SADB_X_EALG_AESCBC | 12 | AES in CBC mode
SADB_X_EALG_AESCTR | 13 | AES Counter Mode
AES-XCBC-MAC-96 is defined in [7] and AES with 128-bit keys in CBC
mode is defined in [8]. AES counter mode has been defined for usage
with IPsec ESP (see [9]). HMAC-RIPEMD-160-96 is defined in [10].
Note that compression algorithms also need to be considered. This
document does not list them, however.
Schilcher & Tschofenig Expires August 18, 2005 [Page 13]
Internet-Draft MOBIKE Extensions for PF_KEY February 2005
7. Traffic Selector Extensions
Information about Traffic Selectors should also be added to a updated
version of PF_KEY [1]. This is left for future work.
Schilcher & Tschofenig Expires August 18, 2005 [Page 14]
Internet-Draft MOBIKE Extensions for PF_KEY February 2005
8. IANA Considerations
This document defines an IANA registry for the cryptographic
algorithms used within PF_KEY:
TBD
Schilcher & Tschofenig Expires August 18, 2005 [Page 15]
Internet-Draft MOBIKE Extensions for PF_KEY February 2005
9. Security Considerations
This document descrbes an extension to PF_KEY [1] and therefore
inherits its security properties. Since this interface allows
existing entries in the security assocation database (and the
security policy database) to be created, updated or deleted it needs
to be ensured that only trusted and previliged processes are allowed
to this this interface.
Schilcher & Tschofenig Expires August 18, 2005 [Page 16]
Internet-Draft MOBIKE Extensions for PF_KEY February 2005
10. Acknowledgments
The authors would like to thank the developers of FreeBSD for
providing the initial PF_KEY implementation and for extending it for
policy support.
Schilcher & Tschofenig Expires August 18, 2005 [Page 17]
Internet-Draft MOBIKE Extensions for PF_KEY February 2005
11. References
11.1 Normative References
[1] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management API,
Version 2", RFC 2367, July 1998.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997.
[3] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and
AH", RFC 2403, November 1998.
[4] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP
and AH", RFC 2404, November 1998.
[5] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm
With Explicit IV", RFC 2405, November 1998.
[6] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its
Use With IPsec", RFC 2410, November 1998.
[7] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and
Its Use With IPsec", RFC 3566, September 2003.
[8] Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[9] Housley, R., "Using Advanced Encryption Standard (AES) Counter
Mode With IPsec Encapsulating Security Payload (ESP)",
RFC 3686, January 2004.
[10] Keromytis, A. and N. Provos, "The Use of HMAC-RIPEMD-160-96
within ESP and AH", RFC 2857, June 2000.
[11] Hoffman, P., "Cryptographic Suites for IPsec",
Internet-Draft draft-ietf-ipsec-ui-suites-06, April 2004.
11.2 Informative References
[12] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol",
Internet-Draft draft-ietf-mobike-design-01, January 2005.
[13] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
Internet-Draft draft-ietf-ipsec-ikev2-17, October 2004.
[14] , ., "PF_KEY Extensions for IPsec Policy Management in KAME
Stack, available at http://www.kame.net/newsletter/20021210/
Schilcher & Tschofenig Expires August 18, 2005 [Page 18]
Internet-Draft MOBIKE Extensions for PF_KEY February 2005
(February 2005)", 12 2002.
Authors' Addresses
Udo Schilcher
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
Email: udo.schilcher@edu.uni-klu.ac.at
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
Email: Hannes.Tschofenig@siemens.com
Schilcher & Tschofenig Expires August 18, 2005 [Page 19]
Internet-Draft MOBIKE Extensions for PF_KEY February 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schilcher & Tschofenig Expires August 18, 2005 [Page 20]