Network L. Dondeti, Ed. Internet-Draft QUALCOMM, Inc. Intended status: Standards Track R. Canetti Expires: April 25, 2007 IBM Research October 22, 2006 The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in IPsec draft-dondeti-msec-ipsec-tesla-01 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 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies the use of Timed Efficient Stream Loss- tolerant Authentication (TESLA) -- a source authentication mechanism for multicast or broadcast data streams -- with IPsec ESP. In addition to the source authentication using TESLA, group authentication of the ESP packet can be provided using a shared symmetric group key. Thus, the proposed extension to ESP combines Dondeti & Canetti Expires April 25, 2007 [Page 1] Internet-Draft IPsec TESLA October 2006 group secrecy, group authentication, and source authentication transforms in an ESP packet. Contributors Adrian Perrig, Ran Canetti, and Bram Whillock were the original contributors of the TESLA work. Mark Baugher, Ran Canetti, Pau-Chen Cheng and Pankaj Rohatgi were the original contributors to the multicast ESP transform design. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Notes on IPsec ESP and TESLA . . . . . . . . . . . . . . . . . 4 4. IPsec ESP Packet Format with TESLA . . . . . . . . . . . . . . 4 4.1. On the presence of the IPsec ICV in TESLA protected ESP packets . . . . . . . . . . . . . . . . . . . . . . . 6 5. Cryptographic algorithms for IPsec ESP with TESLA . . . . . . 7 6. Sender processing . . . . . . . . . . . . . . . . . . . . . . 7 7. Receiver processing . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8.1. Denial-of-Service Protection . . . . . . . . . . . . . . . 9 8.2. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Dondeti & Canetti Expires April 25, 2007 [Page 2] Internet-Draft IPsec TESLA October 2006 1. Introduction The IPsec Encapsulation Security Payload (ESP) [RFC4303] provides a set of security services that include data origin authentication, which enables an IPsec receiver to validate that a received packet originated from a peer-sender in a pairwise security association (SA). A Message Authentication Code (MAC) based on a symmetric key is the common means to provide data origin authentication for pairwise IPsec SAs. However, for secure groups such as IP multicast groups, a MAC supports only "group authentication" and not data origin authentication. This document specifies a ESP data origin authentication transform based on TESLA, for source authentication of data sent to groups of receivers. The description of the TESLA protocol itself is available in RFC 4082 [RFC4082]. The TESLA authentication itself is protected from DoS attacks by an external authentication transform using a symmetric-key based MAC. Thus senders first source authenticate a packet and then protect it with group authentication. The receivers verify the external MAC to rule out any attacks from parties outside of the secure group and then proceed to verify that the message originated from the claimed source following the TESLA procedures. 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 [RFC2119]. In addition, the following terms are defined and used in this document: Group Secrecy (GS): Group Secrecy ensures that transmitted data is accessible only to group members. This can also be viewed as a way to enforce access control. A typical realization of GS is to encrypt data using a key known only to group members. Essentially, the solution for multicast is the same as the solution for unicast confidentiality. Group Authentication (GA): The GA functionality enables a group member to verify that the received data originated from someone in the group and was not modified en-route by a non-group member. Note that group authentication by itself does not identify the source of the data. For example, the data might have been forged by any malicious group member. GA can be efficiently realized using standard shared key authentication mechanisms such as Message Authentication Codes (MACs), e.g., CBC-MAC or HMAC. Dondeti & Canetti Expires April 25, 2007 [Page 3] Internet-Draft IPsec TESLA October 2006 Source and Data Authentication (SrA): The SrA functionality enables a group member to verify that the received data originated from the claimed source and was not modified en-route by anyone (including other group members). Unlike Group Authentication, SrA provides the IPsec data origin authentication function. SrA provides a much stronger security guarantee than GA in that a particular group member can be identified as a source of a packet. 3. Notes on IPsec ESP and TESLA IPsec ESP provides confidentiality, integrity protection, replay protection and traffic flow confidentiality. Integrity protection may be provided using symmetric keys or digital signatures [RFC4359]. For unicast communication, integrity protection using either mechanism provides data origin authentication. In case of multicast or group communication, symmetric-key based integrity protection supports group authentication only. For source authentication of multicast streams, the sender may sign every packet [RFC4359], TESLA or another source authentication mechanism. TESLA uses symmetric key chain commitment, delayed disclosure of a key from the key chain, and loose time synchronization between the sender's and the receivers' clocks to support source and data origin authentication. The delayed disclosure of keys from the key chain implies that the receivers must buffer packets until the authentication can be verified. To avoid denial of service attacks taking advantage of this buffering requirement, TESLA protected packets may be further protected using group authentication of packets. That limits any such denial of service attacks to members of the secure group. TESLA receivers may be bootstrapped using a digitally signed broadcast message containing the commitment to a key chain, local time, disclosure delay and other TESLA parameters from the sender or via individual registration processes with the sender. Bootstrapping of TESLA is out of scope for this document. The key management protocol that establishes the IPsec SA can be used for bootstrapping the receivers. 4. IPsec ESP Packet Format with TESLA In the following we first describe the TESLA authentication fields, followed by a depiction of where the those fields fit in an IPsec ESP packet. Figure 2 also shows the coverage of encryption (when the encryption algorithm is non-NULL), IPsec integrity protection (IPsec ICV), and the TESLA MAC. Dondeti & Canetti Expires April 25, 2007 [Page 4] Internet-Draft IPsec TESLA October 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Id i of K_i(optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Disclosed Key K_(i-d) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ MAC(K'_i, M) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: TESLA Authentication Fields. The TESLA Authentication Fields are as follows: o Id i of K_i (OPTIONAL) -- The 32-bit Id of the key used to compute the TESLA-MAC of the current packet: Within the TESLA tag, the Id i of K_i MAY be sent with the MAC of the message M computed using K_i. If i is not included in the message, the receiver determines i by the time the packet was received and the maximum time displacement from the server. With this time it then can determine the sender's current interval i. o Disclosed Key K_(i-d) -- Variable length disclosed key is MANDATORY and is used to authenticate previous packets from earlier time intervals. o TESLA MAC (K'_i, M): Variable length, MANDATORY. TESLA MAC is computed using the key K'_i (derived from K_i) [RFC4082], which is disclosed in a subsequent packet (in the Disclosed Key field). The MAC coverage is shown in Figure 2. Dondeti & Canetti Expires April 25, 2007 [Page 5] Internet-Draft IPsec TESLA October 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | Security Parameters Index (SPI) | ^ --+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ^ | Sequence Number | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- I T | IV (optional) |^ P E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| s S | Rest of Payload Data (variable) |E e L ~ ~N c A | |C + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R I M | | TFC Padding * (optional, variable) |Y C A +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P V C | | Padding (0-255 bytes) |T | | +-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | v | | Pad Length | Next Header |v | --+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | ~ TESLA Authentication Fields (variable) ~ v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- ~ Integrity Check Value-ICV (variable) ~ +---------------------------------------------------------------+ Figure 2: IPsec ESP Packet Format with TESLA MAC and IPsec ICV o The label "Encyrpt" indicates the coverage of IPsec encryption. It is the same as that described in the IPsec ESP specification [RFC4303]. o The label "IPsec ICV" indicates IPsec ESP's ICV coverage. Whether the ICV is present and its coverage of the fields of the IPsec packet is as specified in the ESP specification. o The label "TESLA MAC" indicates the TESLA MAC coverage. The TESLA MAC protects the IPsec ESP packet starting with the Sequence number and ending with the Next Header field. 4.1. On the presence of the IPsec ICV in TESLA protected ESP packets IPsec ESP mandates the presence of an Integrity Check Value (ICV), except when combined mode algorithms are used to protect the packet and the ICV is part of the combined mode algorithm. In case of CCM, the ICV is encrypted and only parseable at the receiver after decryption. With TESLA protection of a packet, technically an ICV is not required for integrity protection of the packet. However, as Dondeti & Canetti Expires April 25, 2007 [Page 6] Internet-Draft IPsec TESLA October 2006 noted above, a symmetric-key based ICV has the advantage of protecting against some DoS attacks on TESLA, so ICV is REQUIRED to be present in ESP-TESLA. 5. Cryptographic algorithms for IPsec ESP with TESLA TESLA needs a PRF algorithm to derive keys in the key chain. TESLA PRF algorithm is specified through the key management protocol that distributes the ESP SA. The TESLA MAC algorithm is also specified through the key management protocol. There is no reason for this algorithm to be different from the IPsec ICV algorithm. When the TESLA MAC algorithm is not explicitly specified, the receivers are REQUIRED to use the IPsec ICV algorithm to compute the TESLA MAC algorithm. In the single sender group communication, all encryption algorithms that are appropriate for unicast communication are also suitable for secure group communication. In the multi-sender communication case, the counter mode algorithms cannot be used in the same way they are used for the unicast case. Specifically, a sequence number is typically used as the IV or the counter for encryption as well as for replay protection. To do the same in the multi-sender case, requires careful management of the sequence number space between the multiple senders. In this version of this document, counter mode encryption of multicast ESP packets for the multi-sender case, is NOT RECOMMENDED. 6. Sender processing In addition to the steps in [RFC4303], the sender follows the steps below for TESLA protected packets: o The sender determines the current TESLA time interval i. The value of i is the first of the TESLA Authentication Fields. o The sender then includes the TESLA Key, K_(i-d), where d is the TESLA disclosure delay. o Next, it computes the TESLA MAC over the IPsec ESP packet, starting at the Sequence Number field and ending with the Next Header field, using the TESLA Key K_i. That key itself SHALL NOT be disclosed until the TESLA interval i+d. o The sender includes all the TESLA Authentication Fields after the Next Header field of the ESP packet and proceeds to compute the Dondeti & Canetti Expires April 25, 2007 [Page 7] Internet-Draft IPsec TESLA October 2006 IPsec ICV over the entire ESP packet excluding the ICV field itself. 7. Receiver processing Receiver processing of TESLA packets contains the following steps: o When a receiver receives an ESP packet with TESLA fields, it must first check to see that the time interval of the message does not violate the security conditions for the keys used. The message is buffered, and the receiver attempts to authenticate any messages which are authenticated using K_(i-d), i.e., messages received with the index i-d. o If i is not included in the message, the receiver determines i by the time the packet was received and the maximum time displacement from the server. With this time it then can determine the sender's current interval i. o When the receiver receives a TESLA protected ESP packet it first needs to verify whether the packet is safe, which is to check that the key used to compute the MAC of the packet was still secret upon packet arrival. For this, the receiver computes an upper bound on the sender's clock, and checks that the MAC key is still secret (based on the key disclosure schedule). If the packet is safe, the receiver buffers the packet. o Once the receiver has determined i, either directly or by the sender's time, it checks K_(i-d) against the most recently stored key, K_c. If i-d=c then the receiver does nothing. Otherwise it applies the PRF (i-d)-c times to K_(i-d) which should yield K_c. If K_(i-d) is authentic, the receiver uses it to authenticate all messages which used keys in the range K_(c+1) .. K_(i-d) as the MAC key. Finally the receiver replaces K_c with K_(i-d). Note, that if i-d < c the packet would have been unsafe and discarded before this step. o A message in this interval may be authentic or tainted. Dealing with tainted messages is left to the implementor. It is possible that the sender and receiver have fallen out of sync, in which case it is RECOMMENDED that they resynchronize times. If i is not included in the message to the receiver and the two have fallen out of sync, the receiver will not correctly compute i, and failure will occur when attempting to authenticate the key. Dondeti & Canetti Expires April 25, 2007 [Page 8] Internet-Draft IPsec TESLA October 2006 8. Security Considerations This document extends IPsec ESP authentication and encryption transforms to support IP multicast delivery. IPsec ESP provides access control, rejection of replayed packets, confidentiality (encryption), limited traffic-flow confidentiality and connectionless integrity. ESP supports a datagram environment where each IP packet is cryptographically independent of other IP packets and can be decrypted, authenticated, and integrity checked when delayed, reordered, or when other packets from the flow are lost. ESP provides rejection of replayed packets for pairwise security associations and for multicast security associations under certain circumstances[RFC4303]. IPsec ESP for multicast support has the same replay mechanism for the single-sender case; however,the multi-sender case is for further study. ESP provides data origin authentication for pairwise security associations using symmetric message authentication codes, which are not sufficient for group security applications where more than two members share a symmetric key. 8.1. Denial-of-Service Protection A group member cannot authenticate the source of the packet for a multicast group where multiple members share the MAC key. Thus, a rogue member of the group has all the keying material needed to impersonate a sender of the group if that attacker is able to inject packets into the network using that sender's IP address. The modified ESP framework addresses this problem by augmenting the IPsec ICV with the TESLA MAC protection. Source authentication schemes leave multicast receivers vulnerable to DoS attacks if the receiver is duped into performing computationally-expensive validation of bogus packets or buffering of bogus packets. An IPsec ICV is REQUIRED to accompany the TESLA MAC so as to limit the effectiveness of bogus packets sent by non-group members. Unfortunately, group members are still capable of sending packets with a valid external-authenticating MAC and invalid TESLA MAC, i.e., any group member can launch a DoS attack. In this case, the IPsec ICV verification will succeed only to have the TESLA MAC verification to fail. The new transform includes the ESP sequence number in the TESLA MAC to protect against a replay attack by a group member. When the TESLA MAC is used, however, the ESP receiver MUST validate both the authentication tags before updating the ESP replay window. Dondeti & Canetti Expires April 25, 2007 [Page 9] Internet-Draft IPsec TESLA October 2006 8.2. Encryption The value of encryption in the modified ESP transform is to validate individual encryption transforms for multicast operation. It is possible that a particular cipher and mode are suitable for pairwise security associations but not for multicast security associations, such as one where multiple senders share the key. For example, a stream or hybrid stream/block cipher has special risks of keystream reuse when its key is shared by multiple senders. Although IPsec encryption transforms are generally suitable for multicast operation, many have not been evaluated, tested or used in IP multicast environments. The current version of this document specifies some crytographic algorithms that are not safe to use for group communication. Future versions will provide more comprehensive guidance. 9. IANA Considerations IANA considerations associated with this work will appear in future version of this document. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. 10.2. Informative References [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Dondeti & Canetti Expires April 25, 2007 [Page 10] Internet-Draft IPsec TESLA October 2006 Header (AH)", RFC 4359, January 2006. Authors' Addresses Lakshminath Dondeti (editor) QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-1267 Email: ldondeti@qualcomm.com Ran Canetti IBM Research 30 Saw Mill River Rd Hawthorne, NY USA Phone: Email: canetti@watson.ibm.com Dondeti & Canetti Expires April 25, 2007 [Page 11] Internet-Draft IPsec TESLA 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 & Canetti Expires April 25, 2007 [Page 12]