idnits 2.17.1 draft-irtf-dtnrg-ltp-extensions-05.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 222 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-06 ** Obsolete normative reference: RFC 3447 (ref. 'RSA') (Obsoleted by RFC 8017) == Outdated reference: A later version (-07) exists of draft-irtf-dtnrg-ltp-motivation-04 -- 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 April 2007 S. Burleigh 7 Expires October 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 October 1, 2007. 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 ........................................... 8 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 187 The Signature ciphersuite involves generating a digital signature 188 of the LTP segment and appending the resulting AuthVal field to 189 the end of the segment. There is only one signature algorithm 190 currently defined for this which is RSA with SHA256 [RSA]. The 191 AuthVal field in this case is simply the signature value, where 192 the signature value occupies the minimum number of octets, e.g. 193 128 octets for a 1024 bit signature). 195 3. NULL Ciphersuite 197 The NULL ciphersuite is basically the same as the OriginAuth 198 ciphersuite, but with a hardcoded key. This ciphersuite 199 effectively provides only data integrity without authentication, 200 and thus is subject to active attacks and is the equivalent of 201 providing a CRC. 203 The hardcoded key to be used with this ciphersuite is the 204 following: 206 HMAC_KEY : c37b7e64 92584340 207 : bed12207 80894115 208 : 5068f738 209 (The above is the test vector from RFC 3537 [WRAP].) 211 In each case the bytes which are input to the cryptographic 212 algorithm consist of the entire LTP segment except the AuthVal. In 213 particular the header extensions field which may contain the 214 ciphersuite number and the KeyID field are part of the input. 216 The output bytes of the cryptographic operation are the payload of 217 the AuthVal field. 219 The following shows an example LTP-auth header, starting from and 220 including the extensions field 222 ext tag sdnv c-s k-id 223 +----+----+----+----+----+ 224 |0x11|0x00|0x02|0x00|0x24| 225 +----+----+----+----+----+ 227 The Extensions field has the value 0x11 with the most-significant and 228 least-significant nibble value 1, indicating the presence of one 229 header and one trailer extension respectively. The next octet is the 230 extension tag (0x00 for LTP-auth), followed by the SDNV encoded 231 length of the ensuing data : a one-octet ciphersuite (0x00 meaning 232 OriginAuth) and the KeyID (in this case with a short value of 0x24). 233 The trailer extension (not shown above) should contain the AuthVal). 235 2.2 A Cookie mechanism 237 The use of cookies is a well known way to make denial-of-service 238 attacks harder to mount. We define the cookie extension for use in 239 environments where an LTP implementation is liable to such attacks. 241 The cookie is placed in a header extension field, and has no related 242 trailer extension field. It has the extension tag value 0x01. 244 The cookie value can essentially be viewed as a sufficiently long 245 random number, where the length can be determined by the 246 implementation (longer cookies are harder to guess and therefore 247 better, though using more bandwidth). Note that cookie values can be 248 derived using lots of different schemes so long as they produce 249 random looking and hard to guess values. 251 The first cookie inserted into a segment for this session is called 252 the initial cookie. 254 Note that cookies do not outlast an LTP session. 256 The basic mode of operation is that an LTP engine can include a 257 cookie in a segment at any time. After that time all segments 258 corresponding to that LTP session MUST contain a good cookie value - 259 that is, all segments both to and from the engine MUST contain a good 260 cookie. Clearly, there will be some delay before the cookie is seen 261 in incoming segments - implementations MUST determine an acceptable 262 delay for these cases, and MUST only accept segments without a cookie 263 until that time. 265 The cookie value can be extended at any time by catenating more 266 random bits. This allows both LTP engines to contribute to the 267 randomness of the cookie, where that is useful. It also allows a node 268 which considers the cookie value too short (say due to changing 269 circumstances) to add additional security. In this case, the 270 extended cookie value becomes the "to-be-checked-against" cookie 271 value for all future segments (modulo the communications delay as 272 above). 274 It can happen that both sides emit segments containing an initial 275 cookie before their peer has a chance to see any cookie. In that case 276 two cookie extension fields MUST be included in all segments 277 subsequently (once the traffic has caught up). That is, the sender 278 and recipient cookies are handled independently. In such cases, both 279 cookie values MUST be "good" at all relevant times (i.e. modulo the 280 delay). In this case, the peer's initial cookie MUST arrive before 281 the calculated delay for receipt of segments containing this engine's 282 cookie - there is only a finite window during which a second cookie 283 can be inserted into the session. 285 A "good" cookie is therefore one which starts with the currently 286 stored cookie value, or else a new cookie where none has been seen in 287 that session so far. Once a cookie value is seen and treated as 288 "good" (e.g. an extended value), the previous value is no longer 289 "good". 291 Modulo the communications delay, segments with an incorrect or 292 missing cookie value MUST be silently discarded. 294 If a segment is to be re-transmitted, (e.g. as a result of a timer 295 expiring) then it needs to contain the correct cookie value at the 296 time of (re-)transmission. Note that this may differ from what was 297 the correct cookie value at the time of the original transmission. 299 3. Security Considerations 301 While there are currently some concerns about using the SHA-1 302 algorithm, these appear to only make it easier to find collisions. In 303 that case, the use of HMAC with SHA-1 can still be considered safe. 304 However, we have changed to use SHA-256 for the signature 305 ciphersuite. 307 4. IANA Considerations 309 At present there are none known. 311 5. Acknowledgments 313 Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian 314 Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for 315 their thoughts on this protocol and its role in Delay-Tolerant 316 Networking architecture. 318 Part of the research described in this document was carried out at 319 the Jet Propulsion laboratory, California Institute of Technology, 320 under a contract with the National Aeronautics and Space 321 Administration. This work was performed under DOD Contract DAA-B07- 322 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; 323 and NASA Contract NAS7-1407. 325 Thanks are also due to Shawn Ostermann, Hans Kruse, and Dovel Myers 326 at Ohio University for their suggestions and advice in making various 327 design decisions. 329 Part of this work was carried out at Trinity College Dublin as part 330 of the Dev-SeNDT contract funded by Enterprise Ireland's technology 331 development programme. 333 6. References 335 6.1 Normative References 337 [B97] S. Bradner, "Key words for use in RFCs to Indicate Requirement 338 Levels", BCP 14, RFC 2119, March 1997. 340 [HMAC] Krawczyk, H. et al, "HMAC: Keyed-Hashing for Message 341 Authentication", RFC 2104, February 1997. 343 [LTPSPEC] Ramadas, M., Burleigh, S., and Farrell, S., "Licklider 344 Transmission Protocol - Specification", draft-irtf-dtnrg-ltp-06.txt 345 (Work in Progress), April 2007. 347 [RSA] Kaliski, B, Staddon J, "PKCS #1: RSA Cryptography 348 Specifications Version 2.1", RFC 3447, February 2003. 350 6.2 Informative References 352 [LTPMOTIVE] Burleigh, S., Ramadas, M., and Farrell, S., "Licklider 353 Transmission Protocol - Motivation", draft-irtf-dtnrg-ltp- 354 motivation-04.txt (Work in Progress), April 2007. 356 [PKIXPROF] Housley, R. et al, "Internet X.509 Public Key 357 Infrastructure Certificate and Certificate Revocation List (CRL) 358 Profile", RFC 3280, April 2002. 360 [TLS] Dierks, T., Allen, C. "The TLS Protocol - Version 1.1", RFC 361 4346, April 2006. 363 [WRAP] Schaad, J. Housley, R. "Wrapping a Hashed Message 364 Authentication Code (HMAC) key with a Triple-Data Encryption Standard 365 (DES) Key or an Advanced Encryption Standard (AES) Key", RFC 3537, 366 May 2003. 368 7. Author's Addresses 370 Stephen Farrell 371 Distributed Systems Group 372 Computer Science Department 373 Trinity College Dublin 374 Ireland 375 Telephone +353-1-608-3070 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.