idnits 2.17.1 draft-irtf-dtnrg-ltp-extensions-08.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 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 448. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 454. 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 232 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 ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (ref. 'GUIDE') (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 3447 (ref. 'RSA') (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 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 June 24 2008 S. Burleigh 7 Expires December 24 2008 NASA/Jet Propulsion Laboratory 9 Licklider Transmission Protocol - Security 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 (2008). 40 Abstract 42 The Licklider Transmission Protocol (LTP), is intended to serve as a 43 reliable convergence layer over single hop deep-space RF links. LTP 44 does Automatic Repeat reQuest (ARQ) of data transmissions by 45 soliciting selective-acknowledgment reception reports. It is 46 stateful and has no negotiation or handshakes. 48 LTP is designed to provide retransmission-based reliability over 49 links characterized by extremely long message round-trip times (RTTs) 50 and/or frequent interruptions in connectivity. Since communication 51 across interplanetary space is the most prominent example of this 52 sort of environment, LTP is principally aimed at supporting "long- 53 haul" reliable transmission in interplanetary space, but has 54 applications in other environments as well. 56 This document describes security extensions to LTP, and is part of a 57 series of related documents describing LTP. Other documents in this 58 series cover the motivation for LTP and the main protocol 59 specification. We recommend reading all the documents in the series 60 before writing code based on this document. 62 This document is a product of the Delay Tolerant Networking Research 63 Group and has been reviewed by that group. No objections to its 64 publication as an RFC were raised. 66 Table of Contents 68 1. Introduction.................................................. 2 69 2. Security Extensions........................................... 3 70 2.1 LTP Authentication ...................................... 3 71 2.2 Cookie Mechanism......................................... 6 72 3. Security Considerations ...................................... 7 73 4. IANA Considerations .......................................... 7 74 5. Acknowledgments .............................................. 7 75 6. References ................................................... 8 76 6.1 Normative References ..................................... 8 77 6.2 Informative References ................................... 8 78 7. Author's Addresses ........................................... 9 80 1. Introduction 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [B97]. 86 This document describes extensions to the base LTP protocol 87 [LTPSPEC]. The background to LTP is described in the "motivation" 88 document [LTPMOTIVE]. All the extensions defined in this document 89 provide additional security features for LTP. 91 2. Security Extensions 93 The syntactical layout of the extensions are defined in Section 3.1.4 94 of the base protocol specification [LTPSPEC]. 96 Implementers should note that the LTP extension mechanism allows for 97 multiple occurrences of any extension tag, in both (or either) the 98 header or trailer. For example, the LTP authentication mechanism 99 defined below requires both header and trailer extensions, which both 100 use the same tag. 102 This document defines new security extensions for LTP but does not 103 address key management since key management in DTNs remains an open 104 research question. 106 If LTP were deployed layered on top of UDP, it might be possible to 107 use IPsec or other existing security mechanisms. In a general DTN 108 however IPsec's key exchange (IKE) cannot work (e.g. where link 109 delays are measured in minutes). 111 2.1 LTP Authentication 113 The LTP Authentication mechanism provides cryptographic 114 authentication of the segment. 116 Implementations MAY support this extension field. If they do not 117 support this header then they MUST ignore it. 119 The LTP authentication extension field has the extension tag value 120 0x00. 122 LTP authentication requires three new fields, the first two of which 123 are carried as the value of the extensions field of the LTP segment 124 header, and the third of which is carried in the segment trailer. 126 The fields which are carried in the header extensions field are 127 catenated together to form the extension value (with the leftmost 128 octet representing the ciphersuite and the remaining octets the 129 KeyID). The KeyID field is optional, and is determined to be absent 130 if the extension value consists of a single octet. 132 Ciphersuite: an eight bit integer value with values defined below. 134 KeyID: An optional key identifier, the interpretation of which is 135 out of scope for this specification (that is, implementers MUST 136 treat these KeyID fields as raw octets, even if they contained an 137 ASN.1 DER encoding of an X.509 IssuerSerial construct [PKIXPROF], 138 for example). 140 The LTP-auth header extension MUST be present in the first segment 141 from any LTP session which uses LTP authentication, but MAY be 142 omitted from subsequent segments in that session. To guard against 143 additional problems arising from lost segments, implementations 144 SHOULD, where bandwidth allows, include these fields in a number of 145 segments in the LTP session. If the first segment (or any part 146 thereof) is re-transmitted, then the LTP-auth header extension MUST 147 be included in the re-transmission. 149 The field carried as a trailer extension is the AuthVal field. It 150 contains the authentication value, which is either a message 151 authentication code (MAC) or a digital signature. This is itself a 152 structured field whose length and formatting depends on the 153 ciphersuite. 155 If for some reason the sender includes two instances of LTP auth 156 headers then there is a potential problem for the receiver in that 157 presumably at least one of the AuthVal fields will not verify. There 158 are very few situations where it would make sense to include more 159 than one LTP auth extension in a single segment, since LTP is a peer- 160 to-peer protocol. If however, keys are being upgraded then the sender 161 might protect the segment with both the new and old keys. In such 162 cases the receiver MUST search and can consider the LTP 163 authentication valid so long as one AuthVal is correct. 165 For all ciphersuites, the input to the calculation is the entire 166 encoded segment including the AuthVal extension tag and length, but 167 not of course, including the AuthVal value. 169 We define three ciphersuites in this specification. Our approach is 170 to follow the precedent set by TLS [TLS], and to "hardcode" all 171 algorithm options in a single ciphersuite number. This means that 172 there are 256 potential ciphersuites supported by this version of 173 LTP-auth. Since this is a limited space, we request IANA to establish 174 a registry for LTP Ciphersuites as described in the IANA 175 considerations section below. Current ciphersuite assignments are: 177 Ciphersuite Value 178 ----------- ----- 179 HMAC-SHA1-80 0 180 RSA-SHA256 1 181 Unassigned 2-127 182 Reserved 128-191 183 Private/Experimental use 192-254 184 NULL 255 186 1. HMAC-SHA1-80 Ciphersuite 188 The HMAC-SHA1-80 ciphersuite involves generating a MAC over the 189 LTP segment and appending the resulting AuthVal field to the end 190 of the segment. There is only one MACing algorithm defined for 191 this which is HMAC-SHA1-80 [HMAC]. The AuthVal field in this case 192 contains just the output of the HMAC-SHA1-80 algorithm which is a 193 fixed width field (10 octets). 195 2. RSA-SHA256 Ciphersuite 197 The RSA-SHA256 ciphersuite involves generating a digital signature 198 of the LTP segment and appending the resulting AuthVal field to 199 the end of the segment. There is only one signature algorithm 200 currently defined for this which is RSA with SHA256 as defined in 201 [RSA], section 8.2. The AuthVal field in this case is simply the 202 signature value, where the signature value occupies the minimum 203 number of octets, e.g. 128 octets for a 1024 bit signature). 205 3. NULL Ciphersuite 207 The NULL ciphersuite is basically the same as the HMAC-SHA1-80 208 ciphersuite, but with a hardcoded key. This ciphersuite 209 effectively provides only a strong checksum without 210 authentication, and thus is subject to active attacks and is the 211 equivalent of providing a CRC. 213 The hardcoded key to be used with this ciphersuite is the 214 following: 216 HMAC_KEY : c37b7e64 92584340 217 : bed12207 80894115 218 : 5068f738 219 (The above is the test vector from RFC 3537 [WRAP].) 221 In each case the bytes which are input to the cryptographic 222 algorithm consist of the entire LTP segment except the AuthVal. In 223 particular the header extensions field which may contain the 224 ciphersuite number and the KeyID field are part of the input. 226 The output bytes of the cryptographic operation are the payload of 227 the AuthVal field. 229 The following shows an example LTP-auth header, starting from and 230 including the extensions field 232 ext tag sdnv c-s k-id 233 +----+----+----+----+----+ 234 |0x11|0x00|0x02|0x00|0x24| 235 +----+----+----+----+----+ 237 The Extensions field has the value 0x11 with the most-significant and 238 least-significant nibble value 1, indicating the presence of one 239 header and one trailer extension respectively. The next octet is the 240 extension tag (0x00 for LTP-auth), followed by the SDNV encoded 241 length of the ensuing data : a one-octet ciphersuite (0x00 meaning 242 HMAC-SHA1-80) and the KeyID (in this case with a short value of 243 0x24). The trailer extension (not shown above) should contain the 244 AuthVal). 246 2.2 A Cookie mechanism 248 The use of cookies is a well known way to make denial-of-service 249 attacks harder to mount. We define the cookie extension for use in 250 environments where an LTP implementation is liable to such attacks. 252 The cookie is placed in a header extension field, and has no related 253 trailer extension field. It has the extension tag value 0x01. 255 The cookie value can essentially be viewed as a sufficiently long 256 random number, where the length can be determined by the 257 implementation (longer cookies are harder to guess and therefore 258 better, though using more bandwidth). Note that cookie values can be 259 derived using lots of different schemes so long as they produce 260 random-looking and hard-to-predict values. 262 The first cookie inserted into a segment for this session is called 263 the initial cookie. 265 Note that cookies do not outlast an LTP session. 267 The basic mode of operation is that an LTP engine can include a 268 cookie in a segment at any time. After that time all segments 269 corresponding to that LTP session MUST contain a good cookie value - 270 that is, all segments both to and from the engine MUST contain a good 271 cookie. Clearly, there will be some delay before the cookie is seen 272 in incoming segments - implementations MUST determine an acceptable 273 delay for these cases, and MUST only accept segments without a cookie 274 until that time. 276 The cookie value can be extended at any time by catenating more 277 random bits. This allows both LTP engines to contribute to the 278 randomness of the cookie, where that is useful. It also allows a node 279 which considers the cookie value too short (say due to changing 280 circumstances) to add additional security. In this case, the 281 extended cookie value becomes the "to-be-checked-against" cookie 282 value for all future segments (modulo the communications delay as 283 above). 285 It can happen that both sides emit segments containing an initial 286 cookie before their peer has a chance to see any cookie. In that case 287 two cookie extension fields MUST be included in all segments 288 subsequently (once the traffic has caught up). That is, the sender 289 and recipient cookies are handled independently. In such cases, both 290 cookie values MUST be "good" at all relevant times (i.e. modulo the 291 delay). In this case, the peer's initial cookie MUST arrive before 292 the calculated delay for receipt of segments containing this engine's 293 cookie - there is only a finite window during which a second cookie 294 can be inserted into the session. 296 A "good" cookie is therefore one which starts with the currently 297 stored cookie value, or else a new cookie where none has been seen in 298 that session so far. Once a cookie value is seen and treated as 299 "good" (e.g. an extended value), the previous value is no longer 300 "good". 302 Modulo the communications delay, segments with an incorrect or 303 missing cookie value MUST be silently discarded. 305 If a segment is to be re-transmitted, (e.g. as a result of a timer 306 expiring) then it needs to contain the correct cookie value at the 307 time of (re-)transmission. Note that this may differ from what was 308 the correct cookie value at the time of the original transmission. 310 3. Security Considerations 312 The extensions specified above are generally intended to help thwart 313 DoS attacks. For environments where lower layers provide neither 314 integrity nor freshness, it makes sense to use both extensions 315 together. For example, in the case where a node extends an existing 316 cookie, the lack of origin authentication would allow a man in the 317 middle to lock out the session. 319 While there are currently some concerns about using the SHA-1 320 algorithm, these appear to only make it easier to find collisions. In 321 that case, the use of HMAC with SHA-1 can still be considered safe. 322 However, we have changed to use SHA-256 for the signature 323 ciphersuite. 325 4. IANA Considerations 327 <> 335 Section 2.1 above calls for a new registry to be created by the IANA, 336 maintaining the set of known LTP ciphersuites. The registry will be 337 initially populated using the values given in Section 2.1 above. IANA 338 may assign LTP Extension Tag values from the range 2..127 (decimal, 339 inclusive) using the Specifiction Required rule. [GUIDE] The 340 Specification concerned can be an RFC (whether Standards Track, 341 Experimental or Informational), or a specification from any other 342 standards development organisation recognised by IANA or with a 343 liaison with the IESG, specifically including CCSDS. 344 (http://www.ccsds.org/) 346 5. Acknowledgments 348 Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian 349 Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for 350 their thoughts on this protocol and its role in Delay-Tolerant 351 Networking architecture. 353 Part of the research described in this document was carried out at 354 the Jet Propulsion laboratory, California Institute of Technology, 355 under a contract with the National Aeronautics and Space 356 Administration. This work was performed under DOD Contract DAA-B07- 357 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; 358 and NASA Contract NAS7-1407. 360 Thanks are also due to Shawn Ostermann, Hans Kruse, and Dovel Myers 361 at Ohio University for their suggestions and advice in making various 362 design decisions. 364 Part of this work was carried out at Trinity College Dublin as part 365 of the Dev-SeNDT contract funded by Enterprise Ireland's technology 366 development programme. 368 6. References 370 6.1 Normative References 372 [B97] S. Bradner, "Key words for use in RFCs to Indicate Requirement 373 Levels", BCP 14, RFC 2119, March 1997. 375 [GUIDE] Narten, T. & Alvestrand, H. "Guidelines for Writing IANA 376 Considerations Sections in RFCs," BCP 26, RFC 5226, May 2008. 378 [HMAC] Krawczyk, H. et al, "HMAC: Keyed-Hashing for Message 379 Authentication", RFC 2104, February 1997. 381 [LTPSPEC] Ramadas, M., Burleigh, S., and Farrell, S., "Licklider 382 Transmission Protocol - Specification", draft-irtf-dtnrg-ltp-10.txt 383 (Work in Progress), June 2008. 385 [RSA] Kaliski, B, Staddon J, "PKCS1: RSA Cryptography Specifications 386 Version 2.1", RFC 3447, February 2003. 388 6.2 Informative References 390 [LTPMOTIVE] Burleigh, S., Ramadas, M., and Farrell, S., "Licklider 391 Transmission Protocol - Motivation", draft-irtf-dtnrg-ltp- 392 motivation-07.txt (Work in Progress), June 2008. 394 [PKIXPROF] Cooper, D., et al, "Internet X.509 Public Key 395 Infrastructure Certificate and Certificate Revocation List (CRL) 396 Profile", RFC 5280, May 2008. 398 [TLS] Dierks, T., Allen, C. "The TLS Protocol - Version 1.1", RFC 399 4346, April 2006. 401 [WRAP] Schaad, J. Housley, R. "Wrapping a Hashed Message 402 Authentication Code (HMAC) key with a Triple-Data Encryption Standard 403 (DES) Key or an Advanced Encryption Standard (AES) Key", RFC 3537, 404 May 2003. 406 7. Author's Addresses 408 Stephen Farrell 409 Computer Science Department 410 Trinity College Dublin 411 Ireland 412 Telephone +353-1-896-1761 413 Email stephen.farrell@cs.tcd.ie 415 Manikantan Ramadas 416 Internetworking Research Group 417 301 Stocker Center 418 Ohio University 419 Athens, OH 45701 420 Telephone +1 (740) 593-1562 421 Email mramadas@irg.cs.ohiou.edu 423 Scott C. Burleigh 424 Jet Propulsion Laboratory 425 4800 Oak Grove Drive 426 M/S: 301-485B 427 Pasadena, CA 91109-8099 428 Telephone +1 (818) 393-3353 429 FAX +1 (818) 354-1075 430 Email Scott.Burleigh@jpl.nasa.gov 432 Intellectual Property Statement 434 The IETF takes no position regarding the validity or scope of any 435 Intellectual Property Rights or other rights that might be claimed to 436 pertain to the implementation or use of the technology described in 437 this document or the extent to which any license under such rights 438 might or might not be available; nor does it represent that it has 439 made any independent effort to identify any such rights. Information 440 on the procedures with respect to rights in RFC documents can be 441 found in BCP 78 and BCP 79. 443 Copies of IPR disclosures made to the IETF Secretariat and any 444 assurances of licenses to be made available, or the result of an 445 attempt made to obtain a general license or permission for the use of 446 such proprietary rights by implementers or users of this 447 specification can be obtained from the IETF on-line IPR repository at 448 http://www.ietf.org/ipr. 450 The IETF invites any interested party to bring to its attention any 451 copyrights, patents or patent applications, or other proprietary 452 rights that may cover technology that may be required to implement 453 this standard. Please address the information to the IETF at ietf- 454 ipr@ietf.org. 456 Disclaimer of Validity 458 This document and the information contained herein are provided on an 459 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 460 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 461 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 462 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 463 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 464 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 466 Copyright Statement 468 Copyright (C) The IETF Trust (2008). This document is subject to the 469 rights, licenses and restrictions contained in BCP 78, and except as 470 set forth therein, the authors retain all their rights. 472 Acknowledgment 474 Funding for the RFC Editor function is currently provided by the 475 Internet Society.