Network L. Dondeti, Ed. Internet-Draft QUALCOMM, Inc. Expires: December 22, 2006 R. Canetti IBM Research June 20, 2006 The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in IPsec draft-dondeti-msec-ipsec-tesla-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 December 22, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies Timed Efficient Stream Loss-tolerant Authentication (TESLA), a secure source authentication mechanism for multicast or broadcast data streams. RFC 4082 introduces and describes TESLA in detail, and this document specifies the format of the TESLA authentication field as it is used with IPsec ESP. In addition to the source authentication using TESLA there may be a Dondeti & Canetti Expires December 22, 2006 [Page 1] Internet-Draft IPsec TESLA June 2006 message authentication code for group authentication to protect against DoS attacks. The proposed addition to ESP combines 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 this work (see draft-ietf-msec-tesla-spec-00). Mark Baugher, Ran Canetti, Pau-Chen Cheng and Pankaj Rohatgi were the original contributors of the multicast ESP work. Editor's note This version of the draft is the result of a quick and dirty job of merging the old draft-ietf-msec-tesla-spec-00 and the MESP work. Ran was not given a chance to review the I-D before submission, due to time constraints. Any errors and omissions are due to the Editor's hasty work. Please send comments to msec@securemulticast.org so we can promptly revise the document before the Montreal meeting in July 2006. Dondeti & Canetti Expires December 22, 2006 [Page 2] Internet-Draft IPsec TESLA June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. TESLA Specification . . . . . . . . . . . . . . . . . . . . . 5 3.1. Sender Setup . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Receiver Bootstrapping . . . . . . . . . . . . . . . . . . 6 3.2.1. Bootstrapping Parameters . . . . . . . . . . . . . . . 6 3.2.2. Direct Time Synchronization . . . . . . . . . . . . . 7 3.2.3. Set-up using a multicast key management protocol . . . 10 3.3. Layer Placement . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. Interface Specification . . . . . . . . . . . . . . . 10 3.3.2. Sending Authenticated Data . . . . . . . . . . . . . . 12 4. IPsec ESP Packet Format with TESLA . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5.1. IPsec ESP Authentication for Group Communication . . . . . 15 5.2. Denial-of-Service Protection . . . . . . . . . . . . . . . 15 5.3. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Dondeti & Canetti Expires December 22, 2006 [Page 3] Internet-Draft IPsec TESLA June 2006 1. Introduction The IPsec Encapsulation Security Payload (ESP) 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. A Message Authentication Code (MAC) based on a symmetric key is the common means to provide data-origin authentication for pairwise IPsec security associations. For secure groups such as IP multicast groups, however, a MAC supports only "group authentication" and not data-origin authentication. This document defines a framework for ESP data-origin authentication that is suitable for IP multicast groups of ESP receivers. First we specify the format of the TESLA source authentication data as an external authentication transform within the IPsec ESP protocol [RFC4303]. It specifies the cryptographic operations and message formats. The description of the TESLA protocol is in RFC 4082 [RFC4082]. The TESLA authentication itself is protected by external authentication transform using a symmetric-key based MAC. Thus senders first source authenticate a packet and then protect it with group authentication, the latter protects against external DoS attacks on the source authentication scheme. 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. 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): The GS functionality is ESP confidentiality applied to a group . It ensures that transmitted data are accessible only to group members (i.e. two or more hosts in possession of a shared symmetric key). 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. It is important to note, however, that some encryption transforms have special considerations when a key is shared among multiple senders. An Dondeti & Canetti Expires December 22, 2006 [Page 4] Internet-Draft IPsec TESLA June 2006 IPsec ESP encryption or authentication transform SHOULD describe any potential risks of multicast operation and how those risks are averted. 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, HMAC, or UMAC. 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 malicious group members). Unlike Group Authentication, SrA provides the IPsec data-origin authentication function [RFC2401, ESPbis]. Source and Data Authentication provides a much stronger security guarantee than Group Authentication in that a particular group member can be identified as a source of a packet. Group and multicast source authentication requires stronger cryptographic techniques such as digital signatures, stream signatures [GR], flow signatures [WL], hybrid signatures [R], timed MACs, e.g. TESLA [TESLA, Ch,PCTS],asymmetric MACs [CGIMNP], etc. 3. TESLA Specification 3.1. Sender Setup The sender chooses a time interval duration T_int. Practical values for T_int vary from 100 milliseconds to 1 second. The sender estimates an upper bound on the round-trip-time (RTT). More specifically, this RTT is the propagation delay of a unicast packet from the receiver to the sender, plus the propagation delay of a broadcast packet from the sender to the receiver. Based on the RTT, the sender chooses a key disclosure delay d, where d denotes a number of time intervals, such that d > ceil(RTT/T_int). The sender picks the starting time of time interval zero, which we denote with T_0. The starting time of time interval i is thus T_0 + i * T_int. Next, the sender pre-computes the one-way key chain. Each key of the one-way key chain is active in one time interval, for example, key K_i is active in time interval i. The sender always uses the active Dondeti & Canetti Expires December 22, 2006 [Page 5] Internet-Draft IPsec TESLA June 2006 key to compute the MAC of a packet it sends. The sender discloses the keys with a delay of d time intervals, so it discloses key K_i-d in time interval i. To generate the one-way key chain, the sender chooses the length of the chain N. In future versions, we will define extensions which allow the sender to switch key chains, but for now we assume that N is large enough such that the key chain is long enough for the duration of the broadcast. The sender randomly selects the last key of the one-way key chain K_N. The random choice of K_N is critical, since the security of TESLA relies on the fact that an attacker cannot guess K_N. Simply using a hash of the current time, process id, port number, etc. is thus not sufficient, and we suggest using hardware-based random number generators, or operating system provided random number generators such as /dev/random or /dev/urandom on some UNIX systems. The bit length of K_N is a global parameter, and needs to match the output length of the pseudo-random function F that generates the one-way key chain (see the companion draft for more details on how the PRF F is used to generate the one-way chain and the PRF F' is used to derive the MAC key [1]). The sender uses a pseudo-random function F with target-collision resistance to generate the previous elements of the chain. We suggest using HMAC-MD5 for this purpose [17,18], where the output is truncated to the bit length of the key. If the key length is larger than 128 bits, we suggest using HMAC-SHA-1; the 160 bit size should be sufficient for all practical purposes. Jakobsson [19], and Coppersmith and Jakobsson [20] present a storage and computation efficient mechanism for one-way chains. For a chain of length N, storage is about log(N) elements, and the computation overhead to reconstruct each element is also about log(N). The companion document draft-msec-tesla-intro-01.txt [1] has more information on the one-way key chain. 3.2. Receiver Bootstrapping TESLA requires that the sender and the receiver be at least loosely time synchronized such that the receiver MUST know an upper bound on the sender's clock. The receiver MUST also receive authentic parameters for initiating the TESLA session. Authentication is achieved with a digital signature such as RSA or DSA. 3.2.1. Bootstrapping Parameters In order to bootstrap, the receiver must receive the following authenticated information (Note that the Cryptographic Type Assigned Dondeti & Canetti Expires December 22, 2006 [Page 6] Internet-Draft IPsec TESLA June 2006 Number (CTAN) is a 16-bit integer describing the type of authentication used to generate the signature Sig. CTAN is described in Appendix A.): . The id j of a specific time interval I_j. . An NTP timestamp TI_j describing the beginning of that time interval. . An NTP timestamp T_int describing the interval duration. . A PRF CTAN describing the function that will be used to calculate the keychain (F). . A PRF CTAN describing the function that will be used to derive the MAC key from the keychain (F'). . The key disclosure interval d (unit is intervals). . A bit I telling whether or not the optional id field will be in the TESLA authentication tag. . An Encryption CTAN representing the type of key to be used. . A disclosed key K_i (i < j - d). . The id n of the final key in this key chain, K_n. . The interval d_n of the last key chain element. The Network Time Protocol (NTP) timestamp is described in RFC 958 and is a 64 bit integer which can represent time with precision of .2 nanoseconds. It is noted that this format will overflow in year 2030, TESLA will agree with any format changes in NTP to accomodate this problem. 3.2.2. Direct Time Synchronization In direct time synchronization, the receiver will synchronize its clock with the sender by determining an upper bound on the sender's clock. The protocol is very simple, and suffices for the loose time synchronization required by TESLA. The receiver sends an initial time synchronization request to the sender. This time synchronization request will contain only a random nonce N_r to later ensure that data received from the sender is authentic. The receiver will then record the time T_s at which the nonce was sent. Figure 1 describes the format of the nonce. The Dondeti & Canetti Expires December 22, 2006 [Page 7] Internet-Draft IPsec TESLA June 2006 size of the nonce is a multiple of 8 bits, and the sender can deduce the nonce size from the size of the request packet. Once N_r has been received, the sender responds with the bootstrap ping parameters as well as the following time synchronization parameters: . An NTP timestamp T_sig describing when the data was signed. . An Authentication CTAN S_sig describing the signature type. . A bit F, allowing for an optional formatting of the signature to include a public certificate chain. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | Nr (nonce) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Time synchronization request format . The signature Sig, used to authenticate the parameters. Dondeti & Canetti Expires December 22, 2006 [Page 8] Internet-Draft IPsec TESLA June 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # of certs | PCAN of certs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of Certificate 1 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ | Certificate 1 | ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of Certificate 2 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ | Certificate 2 | ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Signature(variable length) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Optional Signature Format Sig is a signature of the bootstrapping parameters, the time synchronization parameters (excluding Sig), and N_r. The receiver can authenticate the data by appending its nonce to the parameter and use this data to verify the signature. This method assumes that the receiver has an authentic public key of the sender, for example using a public-key infrastructure, so the receiver has a list of authentic public root key certificates of the certificate authorities, and the sender sends along its certificate signed by a certificate authority. Once a receiver has received both sets of parameters, it records the time at which he received the parameters, T_r. The maximum clock off set is d_t = T_r - T_s. The receiver can now easily compute an upper bound on the sender's current time t_s, using it's current local time t_r as follows: t_s = t_r - T_r + T_s. If d_t is larger than a certain threshold, the receiver may repeat time synchronization. TESLA will return the data in the form of a Signature Tag, which has the format described in Figure 3. If so required TESLA will include a certificate chain for authentication via RSA or another public certificate algorithm. If the bit F is set, then the optional format described by 2 is used. The PCAN is a Public Certificate Assigned Number describing what format the certificates are in. Dondeti & Canetti Expires December 22, 2006 [Page 9] Internet-Draft IPsec TESLA June 2006 3.2.3. Set-up using a multicast key management protocol Another way to set-up the parameters of the TESLA transform at the receiver is to obtain these parameters in the Security Association provided by the multicast key management protocol in use (e.g., GDOI). This way of setting the parameters will be further described in future versions of this draft. 3.3. Layer Placement This document assumes TESLA to be implemented as a standalone library, which could reside either in the network, transport, or application layer. However, incorporating TESLA within IPsec ESP implies usage in the network layer. TESLA relies upon timing of packets, that is, TESLA requires knowing the arrival time of incoming packets. TESLA SHOULD NOT be deployed on top of a protocol or layer which will aggressively buffer packets and hides the true packet arrival time, e.g. TCP. 3.3.1. Interface Specification The following describes the interface which the TESLA library will export for the above methods of bootstrapping. 3.3.1.1. Time Synchronization request TESLA will accept a nonce and write a time synchronization request tag (TSRT) to a user specified buffer which must be of required length. The nonce must have significant random properties (non- trivial and of certain length). The implementer must provide adequate space to write the TSRT. Dondeti & Canetti Expires December 22, 2006 [Page 10] Internet-Draft IPsec TESLA June 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 j of time interval I_j (integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TI_j (NTP timestamp) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ T_int (NTP timedif) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | KeyChain PRF type(F) | MAC PRF type(F') | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| d (intervals) | Key type(HMAC function) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ | | ~ K_i(variable length) ~ | | ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Id n of K_n (integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interval of n, d_n (intervals) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Time of signature T_sig (NTP timestamp) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature type | Signature Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Reserved(0) | | +-+-+-+-+-+-+-+-+ Signature(variable length) ~ | | ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Signature Tag format Dondeti & Canetti Expires December 22, 2006 [Page 11] Internet-Draft IPsec TESLA June 2006 3.3.1.2. Authentic Parameters TESLA will accept the time synchronization request, which has the format described in Figure 1, and write the signature tag to a user specified buffer. It is assumed that the signature tag will be sent to the receiver immediately following the creation of the signature. Significant delay would result in too large a bound for d_t and possible synchronization failure. 3.3.2. Sending Authenticated Data When the sender sends an authenticated message to all receivers, it adds a TESLA authentication tag to attach to the message. With the authentication tag, a receiver MAY be able to verify or disrepute previously received messages. TESLA will be used as the external authentication transform in the IPsec ESP protocol. (Recall that IPsec ESP determines exactly which fields are covered under the TESLA authentication.) The format of the TESLA authentication tag is shown in Figure 4. Here M denotes the data in the fields covered by the external authentication in IPsec ESP. Within the TESLA tag, the Id i of K_i is always sent with the MAC of the message M computed using K_i. The last disclosed key K_(i-d) can be used to authenticate previous messages. When a receiver receives the tag, he must first check to see that the time of the message does not violate the security conditions for the keys used. M is buffered, and he attempts to authenticate any messages which relied upon K_(i-d). 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. When the receiver receives an IPsec ESP packet with external authentication done using TESLA, 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. 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 he 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 Dondeti & Canetti Expires December 22, 2006 [Page 12] Internet-Draft IPsec TESLA June 2006 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. 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) ~ | | ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Authentication Tag format. (This is the external authentication tag of IPsec ESP with TESLA.) 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. 4. IPsec ESP Packet Format with TESLA Dondeti & Canetti Expires December 22, 2006 [Page 13] Internet-Draft IPsec TESLA June 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 |^ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | ~ IV (variable & optional) ~| | +---------------------------------------------------------------+| | ~ Internal Authentication Parameters (variable & optional) ~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | ^~ Data (variable) ~I E E+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+N X N~ ~ Padding (0-255 bytes) |T T C+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | V| | Pad Length | Next Header |v | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ Internal Authentication Tag (variable) ~ v +---------------------------------------------------------------+ ~ Integrity Check Value (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: IPsec ESP Packet Format with External and Internal Authentication Encryption (ENC), when applied, covers the ESP data, padding and next header fields. Internal Authentication (INT) covers the ESP sequence number through the next header field, inclusive. External authentication (EXT) covers the entire ESP packet except for the Integrity Check Value (ICV) field. A sender MAY use an encryption-transform (ENC) as done in any other ESP packet. When INT is applied to the packet, its output (if any) is placed in the Internal Authentication Tag. Section 4.1 identifies the INT transforms, which the sender MUST perform prior to the encryption transform. A sender of an IPsec ESP packet for multicast or group communication SHOULD use an external-authentication transform (EXT). Section 4.1 identifies the EXT transforms, which the sender MUST perform last (and the receiver performs first). The sender MUST perform the IPsec ESP transforms for multicast or Dondeti & Canetti Expires December 22, 2006 [Page 14] Internet-Draft IPsec TESLA June 2006 group communication in the order of ENC, INT, and EXT while the receiver MUST perform them in the order of EXT, INT and ENC. 5. Security Considerations For a formal proof of the security of TESLA, please see [6]. An analysis of the robustness of TESLA to denial-of-service attacks along with countermeasures is described in [5]. 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 [ESPbis]. IPsec ESP for multicast support has the same replay mechanism for the single-sender case; 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. 5.1. IPsec ESP Authentication for Group Communication This document describes data-origin authentication services to multicast ESP packets. Secure groups, such as secure multicast groups, cannot use a symmetric-key MAC to uniquely identify the sender; any group member that is in possession of the group authentication key is capable of replacing the source address of the packet with that of another group member and applying the symmetric key to authenticate the packet. To uniquely identify a sender among a group of members, digital signature, public key encryption, or specialized source-authentication techniques such as timed MACs are needed. We define a general ESP packet structure for accommodating a digital signature or TESLA timed MAC. 5.2. Denial-of-Service Protection As discussed above, 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. Dondeti & Canetti Expires December 22, 2006 [Page 15] Internet-Draft IPsec TESLA June 2006 The modified ESP framework addresses this problem by augmenting the MAC with an "internal authentication" transform, which MAY be an RSA- SHA1 digital signature or a TESLA timed MAC. Digital signatures leave multicast receivers vulnerable to denial- of-service attack if the receiver is duped into performing computationally-expensive signature validation of bogus packets. An external message authentication SHOULD accompany a digital signature so as to limit the effectiveness of bogus digitally signed packets by non-group members. TESLA is also vulnerable to a denial of service attack if the receiver is duped into storing bogus packets awaiting MAC verification. An external message authentication transform SHOULD accompany a TESLA authentication transform so as to limit the effectiveness of bogus TESLA packets by non-group members. Unfortunately, group members are still capable of sending packets with a valid external-authenticating MAC and invalid digital signature, i.e. a group member can launch a DoS attack on the group using invalid digital signatures. And group members are still capable of sending packets with a valid external-authentication MAC but an invalid TESLA MAC. In both the TESLA and digital-signature cases, the external authentication will succeed only to have the internal authentication fail. The new transform includes the ESP sequence number in the internal authentication to protect against a replay attack by a group member. When the RECOMMENDED external authentication code is use, however, the ESP receiver MUST validate both the internal authentication as well as the external authentication before updating the ESP replay window. The value of the external MAC authentication transforms is to enable the receiver to greatly reduce the effect of an attack by non-group members, to reduce the effects of a denial of service attack by a group member, to detect an attack by a group member, and to support the integration of multicast source-authentication transforms into IPsec ESP for data-origin authentication. 5.3. 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. This I-D has considered the suitability of several IPsec ESP encryption transforms for inclusion in the modified Dondeti & Canetti Expires December 22, 2006 [Page 16] Internet-Draft IPsec TESLA June 2006 framework. It is RECOMMENDED that all future IPsec encryption transforms be analyzed as to their security for multicast and group security as well as for pairwise security. 6. IANA Considerations IANA considerations associated with this work will appear in future version of this document. 7. References 7.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. 7.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. Dondeti & Canetti Expires December 22, 2006 [Page 17] Internet-Draft IPsec TESLA 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 Ran Canetti IBM Research 30 Saw Mill River Rd Hawthorne, NY USA Phone: Email: canetti@watson.ibm.com Dondeti & Canetti Expires December 22, 2006 [Page 18] Internet-Draft IPsec TESLA June 2006 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Dondeti & Canetti Expires December 22, 2006 [Page 19]