RFC 5327

Licklider Transmission Protocol - Security Extensions

📅 published September 2008, from ietf

RFC 5327: Licklider Transmission Protocol - Security Extensions ✨

Okay bestie, this is RFC 5327, and it's all about adding security to LTP 🛰️ It was written by S. Farrell (Trinity College Dublin), M. Ramadas (ISTRAC, ISRO), and S. Burleigh (NASA/Jet Propulsion Laboratory). It came out in September 2008, it's Category: Experimental, and its header says Network Working Group. The header doesn't list anything it obsoletes or updates, so there's no "Obsoletes" or "Updates" line to worry about 💅

Status of This Memo 🌸

This memo defines an Experimental Protocol for the Internet community. It isn't an Internet standard of any kind, and they're literally asking for discussion and suggestions for improvement. Distribution is unlimited 🦋

IESG Note 🔥

This RFC is not a candidate for any level of Internet Standard. It represents the consensus of the Delay Tolerant Networking (DTN) Research Group of the Internet Research Task Force (IRTF). The IETF might consider standardizing it someday, but it disclaims any knowledge of whether this RFC is fit for any purpose. It also notes that the decision to publish wasn't based on IETF review of things like security, congestion control, or inappropriate interaction with deployed protocols. See RFC 3932 for more info 🙈

Abstract 🧚

The Licklider Transmission Protocol (LTP) is meant to be a reliable convergence layer over single-hop deep-space radio frequency (RF) links. It does Automatic Repeat reQuest (ARQ) for data transmissions by soliciting selective-acknowledgment reception reports. It's stateful, and there's no negotiation or handshakes, which is very chill ✨ This document describes security extensions to LTP and is part of a series of related documents about LTP.

This document is a product of the Delay Tolerant Networking Research Group, and that group reviewed it. No objections to publishing it as an RFC were raised 🎀

Table of Contents 🍓

1. Introduction ....................................................2
2. Security Extensions .............................................2
   2.1. LTP Authentication .........................................3
   2.2. A Cookie Mechanism .........................................6
3. Security Considerations .........................................7
4. IANA Considerations .............................................7
5. Acknowledgments .................................................8
6. References ......................................................8
   6.1. Normative References .......................................8
   6.2. Informative References .....................................9

1. Introduction 🦋

Okay so this document describes extensions to the base LTP protocol [LTPSPEC]. You can find the background on LTP in the "motivation" document [LTPMOTIVE]. Every extension defined here gives LTP extra security features 🔐

LTP is designed to give you retransmission-based reliability over links with extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Communication across interplanetary space is the most prominent example of this kind of environment, so LTP is mainly aimed at "long-haul" reliable transmission in interplanetary space, though it can be used in other environments too 🚀

This document describes security extensions to LTP, and it's part of a series of related documents describing LTP. The other documents in the series cover the motivation for LTP and the main protocol specification. We really recommend reading all the documents in the series before you write any code based on this one, bestie 📚

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 [B97].

2. Security Extensions 👑

The syntactical layout of the extensions is defined in Section 3.1.4 of the base protocol specification [LTPSPEC].

Implementers should note that the LTP extension mechanism allows for multiple occurrences of any extension tag, in the header, the trailer, or both. For example, the LTP authentication mechanism defined below needs both header and trailer extensions, and both of them use the same tag 🧩

This document defines new security extensions for LTP but does not address key management, since key management in Delay-Tolerant Networking (DTN) is still an open research question 🗝️

If LTP were deployed layered on top of UDP, it might be possible to use IPsec or other existing security mechanisms. In general DTN, though, IPsec's key exchange (IKE) cannot work (for example, where link delays are measured in minutes) ⏳

2.1. LTP Authentication 🔏

The LTP authentication mechanism gives you cryptographic authentication of the segment, which is a big glow-up for security 💖

Implementations MAY support this extension field. If they do not support this header, then they MUST ignore it.

The LTP authentication extension field has the extension tag value 0x00.

LTP authentication needs three new fields. The first two are carried as the value of the Extensions field of the LTP segment header, and the third is carried in the segment trailer.

The fields carried in the header extensions field get catenated together to form the extension value. The leftmost octet is the ciphersuite, and the remaining octets are the KeyID. The KeyID field is optional, and it's considered absent if the extension value is just a single octet 🌈

  • Ciphersuite: an 8-bit integer value, with the values defined below.
  • KeyID: an optional key identifier. Its interpretation is out of scope for this specification. That means implementers MUST treat these KeyID fields as raw octets, even if they contain an ASN.1 DER encoding of an X.509 IssuerSerial construct [PKIXPROF], for example.

The LTP-auth header extension MUST be present in the first segment from any LTP session that uses LTP authentication, but it MAY be omitted from subsequent segments in that session. To guard against extra problems from lost segments, implementations SHOULD, where bandwidth allows, include these fields in a number of segments in the LTP session. If the first segment (or any part of it) gets retransmitted, then the LTP-auth header extension MUST be included in the retransmission 🔁

