doc: Add RFC documents

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]
+