idnits 2.17.1 draft-irtf-dtnrg-ltp-extensions-06.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 427. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 417. 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 == Line 223 has weird spacing: '... ext tag ...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-ltp-07 ** Obsolete normative reference: RFC 3447 (ref. 'RSA') (Obsoleted by RFC 8017) == Outdated reference: A later version (-07) exists of draft-irtf-dtnrg-ltp-motivation-05 -- Obsolete informational reference (is this intentional?): RFC 3280 (ref. 'PKIXPROF') (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay Tolerant Networking Research Group S. Farrell 3 Internet Draft Trinity College Dublin 4 Intended Status: Experimental M. Ramadas 5 Ohio University 6 October 17 2007 S. Burleigh 7 Expires March 17 2007 NASA/Jet Propulsion Laboratory 9 Licklider Transmission Protocol - Extensions 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 17, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 In an Interplanetary Internet setting deploying the Bundle protocol 43 being developed by the Delay Tolerant Networking Research Group, the 44 Licklider Transmission Protocol (LTP), is intended to serve as a 45 reliable convergence layer over single hop deep-space RF links. LTP 46 does ARQ of data transmissions by soliciting selective-acknowledgment 47 reception reports. It is stateful and has no negotiation or 48 handshakes. 50 LTP is designed to provide retransmission-based reliability over 51 links characterized by extremely long message round-trip times (RTTs) 52 and/or frequent interruptions in connectivity. Since communication 53 across interplanetary space is the most prominent example of this 54 sort of environment, LTP is principally aimed at supporting "long- 55 haul" reliable transmission in interplanetary space, but has 56 applications in other environments as well. 58 This document describes extensions to LTP, and is part of a series of 59 related documents describing LTP. Other documents in this series 60 cover the motivation for LTP and the main protocol specification. We 61 recommend reading all the documents in the series before writing code 62 based on this document. 64 This document is a product of the Delay Tolerant Networking Research 65 Group and has been reviewed by that group. No objections to its 66 publication as an RFC were raised. 68 Table of Contents 70 1. Introduction.................................................. 2 71 2. Security Extensions........................................... 3 72 2.1 LTP Authentication ...................................... 3 73 2.2 Cookie Mechanism......................................... 6 74 3. Security Considerations ...................................... 7 75 4. IANA Considerations .......................................... 7 76 5. Acknowledgments .............................................. 7 77 6. References ................................................... 8 78 6.1 Normative References ..................................... 8 79 6.2 Informative References ................................... 8 80 7. Author's Addresses ........................................... 9 82 1. Introduction 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [B97]. 88 Discussions on this internet-draft are being made in the Delay 89 Tolerant Networking Research Group (DTNRG) mailing list. More 90 information can be found in the DTNRG web-site at 91 http://www.dtnrg.org This document describes extensions to the base 92 LTP protocol [LTPSPEC]. The background to LTP is described in the 93 "motivation" document [LTPMOTIVE]. All the extensions defined in 94 this document provide additional security features for LTP. 96 2. Security Extensions 98 The syntactical layout of the extensions are defined in Section 3.1.4 99 of the base protocol specification [LTPSPEC]. 101 Implementers should note that the LTP extension mechanism allows for 102 multiple occurrences of any extension tag, in both (or either) the 103 header or trailer. For example, the LTP authentication mechanism 104 defined below requires both header and trailer extensions, which both 105 use the same tag. 107 2.1 LTP Authentication 109 The LTP Authentication mechanism provides cryptographic 110 authentication of the segment. 112 Implementations MAY support this extension field. If they do not 113 support this header then they MUST ignore it. 115 The LTP authentication extension field has the extension tag value 116 0x00. 118 LTP authentication requires three new fields, the first two of which 119 are carried as the value of the extensions field of the LTP segment 120 header, and the third of which is carried in the segment trailer. 122 The fields which are carried in the header extensions field are 123 catenated together to form the extension value (with the leftmost 124 octet representing the ciphersuite and the remaining octets the 125 KeyID). The KeyID field is optional, and is determined to be absent 126 if the extension value consists of a single octet. 128 Ciphersuite: an eight bit integer value with values defined below. 130 KeyID: An optional key identifier, the interpretation of which is 131 out of scope for this specification (that is, implementers MUST 132 treat these KeyID fields as raw octets, even if they contained an 133 ASN.1 DER encoding of an X.509 IssuerSerial construct [PKIXPROF], 134 for example). 136 The LTP-auth header extension MUST be present in the first segment 137 from any LTP session which uses LTP authentication, but MAY be 138 omitted from subsequent segments in that session. To guard against 139 additional problems arising from lost segments, implementations 140 SHOULD, where bandwidth allows, include these fields in a number of 141 segments in the LTP session. If the first segment (or any part 142 thereof) is re-transmitted, then the LTP-auth header extension MUST 143 be included in the re-transmission. 145 The field carried as a trailer extension is the AuthVal field. It 146 contains the authentication value, which is either a message 147 authentication code (MAC) or a digital signature. This is itself a 148 structured field whose length and formatting depends on the 149 ciphersuite. 151 If for some reason the sender includes two instances of LTP auth 152 headers then there is a potential problem for the receiver in that 153 presumably at least one of the AuthVal fields will not verify. There 154 are very few situations where it would make sense to include more 155 than one LTP auth extension in a single segment, since LTP is a peer- 156 to-peer protocol. If however, keys are being upgraded then the sender 157 might protect the segment with both the new and old keys. In such 158 cases the receiver MUST search and can consider the LTP 159 authentication valid so long as one AuthVal is correct. 161 For all ciphersuites, the input to the calculation is the entire 162 encoded segment including the AuthVal extension tag and length, but 163 not of course, including the AuthVal value. 165 We define three ciphersuites in this specification. Our approach is 166 to follow the precedent set by TLS [TLS], and to "hardcode" all 167 algorithm options in a single ciphersuite number. This means that 168 there are 256 potential ciphersuites supported by this version of 169 LTP-auth. 171 Ciphersuite Value 172 ----------- ----- 173 OriginAuth 0 174 Signature 1 175 NULL 255 177 1. OriginAuth Ciphersuite 179 The OriginAuth ciphersuite involves generating a MAC over the LTP 180 segment and appending the resulting AuthVal field to the end of 181 the segment. There is only one MACing algorithm defined for this 182 which is HMAC-SHA1-80 [HMAC]. The AuthVal field in this case 183 contains just the output of the HMAC-SHA1-80 algorithm which is a 184 fixed width field (10 octets). 186 2. Signature Ciphersuite 188 The Signature ciphersuite involves generating a digital signature 189 of the LTP segment and appending the resulting AuthVal field to 190 the end of the segment. There is only one signature algorithm 191 currently defined for this which is RSA with SHA256 [RSA]. The 192 AuthVal field in this case is simply the signature value, where 193 the signature value occupies the minimum number of octets, e.g. 194 128 octets for a 1024 bit signature). 196 3. NULL Ciphersuite 198 The NULL ciphersuite is basically the same as the OriginAuth 199 ciphersuite, but with a hardcoded key. This ciphersuite 200 effectively provides only data integrity without authentication, 201 and thus is subject to active attacks and is the equivalent of 202 providing a CRC. 204 The hardcoded key to be used with this ciphersuite is the 205 following: 207 HMAC_KEY : c37b7e64 92584340 208 : bed12207 80894115 209 : 5068f738 210 (The above is the test vector from RFC 3537 [WRAP].) 212 In each case the bytes which are input to the cryptographic 213 algorithm consist of the entire LTP segment except the AuthVal. In 214 particular the header extensions field which may contain the 215 ciphersuite number and the KeyID field are part of the input. 217 The output bytes of the cryptographic operation are the payload of 218 the AuthVal field. 220 The following shows an example LTP-auth header, starting from and 221 including the extensions field 223 ext tag sdnv c-s k-id 224 +----+----+----+----+----+ 225 |0x11|0x00|0x02|0x00|0x24| 226 +----+----+----+----+----+ 228 The Extensions field has the value 0x11 with the most-significant and 229 least-significant nibble value 1, indicating the presence of one 230 header and one trailer extension respectively. The next octet is the 231 extension tag (0x00 for LTP-auth), followed by the SDNV encoded 232 length of the ensuing data : a one-octet ciphersuite (0x00 meaning 233 OriginAuth) and the KeyID (in this case with a short value of 0x24). 234 The trailer extension (not shown above) should contain the AuthVal). 236 2.2 A Cookie mechanism 238 The use of cookies is a well known way to make denial-of-service 239 attacks harder to mount. We define the cookie extension for use in 240 environments where an LTP implementation is liable to such attacks. 242 The cookie is placed in a header extension field, and has no related 243 trailer extension field. It has the extension tag value 0x01. 245 The cookie value can essentially be viewed as a sufficiently long 246 random number, where the length can be determined by the 247 implementation (longer cookies are harder to guess and therefore 248 better, though using more bandwidth). Note that cookie values can be 249 derived using lots of different schemes so long as they produce 250 random looking and hard to guess values. 252 The first cookie inserted into a segment for this session is called 253 the initial cookie. 255 Note that cookies do not outlast an LTP session. 257 The basic mode of operation is that an LTP engine can include a 258 cookie in a segment at any time. After that time all segments 259 corresponding to that LTP session MUST contain a good cookie value - 260 that is, all segments both to and from the engine MUST contain a good 261 cookie. Clearly, there will be some delay before the cookie is seen 262 in incoming segments - implementations MUST determine an acceptable 263 delay for these cases, and MUST only accept segments without a cookie 264 until that time. 266 The cookie value can be extended at any time by catenating more 267 random bits. This allows both LTP engines to contribute to the 268 randomness of the cookie, where that is useful. It also allows a node 269 which considers the cookie value too short (say due to changing 270 circumstances) to add additional security. In this case, the 271 extended cookie value becomes the "to-be-checked-against" cookie 272 value for all future segments (modulo the communications delay as 273 above). 275 It can happen that both sides emit segments containing an initial 276 cookie before their peer has a chance to see any cookie. In that case 277 two cookie extension fields MUST be included in all segments 278 subsequently (once the traffic has caught up). That is, the sender 279 and recipient cookies are handled independently. In such cases, both 280 cookie values MUST be "good" at all relevant times (i.e. modulo the 281 delay). In this case, the peer's initial cookie MUST arrive before 282 the calculated delay for receipt of segments containing this engine's 283 cookie - there is only a finite window during which a second cookie 284 can be inserted into the session. 286 A "good" cookie is therefore one which starts with the currently 287 stored cookie value, or else a new cookie where none has been seen in 288 that session so far. Once a cookie value is seen and treated as 289 "good" (e.g. an extended value), the previous value is no longer 290 "good". 292 Modulo the communications delay, segments with an incorrect or 293 missing cookie value MUST be silently discarded. 295 If a segment is to be re-transmitted, (e.g. as a result of a timer 296 expiring) then it needs to contain the correct cookie value at the 297 time of (re-)transmission. Note that this may differ from what was 298 the correct cookie value at the time of the original transmission. 300 3. Security Considerations 302 While there are currently some concerns about using the SHA-1 303 algorithm, these appear to only make it easier to find collisions. In 304 that case, the use of HMAC with SHA-1 can still be considered safe. 305 However, we have changed to use SHA-256 for the signature 306 ciphersuite. 308 4. IANA Considerations 310 At present there are none known. 312 5. Acknowledgments 314 Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian 315 Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for 316 their thoughts on this protocol and its role in Delay-Tolerant 317 Networking architecture. 319 Part of the research described in this document was carried out at 320 the Jet Propulsion laboratory, California Institute of Technology, 321 under a contract with the National Aeronautics and Space 322 Administration. This work was performed under DOD Contract DAA-B07- 323 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; 324 and NASA Contract NAS7-1407. 326 Thanks are also due to Shawn Ostermann, Hans Kruse, and Dovel Myers 327 at Ohio University for their suggestions and advice in making various 328 design decisions. 330 Part of this work was carried out at Trinity College Dublin as part 331 of the Dev-SeNDT contract funded by Enterprise Ireland's technology 332 development programme. 334 6. References 336 6.1 Normative References 338 [B97] S. Bradner, "Key words for use in RFCs to Indicate Requirement 339 Levels", BCP 14, RFC 2119, March 1997. 341 [HMAC] Krawczyk, H. et al, "HMAC: Keyed-Hashing for Message 342 Authentication", RFC 2104, February 1997. 344 [LTPSPEC] Ramadas, M., Burleigh, S., and Farrell, S., "Licklider 345 Transmission Protocol - Specification", draft-irtf-dtnrg-ltp-07.txt 346 (Work in Progress), October 2007. 348 [RSA] Kaliski, B, Staddon J, "PKCS1: RSA Cryptography Specifications 349 Version 2.1", RFC 3447, February 2003. 351 6.2 Informative References 353 [LTPMOTIVE] Burleigh, S., Ramadas, M., and Farrell, S., "Licklider 354 Transmission Protocol - Motivation", draft-irtf-dtnrg-ltp- 355 motivation-05.txt (Work in Progress), October 2007. 357 [PKIXPROF] Housley, R. et al, "Internet X.509 Public Key 358 Infrastructure Certificate and Certificate Revocation List (CRL) 359 Profile", RFC 3280, April 2002. 361 [TLS] Dierks, T., Allen, C. "The TLS Protocol - Version 1.1", RFC 362 4346, April 2006. 364 [WRAP] Schaad, J. Housley, R. "Wrapping a Hashed Message 365 Authentication Code (HMAC) key with a Triple-Data Encryption Standard 366 (DES) Key or an Advanced Encryption Standard (AES) Key", RFC 3537, 367 May 2003. 369 7. Author's Addresses 371 Stephen Farrell 372 Computer Science Department 373 Trinity College Dublin 374 Ireland 375 Telephone +353-1-896-1761 376 Email stephen.farrell@cs.tcd.ie 378 Manikantan Ramadas 379 Internetworking Research Group 380 301 Stocker Center 381 Ohio University 382 Athens, OH 45701 383 Telephone +1 (740) 593-1562 384 Email mramadas@irg.cs.ohiou.edu 386 Scott C. Burleigh 387 Jet Propulsion Laboratory 388 4800 Oak Grove Drive 389 M/S: 301-485B 390 Pasadena, CA 91109-8099 391 Telephone +1 (818) 393-3353 392 FAX +1 (818) 354-1075 393 Email Scott.Burleigh@jpl.nasa.gov 395 Intellectual Property Statement 397 The IETF takes no position regarding the validity or scope of any 398 Intellectual Property Rights or other rights that might be claimed to 399 pertain to the implementation or use of the technology described in 400 this document or the extent to which any license under such rights 401 might or might not be available; nor does it represent that it has 402 made any independent effort to identify any such rights. Information 403 on the procedures with respect to rights in RFC documents can be 404 found in BCP 78 and BCP 79. 406 Copies of IPR disclosures made to the IETF Secretariat and any 407 assurances of licenses to be made available, or the result of an 408 attempt made to obtain a general license or permission for the use of 409 such proprietary rights by implementers or users of this 410 specification can be obtained from the IETF on-line IPR repository at 411 http://www.ietf.org/ipr. 413 The IETF invites any interested party to bring to its attention any 414 copyrights, patents or patent applications, or other proprietary 415 rights that may cover technology that may be required to implement 416 this standard. Please address the information to the IETF at ietf- 417 ipr@ietf.org. 419 Disclaimer of Validity 421 This document and the information contained herein are provided on an 422 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 423 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 424 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 425 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 426 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 427 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 429 Copyright Statement 431 Copyright (C) The IETF Trust (2007). This document is subject to the 432 rights, licenses and restrictions contained in BCP 78, and except as 433 set forth therein, the authors retain all their rights. 435 Acknowledgment 437 Funding for the RFC Editor function is currently provided by the 438 Internet Society.