summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5327.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5327.txt')
-rw-r--r--doc/rfc/rfc5327.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc5327.txt b/doc/rfc/rfc5327.txt
new file mode 100644
index 0000000..a3db6d1
--- /dev/null
+++ b/doc/rfc/rfc5327.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group S. Farrell
+Request for Comments: 5327 Trinity College Dublin
+Category: Experimental M. Ramadas
+ ISTRAC, ISRO
+ S. Burleigh
+ NASA/Jet Propulsion Laboratory
+ September 2008
+
+
+ Licklider Transmission Protocol - Security Extensions
+
+Status of This Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo 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). It may be
+ considered for standardization by the IETF in the future, but the
+ IETF disclaims any knowledge of the fitness of this RFC for any
+ purpose and in particular notes that the decision to publish is not
+ based on IETF review for such things as security, congestion control,
+ or inappropriate interaction with deployed protocols. See RFC 3932
+ for more information.
+
+Abstract
+
+ The Licklider Transmission Protocol (LTP) is intended to serve as a
+ reliable convergence layer over single-hop deep-space radio frequency
+ (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data
+ transmissions by soliciting selective-acknowledgment reception
+ reports. It is stateful and has no negotiation or handshakes. This
+ document describes security extensions to LTP, and is part of a
+ series of related documents describing LTP.
+
+ This document is a product of the Delay Tolerant Networking Research
+ Group and has been reviewed by that group. No objections to its
+ publication as an RFC were raised.
+
+
+
+
+
+
+
+
+Farrell, et al. Experimental [Page 1]
+
+RFC 5327 LTP - Extensions September 2008
+
+
+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
+
+ This document describes extensions to the base LTP protocol
+ [LTPSPEC]. The background to LTP is described in the "motivation"
+ document [LTPMOTIVE]. All the extensions defined in this document
+ provide additional security features for LTP.
+
+ LTP is designed to provide retransmission-based reliability over
+ links characterized by extremely long message round-trip times (RTTs)
+ and/or frequent interruptions in connectivity. Since communication
+ across interplanetary space is the most prominent example of this
+ sort of environment, LTP is principally aimed at supporting "long-
+ haul" reliable transmission in interplanetary space, but has
+ applications in other environments as well.
+
+ This document describes security extensions to LTP, and is part of a
+ series of related documents describing LTP. Other documents in this
+ series cover the motivation for LTP and the main protocol
+ specification. We recommend reading all the documents in the series
+ before writing code based on this document.
+
+ 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 are 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 both (or either) the
+ header or trailer. For example, the LTP authentication mechanism
+ defined below requires both header and trailer extensions, which both
+ use the same tag.
+
+
+
+Farrell, et al. Experimental [Page 2]
+
+RFC 5327 LTP - Extensions September 2008
+
+
+ This document defines new security extensions for LTP but does not
+ address key management since key management in Delay-Tolerant
+ Networking (DTN) remains 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. However, in general
+ DTN, IPsec's key exchange (IKE) cannot work (e.g., where link delays
+ are measured in minutes).
+
+2.1. LTP Authentication
+
+ The LTP authentication mechanism provides cryptographic
+ authentication of the segment.
+
+ 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 requires three new fields, the first two of which
+ are carried as the value of the Extensions field of the LTP segment
+ header, and the third of which is carried in the segment trailer.
+
+ The fields that are carried in the header extensions field are
+ catenated together to form the extension value (with the leftmost
+ octet representing the ciphersuite and the remaining octets the
+ KeyID). The KeyID field is optional, and is determined to be absent
+ if the extension value consists of a single octet.
+
+ Ciphersuite: an 8-bit integer value with values defined below.
+
+ KeyID: An optional key identifier, the interpretation of which is
+ out of scope for this specification (that is, implementers MUST
+ treat these KeyID fields as raw octets, even if they contained 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 MAY be omitted
+ from subsequent segments in that session. To guard against
+ additional problems arising 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
+ thereof) is retransmitted, then the LTP-auth header extension MUST be
+ included in the retransmission.
+
+
+
+
+
+Farrell, et al. Experimental [Page 3]
+
+RFC 5327 LTP - Extensions September 2008
+
+
+ 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. This is itself a
+ structured field whose length and formatting depend on the
+ ciphersuite.
+
+ If for some reason the sender includes two instances of LTP-auth
+ headers, then there is a potential problem for the receiver in that
+ presumably at least one of the AuthVal fields will not 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. If however, keys are being upgraded, then the
+ sender might protect the segment with both the new and old keys. In
+ such cases, the receiver MUST search and can consider the LTP
+ authentication valid so 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, but
+ not of course, including the AuthVal value.
+
+ We define three ciphersuites in this specification. Our approach is
+ to follow the precedent set by TLS [TLS], and to "hardcode" all
+ algorithm options in a single ciphersuite number. This means that
+ there are 256 potential ciphersuites supported by this version of
+ LTP-auth. Since this is a limited space, IANA has established a
+ registry for LTP Ciphersuites as described in the IANA Considerations
+ section below. 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 is only one MACing algorithm defined for
+ this, which is HMAC-SHA1-80 [HMAC]. The AuthVal field in this
+ case contains just the output of the HMAC-SHA1-80 algorithm, which
+ is a fixed-width field (10 octets).
+
+
+
+
+
+
+Farrell, et al. Experimental [Page 4]
+
+RFC 5327 LTP - Extensions September 2008
+
+
+ 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 is only one signature algorithm
+ currently defined for this, which is RSA with SHA256 as defined in
+ [RSA], Section 8.2. The AuthVal field in this case 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 the HMAC-SHA1-80
+ ciphersuite, but with a hardcoded key. This ciphersuite
+ effectively provides only a strong checksum without
+ authentication, and thus is subject to active attacks and is the
+ equivalent of providing a Cyclic Redundancy Check (CRC).
+
+ 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 that 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|
+ +----+----+----+----+----+
+
+
+
+
+
+
+
+
+
+
+Farrell, et al. Experimental [Page 5]
+
+RFC 5327 LTP - Extensions September 2008
+
+
+ The Extensions field has the value 0x11 with the most significant and
+ least significant nibble value 1, indicating the presence of one
+ header 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 ensuing data: a
+ one-octet ciphersuite (0x00 meaning HMAC-SHA1-80) and the KeyID (in
+ this case with a short value of 0x24). The trailer extension (not
+ shown above) should contain the AuthVal.
+
+2.2. A Cookie Mechanism
+
+ The use of cookies is a well-known way to make Denial of Service
+ (DoS) attacks harder to mount. We define the cookie extension for
+ use in environments where an LTP implementation is liable to such
+ attacks.
+
+ The cookie is placed in a header extension field, and has no related
+ trailer extension field. It has the extension tag value 0x01.
+
+ The cookie value can essentially be viewed as a sufficiently long
+ random number, where the length can be determined by the
+ implementation (longer cookies are harder to guess and therefore
+ better, though using more bandwidth). Note that cookie values can be
+ derived using lots of different schemes so long as they produce
+ random-looking and hard-to-predict values.
+
+ The first cookie inserted into a segment for this session is called
+ the initial cookie.
+
+ Note that cookies do not outlast an LTP session.
+
+ The basic mode of operation is that an LTP engine can include a
+ cookie in a segment at any time. After that time, all segments
+ corresponding to that LTP session MUST contain a good cookie value --
+ that is, all segments both to and from the engine MUST contain a good
+ cookie. Clearly, there will be some delay before the cookie is seen
+ in incoming segments -- 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 allows both LTP engines to contribute to the
+ randomness of the cookie, where that is useful. It also allows a
+ node that considers the cookie value too short (say due to changing
+ circumstances) to add additional security. In this case, the
+ extended cookie value becomes the "to-be-checked-against" cookie
+ value for all future segments (modulo the communications delay as
+ above).
+
+
+
+Farrell, et al. Experimental [Page 6]
+
+RFC 5327 LTP - Extensions September 2008
+
+
+ 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). That is, 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). In this case, the peer's initial cookie MUST arrive before
+ the calculated delay for receipt of segments containing this engine's
+ cookie -- there is 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.
+
+ 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. Note that this may differ from what was
+ the correct cookie value at the time of the original transmission.
+
+3. Security Considerations
+
+ 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.
+
+ While there are currently some concerns about using the SHA-1
+ algorithm, 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
+
+
+
+Farrell, et al. Experimental [Page 7]
+
+RFC 5327 LTP - Extensions September 2008
+
+
+ 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.
+
+
+
+
+Farrell, et al. Experimental [Page 8]
+
+RFC 5327 LTP - Extensions 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, et al. Experimental [Page 9]
+
+RFC 5327 LTP - Extensions September 2008
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, et al. Experimental [Page 10]
+
+RFC 5327 LTP - Extensions September 2008
+
+
+Full Copyright Statement
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, et al. Experimental [Page 11]
+