The field carried as a trailer extension is the AuthVal field. It contains the authentication value, which is either a message authentication code (MAC) or a digital signature. It's a structured field, and its length and formatting depend on the ciphersuite 🧾

If for some reason the sender includes two instances of LTP-auth headers, the receiver could run into trouble, because presumably at least one of the AuthVal fields won't verify. There are very few situations where it would make sense to include more than one LTP-auth extension in a single segment, since LTP is a peer-to-peer protocol. However, if keys are being upgraded, the sender might protect the segment with both the new and old keys. In those cases, the receiver MUST search, and it can consider the LTP authentication valid as long as one AuthVal is correct 🔑

For all ciphersuites, the input to the calculation is the entire encoded segment, including the AuthVal extension tag and length. It does not include the AuthVal value itself 🧮

We define three ciphersuites in this specification. Our approach follows the precedent set by TLS [TLS], which "hardcodes" all algorithm options into a single ciphersuite number. That means there are 256 potential ciphersuites supported by this version of LTP-auth. Since that's a limited space, IANA has set up a registry for LTP Ciphersuites, as described in the IANA Considerations section below. The current ciphersuite assignments are:

Ciphersuite                        Value
-----------                        -----
HMAC-SHA1-80                          0
RSA-SHA256                            1
Unassigned                          2-127
Reserved                           128-191
Private/Experimental Use           192-254
NULL                                 255

1. HMAC-SHA1-80 Ciphersuite 🍬

The HMAC-SHA1-80 ciphersuite involves generating a MAC over the LTP segment and appending the resulting AuthVal field to the end of the segment. There's only one MACing algorithm defined for this, which is HMAC-SHA1-80 [HMAC]. In this case, the AuthVal field contains just the output of the HMAC-SHA1-80 algorithm, which is a fixed-width field of 10 octets.

2. RSA-SHA256 Ciphersuite 🌷

The RSA-SHA256 ciphersuite involves generating a digital signature of the LTP segment and appending the resulting AuthVal field to the end of the segment. There's only one signature algorithm currently defined for this, which is RSA with SHA256 as defined in [RSA], Section 8.2. In this case, the AuthVal field is simply the signature value, where the signature value occupies the minimum number of octets, e.g., 128 octets for a 1024-bit signature).

3. NULL Ciphersuite 🫧

The NULL ciphersuite is basically the same as HMAC-SHA1-80, except it uses a hardcoded key. This ciphersuite effectively gives you only a strong checksum without authentication. That makes it subject to active attacks, and it's basically the equivalent of a Cyclic Redundancy Check (CRC). Not the vibe for security, periodt 💀

The hardcoded key to be used with this ciphersuite is the following:

HMAC_KEY     :  c37b7e64 92584340
             :  bed12207 80894115
             :  5068f738

(The above is the test vector from RFC 3537 [WRAP].)

In each case, the bytes that are input to the cryptographic algorithm consist of the entire LTP segment except the AuthVal. In particular, the header extensions field, which may contain the ciphersuite number and the KeyID field, is part of the input.

The output bytes of the cryptographic operation are the payload of the AuthVal field.

The following shows an example LTP-auth header, starting from and including the Extensions field:

    ext  tag  sdnv  c-s  k-id
   +----+----+----+----+----+
   |0x11|0x00|0x02|0x00|0x24|
   +----+----+----+----+----+

The Extensions field has the value 0x11, with the most significant and least significant nibble values both 1. That means there's one header extension and one trailer extension, respectively 🧸 The next octet is the extension tag (0x00 for LTP-auth), followed by the Self-Delimiting Numeric Value (SDNV) encoded length of the data that follows. That data is a one-octet ciphersuite (0x00, meaning HMAC-SHA1-80) and the KeyID, which in this case has a short value of 0x24. The trailer extension (not shown above) should contain the AuthVal ✨

Okay bestie, cookies are a super well-known way to make Denial of Service (DoS) attacks harder to pull off 💀 So we define the cookie extension for environments where an LTP implementation is liable to such attacks 🛡️

The cookie goes in a header extension field and has no related trailer extension field. Its extension tag value is 0x01 🎀

The cookie value is basically a sufficiently long random number ✨ The length is up to the implementation. Longer cookies are harder to guess and therefore better, though they use more bandwidth 🦋 Note that cookie values can be derived using lots of different schemes, as long as they come out random-looking and hard to predict 💅

The first cookie inserted into a segment for this session is called the initial cookie 👑

Note that cookies do not outlast an LTP session 👋

