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: 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: The kernel responds with a message of the form: 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: The kernel responds with a message of the form: 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: The kernel responds with a message of the form: 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: The kernel responds with a message of the form: 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: 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: 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]