idnits 2.17.1 draft-dondeti-msec-ipsec-tesla-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 460. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 467. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 473. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2007) is 6130 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4302' is defined on line 389, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 402, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network L. Dondeti, Ed. 3 Internet-Draft QUALCOMM, Inc. 4 Intended status: Standards Track R. Canetti 5 Expires: January 8, 2008 IBM Research 6 July 7, 2007 8 The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) 9 in IPsec 10 draft-dondeti-msec-ipsec-tesla-02 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 8, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document specifies the use of Timed Efficient Stream Loss- 44 tolerant Authentication (TESLA) -- a source authentication mechanism 45 for multicast or broadcast data streams -- with IPsec ESP. In 46 addition to the source authentication using TESLA, group 47 authentication of the ESP packet can be provided using a shared 48 symmetric group key. Thus, the proposed extension to ESP combines 49 group secrecy, group authentication, and source authentication 50 transforms in an ESP packet. 52 Contributors 54 Adrian Perrig, Ran Canetti, and Bram Whillock were the original 55 contributors of the TESLA work. Mark Baugher, Ran Canetti, Pau-Chen 56 Cheng and Pankaj Rohatgi were the original contributors to the 57 multicast ESP transform design. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Notes on IPsec ESP and TESLA . . . . . . . . . . . . . . . . . 4 64 4. IPsec ESP Packet Format with TESLA . . . . . . . . . . . . . . 4 65 4.1. On the IPsec ICV in TESLA Protected ESP packets . . . . . 6 66 5. Cryptographic Algorithms for IPsec ESP with TESLA . . . . . . 7 67 6. Sender Processing of TESLA Protected Packets . . . . . . . . . 7 68 7. Receiver Processing of TESLA Protected Packets . . . . . . . . 8 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 75 Intellectual Property and Copyright Statements . . . . . . . . . . 12 77 1. Introduction 79 The IPsec Encapsulation Security Payload (ESP) [RFC4303] transform 80 provides a set of security services that include data origin 81 authentication, which enables an IPsec receiver to validate that a 82 received packet originated from a peer-sender in a pairwise security 83 association (SA). A Message Authentication Code (MAC) based on a 84 symmetric key is the common means to provide data origin 85 authentication for pairwise IPsec SAs. However, for secure groups 86 such as IP multicast groups, a MAC supports only "group 87 authentication" and not data origin authentication. This document 88 specifies a ESP data origin authentication transform based on TESLA 89 for source authentication of data sent to groups of receivers. 91 The description of the TESLA protocol itself is available in RFC 4082 92 [RFC4082]. The TESLA authentication itself is protected from DoS 93 attacks by an external authentication transform using a symmetric-key 94 based MAC. Thus senders first source authenticate a packet and then 95 protect it with group authentication. The receivers verify the 96 external MAC to rule out any attacks from parties outside of the 97 secure group and then proceed to verify that the message originated 98 from the claimed source following the TESLA procedures. 100 2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 In addition, the following terms are defined and used in this 106 document: 108 Group Secrecy (GS): Group Secrecy ensures that transmitted data is 109 accessible only to group members. This is often used as the means 110 to enforce access control. A typical realization of GS is to 111 encrypt data using a key known only to group members. 112 Essentially, the solution for group secrecy is the same as the 113 solution for two party confidential communication. 115 Group Authentication (GA): The GA functionality enables a group 116 member to verify that the received data originated from someone in 117 the group and was not modified en-route by a non-group member. 118 Note that group authentication by itself does not identify the 119 source of the data. For example, the data might have been forged 120 by any malicious group member. GA can be efficiently realized 121 using standard shared key authentication mechanisms such as 122 Message Authentication Codes (MACs), e.g., CBC-MAC or HMAC. 124 Source and Data Authentication (SrA): The SrA functionality enables 125 a group member to verify that the received data originated from 126 the claimed source and was not modified en-route by anyone 127 (including other group members). Unlike Group Authentication, SrA 128 provides the IPsec data origin authentication function. SrA 129 provides a much stronger security guarantee than GA in that a 130 particular group member can be identified as a source of a packet. 132 3. Notes on IPsec ESP and TESLA 134 IPsec ESP provides confidentiality, integrity protection, replay 135 protection and traffic flow confidentiality. Integrity protection 136 may be provided using symmetric keys or digital signatures [RFC4359]. 137 For unicast communication, integrity protection using either 138 mechanism provides data origin authentication. In case of multicast 139 or group communication, symmetric-key based integrity protection 140 supports group authentication only. For source authentication of 141 multicast streams, the sender may sign every packet [RFC4359], use 142 TESLA or another source authentication mechanism. 144 TESLA uses symmetric key chain commitment, delayed disclosure of a 145 key from the key chain, and loose time synchronization between the 146 sender's and the receivers' clocks to support source and data origin 147 authentication. The delayed disclosure of keys from the key chain 148 implies that the receivers must buffer packets until the 149 authentication can be verified. To avoid denial of service attacks 150 taking advantage of this buffering requirement, TESLA protected 151 packets may be further protected using group authentication of 152 packets. That limits any such denial of service attacks to from 153 members of the secure group. 155 TESLA receivers may be bootstrapped using a digitally signed 156 broadcast message containing the commitment to a key chain, local 157 time, disclosure delay and other TESLA parameters from the sender or 158 via individual registration processes with the sender. Bootstrapping 159 of TESLA is out of scope for this document. The key management 160 protocol that establishes the IPsec SA can be used for bootstrapping 161 TESLA at the receivers. 163 4. IPsec ESP Packet Format with TESLA 165 In the following we first describe the TESLA authentication fields, 166 followed by a depiction of where the those fields fit in an IPsec ESP 167 packet. Figure 2 also shows the coverage of encryption (when the 168 encryption algorithm is non-NULL), IPsec integrity protection (IPsec 169 ICV), and the TESLA MAC. 171 The TESLA Authentication Fields are as follows: 173 o Id i of K_i (OPTIONAL) -- The 32-bit Id of the key used to compute 174 the TESLA-MAC of the current packet: Within the TESLA tag, the Id 175 i of K_i MAY be sent with the MAC of the message M computed using 176 K_i. If i is not included in the message, the receiver determines 177 i by the time the packet was received and the maximum time 178 displacement from the server. With this time it then can 179 determine the sender's current interval i. 181 o Disclosed Key K_(i-d) -- Variable length disclosed key is 182 MANDATORY and is used to authenticate previous packets from 183 earlier time intervals. 185 o TESLA MAC (K'_i, M): Variable length, MANDATORY. TESLA MAC is 186 computed using the key K'_i (derived from K_i) [RFC4082], which is 187 disclosed in a subsequent packet (in the Disclosed Key field). 188 The MAC coverage is shown in Figure 2. 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Id i of K_i(optional) | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 ~ Disclosed Key K_(i-d) ~ 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 ~ MAC(K'_i, M) ~ 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Figure 1: TESLA Authentication Fields. 202 TESLA authentication fields are added to IPsec ESP packets as shown 203 in Figure 2. 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 208 | Security Parameters Index (SPI) | ^ 209 --+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 210 ^ | Sequence Number | | 211 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- I 212 T | IV (optional) |^ P 213 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| s 214 S | Rest of Payload Data (variable) |E e 215 L ~ ~N c 216 A | |C 217 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R I 218 M | | TFC Padding * (optional, variable) |Y C 219 A +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P V 220 C | | Padding (0-255 bytes) |T | 221 | +-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 222 v | | Pad Length | Next Header |v | 223 --+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | 224 ~ TESLA Authentication Fields (variable) ~ v 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 226 ~ Integrity Check Value-ICV (variable) ~ 227 +---------------------------------------------------------------+ 229 Figure 2: IPsec ESP Packet Format with TESLA MAC and IPsec ICV 231 In the figure, 233 o The label "Encyrpt" indicates the coverage of IPsec encryption. 234 It is the same as that described in the IPsec ESP specification 235 [RFC4303]. 237 o The label "IPsec ICV" indicates IPsec ESP's ICV coverage. Whether 238 the ICV is present and its coverage of the fields of the IPsec 239 packet is as specified in the ESP specification. 241 o The label "TESLA MAC" indicates the TESLA MAC coverage. The TESLA 242 MAC protects the IPsec ESP packet starting with the Sequence 243 number and ending with the Next Header field. 245 4.1. On the IPsec ICV in TESLA Protected ESP packets 247 IPsec ESP mandates the presence of an Integrity Check Value (ICV), 248 except when combined mode algorithms are used to protect the packet 249 and the ICV is part of the combined mode algorithm. In case of CCM, 250 the ICV is encrypted and only parseable at the receiver after 251 decryption. With TESLA protection of a packet, technically an ICV is 252 not required for integrity protection of the packet. However, as 253 noted above, a symmetric-key based ICV has the advantage of 254 protecting against some DoS attacks on TESLA, so ICV is REQUIRED to 255 be present in ESP-TESLA. 257 5. Cryptographic Algorithms for IPsec ESP with TESLA 259 TESLA needs a PRF algorithm to derive keys in the key chain. TESLA 260 PRF algorithm is specified through the key management protocol that 261 distributes the ESP SA. 263 The TESLA MAC algorithm is also specified through the key management 264 protocol. There is no reason for this algorithm to be different from 265 the IPsec ICV algorithm. When the TESLA MAC algorithm is not 266 explicitly specified, the receivers are REQUIRED to use the IPsec ICV 267 algorithm to compute the TESLA MAC algorithm. 269 In the single sender group communication, all encryption algorithms 270 that are appropriate for unicast communication are also suitable for 271 secure group communication. In the multi-sender communication case, 272 the counter mode algorithms must be used as specified in . 273 [I-D.weis-esp-group-counter-cipher] 275 6. Sender Processing of TESLA Protected Packets 277 In addition to the steps in [RFC4303], the sender follows the steps 278 below for TESLA protected packets: 280 o The sender determines the current TESLA time interval i. The 281 sender may include the time interval i in the message. 283 o It then includes the TESLA Key, K_(i-d), where d is the TESLA 284 disclosure delay. 286 o Next, it computes the TESLA MAC over the IPsec ESP packet, 287 starting at the Sequence Number field and ending with the Next 288 Header field, using the TESLA Key K_i. That key itself SHALL NOT 289 be disclosed until the TESLA interval i+d. 291 o The sender includes all the TESLA Authentication Fields after the 292 Next Header field of the ESP packet and proceeds to compute the 293 IPsec ICV over the entire ESP packet excluding the ICV field 294 itself. 296 7. Receiver Processing of TESLA Protected Packets 298 Receiver processing of TESLA packets contains the following steps. 299 Note that the symmetric key MAC or the group MAC verification is 300 similar to the MAC verification process specified in Section 3.4.4 of 301 [RFC4303]. We limit the specification below for TESLA MAC 302 verification. 304 o When a receiver receives an ESP packet with TESLA fields, it must 305 first check to see that the time interval of the message does not 306 violate the security conditions for the keys used. The message is 307 buffered, and the receiver attempts to authenticate any messages 308 which are authenticated using K_(i-d), i.e., messages received 309 with the index i-d. 311 o If i is not included in the message, the receiver determines i by 312 the time the packet was received and the maximum time displacement 313 from the server. With this time it then can determine the 314 sender's current interval i. 316 o When the receiver receives a TESLA protected ESP packet, it first 317 needs to verify whether the packet is safe, which is to verify 318 that the key used to compute the MAC of the packet was still 319 secret upon packet arrival. For the verification, the receiver 320 computes an upper bound on the sender's clock, and checks that the 321 MAC key is still secret (based on the key disclosure schedule). 322 If the packet is safe, the receiver buffers the packet. The "safe 323 packet test" is explained in detail in Section 3.5 of [RFC4082]. 325 o Once the receiver has determined i, it checks K_(i-d) against the 326 most recently stored key, K_c. If i-d=c then the receiver does 327 nothing. Otherwise it applies the PRF (i-d)-c times to K_(i-d) 328 which should yield K_c. If K_(i-d) is authentic, the receiver 329 uses it to authenticate all buffered messages which used keys in 330 the range K_(c+1) .. K_(i-d) as the MAC key. Finally the 331 receiver replaces K_c with K_(i-d). If K_(i-d) is not authentic, 332 the receiver discards the received message. If the MAC 333 verification on any individual buffered packet fails, the receiver 334 discards that buffered packet. 336 o Note, that if i-d < c the packet would have been unsafe and 337 discarded before this step. 339 o After the TESLA MAC has been verified, the receiver updates the 340 replay window. 342 8. Security Considerations 344 This document specifies the use of a source authentication scheme 345 TESLA with IPsec ESP. TESLA provides source authentication using a 346 symmetric key MAC but relies on loose time synchronization and 347 delayed MAC key disclosure. The scheme is safe as long as receivers 348 can estimate an upper bound on the sender's time and accept packets 349 only if there is a local assurance that the sender has not revealed 350 the MAC key used to authenticate the received packet. To that end, 351 the security considerations in [RFC4082] apply. 353 A group member cannot authenticate the source of the packet for a 354 multicast group where multiple members share the MAC key. Thus, a 355 rogue member of the group has all the keying material needed to 356 impersonate a sender of the group if that attacker is able to inject 357 packets into the network using that sender's IP address. TESLA-ESP 358 addresses this problem by augmenting the IPsec ICV with the TESLA MAC 359 protection. Source authentication schemes leave multicast receivers 360 vulnerable to DoS attacks if the receiver is duped into performing 361 computationally-expensive validation of bogus packets or buffering of 362 bogus packets. An IPsec ICV is RECOMMENDED to accompany the TESLA 363 MAC so as to limit the effectiveness of bogus packets sent by non- 364 group members. 366 Unfortunately, group members are still capable of sending packets 367 with a valid external-authenticating MAC and invalid TESLA MAC, i.e., 368 any group member can launch a DoS attack. In this case, the IPsec 369 ICV verification will succeed only to have the TESLA MAC verification 370 to fail. 372 The new transform includes the ESP sequence number in the TESLA MAC 373 to protect against a replay attack by a group member. When the TESLA 374 MAC is used, however, the ESP receiver MUST validate both the 375 authentication tags before updating the ESP replay window. 377 9. IANA Considerations 379 IANA considerations associated with this work will appear in future 380 version of this document. 382 10. References 384 10.1. Normative References 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, March 1997. 389 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 390 December 2005. 392 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 393 RFC 4303, December 2005. 395 10.2. Informative References 397 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 398 Briscoe, "Timed Efficient Stream Loss-Tolerant 399 Authentication (TESLA): Multicast Source Authentication 400 Transform Introduction", RFC 4082, June 2005. 402 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 403 Internet Protocol", RFC 4301, December 2005. 405 [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within 406 Encapsulating Security Payload (ESP) and Authentication 407 Header (AH)", RFC 4359, January 2006. 409 [I-D.weis-esp-group-counter-cipher] 410 McGrew, D. and B. Weis, "Using Counter Modes with 411 Encapsulating Security Payload (ESP) and Authentication 412 Header (AH) to Protect Group Traffic", 413 draft-weis-esp-group-counter-cipher-00 (work in progress), 414 October 2006. 416 Authors' Addresses 418 Lakshminath Dondeti (editor) 419 QUALCOMM, Inc. 420 5775 Morehouse Dr 421 San Diego, CA 422 USA 424 Phone: +1 858-845-1267 425 Email: ldondeti@qualcomm.com 426 Ran Canetti 427 IBM Research 428 30 Saw Mill River Rd 429 Hawthorne, NY 430 USA 432 Phone: 433 Email: canetti@watson.ibm.com 435 Full Copyright Statement 437 Copyright (C) The IETF Trust (2007). 439 This document is subject to the rights, licenses and restrictions 440 contained in BCP 78, and except as set forth therein, the authors 441 retain all their rights. 443 This document and the information contained herein are provided on an 444 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 445 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 446 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 447 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 448 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 449 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 451 Intellectual Property 453 The IETF takes no position regarding the validity or scope of any 454 Intellectual Property Rights or other rights that might be claimed to 455 pertain to the implementation or use of the technology described in 456 this document or the extent to which any license under such rights 457 might or might not be available; nor does it represent that it has 458 made any independent effort to identify any such rights. Information 459 on the procedures with respect to rights in RFC documents can be 460 found in BCP 78 and BCP 79. 462 Copies of IPR disclosures made to the IETF Secretariat and any 463 assurances of licenses to be made available, or the result of an 464 attempt made to obtain a general license or permission for the use of 465 such proprietary rights by implementers or users of this 466 specification can be obtained from the IETF on-line IPR repository at 467 http://www.ietf.org/ipr. 469 The IETF invites any interested party to bring to its attention any 470 copyrights, patents or patent applications, or other proprietary 471 rights that may cover technology that may be required to implement 472 this standard. Please address the information to the IETF at 473 ietf-ipr@ietf.org. 475 Acknowledgment 477 Funding for the RFC Editor function is provided by the IETF 478 Administrative Support Activity (IASA).