Here's the basic vibe. An LTP engine can include a cookie in a segment at any time. After that point, all segments corresponding to that LTP session MUST contain a good cookie value. That means all segments both to and from the engine MUST contain a good cookie 🔥 Obviously there will be some delay before the cookie shows up in incoming segments, so implementations MUST determine an acceptable delay for these cases, and MUST only accept segments without a cookie until that time ⏳

The cookie value can be extended at any time by catenating more random bits 🌈 This lets both LTP engines add to the randomness, where that's useful. It also lets a node that thinks the cookie value is too short (say, because circumstances changed) add extra security. In that case, the extended cookie value becomes the "to-be-checked-against" cookie value for all future segments (modulo the communications delay as above) 💜

It can happen that both sides emit segments containing an initial cookie before their peer has a chance to see any cookie 😭 In that case, two cookie extension fields MUST be included in all segments subsequently (once the traffic has caught up). The sender and recipient cookies are handled independently. In such cases, both cookie values MUST be "good" at all relevant times (i.e., modulo the delay). The peer's initial cookie MUST arrive before the calculated delay for receipt of segments containing this engine's cookie, because there's only a finite window during which a second cookie can be inserted into the session ⌛

A "good" cookie is therefore one that starts with the currently stored cookie value, or else a new cookie where none has been seen in that session so far. Once a cookie value is seen and treated as "good" (e.g., an extended value), the previous value is no longer "good" 🙈

Modulo the communications delay, segments with an incorrect or missing cookie value MUST be silently discarded 🗑️ No segment gets a pass 🚫

If a segment is to be retransmitted (e.g., as a result of a timer expiring), then it needs to contain the correct cookie value at the time of (re)transmission. This may differ from what was the correct cookie value at the time of the original transmission 🔄

3. Security Considerations 🛡️

Okay, this part is serious, so listen up 👀 The extensions specified above are generally intended to help thwart DoS attacks. For environments where lower layers provide neither integrity nor freshness, it makes sense to use both extensions together. For example, in the case where a node extends an existing cookie, the lack of origin authentication would allow a man in the middle to lock out the session 😱

There are currently some concerns about using the SHA-1 algorithm, but these appear to only make it easier to find collisions. In that case, the use of HMAC with SHA-1 can still be considered safe 🤍 However, we have changed to use SHA-256 for the signature ciphersuite 🔐

4. IANA Considerations 📋

IANA has created and now maintains registry for known LTP ciphersuites (as defined in Section 2.1). The registry has been populated using the initial values given in Sections 2.1 and 2.2 above. IANA may assign LTP Extension Tag values from the range 2..127 (decimal, inclusive) using the Specification Required rule [GUIDE]. The specification concerned can be an RFC (whether Standards Track, Experimental, or Informational), or a specification from any other standards development organization recognized by IANA or with a liaison with the IESG, specifically including CCSDS (http://www.ccsds.org/).

5. Acknowledgments 🫶

Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for their thoughts on this protocol and its role in Delay-Tolerant Networking architecture 💖

Part of the research described in this document was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration. This work was performed under DOD Contract DAA-B07-00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; and NASA Contract NAS7-1407 🚀

Thanks are also due to Shawn Ostermann, Hans Kruse, and Dovel Myers at Ohio University for their suggestions and advice in making various design decisions. This work was done when Manikantan Ramadas was a graduate student at the EECS Dept., Ohio University, in the Internetworking Research Group Laboratory 🎓

Part of this work was carried out at Trinity College Dublin as part of the Dev-SeNDT contract funded by Enterprise Ireland's technology development programme 🍀

6. References 📚

6.1. Normative References

  • [B97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [GUIDE] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
  • [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
  • [LTPSPEC] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, September 2008.
  • [RSA] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.

6.2. Informative References

  • [LTPMOTIVE] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider Transmission Protocol - Motivation", RFC 5325, September 2008.
  • [PKIXPROF] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
  • [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
  • [WRAP] Schaad, J. and R. Housley, "Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key", RFC 3537, May 2003.

Authors' Addresses 🎀

Stephen Farrell
Computer Science Department
Trinity College Dublin
Ireland
Telephone: +353-1-896-1761
EMail: stephen.farrell@cs.tcd.ie
Manikantan Ramadas
ISRO Telemetry Tracking and Command Network (ISTRAC)
Indian Space Research Organization (ISRO)
Plot # 12 & 13, 3rd Main, 2nd Phase
Peenya Industrial Area
Bangalore 560097
India
Telephone: +91 80 2364 2602
EMail: mramadas@gmail.com
Scott C. Burleigh
Jet Propulsion Laboratory
4800 Oak Grove Drive
M/S: 301-485B
Pasadena, CA 91109-8099
Telephone: +1 (818) 393-3353
Fax: +1 (818) 354-1075
EMail: Scott.Burleigh@jpl.nasa.gov

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.

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, THE IETF TRUST 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.

Intellectual Property 🌸

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.

📦 where this page comes from