--- 1/draft-ietf-dtn-tcpclv4-27.txt 2021-10-06 11:13:10.318855919 -0700 +++ 2/draft-ietf-dtn-tcpclv4-28.txt 2021-10-06 11:13:10.474859834 -0700 @@ -1,22 +1,22 @@ Delay-Tolerant Networking B. Sipos Internet-Draft RKF Engineering Intended status: Standards Track M. Demmer -Expires: 26 March 2022 UC Berkeley +Expires: 9 April 2022 UC Berkeley J. Ott Aalto University S. Perreault - 22 September 2021 + 6 October 2021 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 - draft-ietf-dtn-tcpclv4-27 + draft-ietf-dtn-tcpclv4-28 Abstract This document describes a TCP-based convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol (BP) contents, encodings, and convergence layer requirements in BP Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 bundles as its service data unit being transported and provides a reliable transport of such bundles. @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 26 March 2022. + This Internet-Draft will expire on 9 April 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -116,29 +116,31 @@ 8.13. Predictability of Transfer IDs . . . . . . . . . . . . . 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 62 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 63 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 64 9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 64 9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 65 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 66 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 67 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 68 - 9.9. Object Identifier for PKIX Other Name Forms . . . . . . . 69 - 9.10. Object Identifier for PKIX Extended Key Usage . . . . . . 70 + 9.9. Object Identifier for PKIX Module Identifier . . . . . . 69 + 9.10. Object Identifier for PKIX Other Name Forms . . . . . . . 69 + 9.11. Object Identifier for PKIX Extended Key Usage . . . . . . 70 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 70 11.2. Informative References . . . . . . . . . . . . . . . . . 72 Appendix A. Significant changes from RFC7242 . . . . . . . . . . 74 - Appendix B. Example of bundleEID Other Name Form . . . . . . . . 75 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 + Appendix B. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 76 + Appendix C. Example of the BundleEID Other Name Form . . . . . . 78 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78 1. Introduction This document describes the TCP-based convergence-layer protocol for Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to- end architecture providing communications in and/or through highly stressed environments, including those with intermittent connectivity, long and/or variable delays, and high bit error rates. More detailed descriptions of the rationale and capabilities of these networks can be found in "Delay-Tolerant Network Architecture" @@ -1272,30 +1274,30 @@ wildcard DNS-ID is discouraged due to the complex rules for matching and dependence on implementation support for wildcard matching (see Section 6.4.3 of [RFC6125]). Network Address: If no stable DNS name is available but a stable network address is available and CA policy allows a certificate to contain a IPADDR-ID (as defined below) then one or more network addresses can be identified in the certificate. This specification defines a NODE-ID of a certificate as being the - subjectAltName entry of type otherName with a name form of - "bundleEID" (see Section 4.4.2.1) and a value limited to a Node ID. - An entity SHALL ignore any otherName with a name form of "bundleEID" - and a value which is some URI other than a Node ID. The NODE-ID is - similar to the URI-ID of [RFC6125] but restricted to a Node ID rather - than a URI with a qualified-name authority part. Unless specified - otherwise by the definition of the URI scheme being authenticated, - URI matching of a NODE-ID SHALL use the URI comparison logic of - [RFC3986] and scheme-based normalization of those schemes specified - in [I-D.ietf-dtn-bpbis]. A URI scheme can refine this "exact match" + subjectAltName entry of type otherName with a name form of BundleEID + (see Section 4.4.2.1) and a value limited to a Node ID. An entity + SHALL ignore any otherName with a name form of BundleEID and a value + which is some URI other than a Node ID. The NODE-ID is similar to + the URI-ID of [RFC6125] but restricted to a Node ID rather than a URI + with a qualified-name authority part. Unless specified otherwise by + the definition of the URI scheme being authenticated, URI matching of + a NODE-ID SHALL use the URI comparison logic of [RFC3986] and scheme- + based normalization of those schemes specified in + [I-D.ietf-dtn-bpbis]. A URI scheme can refine this "exact match" logic with rules about how Node IDs within that scheme are to be compared with the certificate-authenticated NODE-ID. This specification reuses the DNS-ID definition of Section 1.8 of [RFC6125], which is the subjectAltName entry of type dNSName whose value is encoded according to [RFC5280]. This specification defines a IPADDR-ID of a certificate as being the subjectAltName entry of type iPAddress whose value is encoded according to [RFC5280]. @@ -1331,57 +1333,57 @@ contain a NODE-ID which authenticates the Node ID of the peer. When assigned one or more stable DNS names, a TCPCL end-entity certificate SHOULD contain DNS-ID which authenticates those (fully qualified) names. When assigned one or more stable network addresses, a TCPCL end-entity certificate MAY contain IPADDR-ID which authenticates those addresses. When allowed by CA policy, a BPSec end-entity certificate SHOULD contain a PKIX Extended Key Usage extension in accordance with Section 4.2.1.12 of [RFC5280]. When the PKIX Extended Key Usage - extension is present, it SHOULD contain a key purpose "id-kp- - bundleSecurity" (see Section 4.4.2.1 and Section 9.10). Although not - specifically required by TCPCL, some networks or TLS implementations - assume the use of "id-kp-clientAuth" and "id-kp-serverAuth" are - needed for, respectively, the client-side and server-side of TLS - authentication. For interoperability, a TCPCL end-entity certificate - MAY contain an Extended Key Usage with both "id-kp-clientAuth" and - "id-kp-serverAuth" values. + extension is present, it SHOULD contain a key purpose id-kp- + bundleSecurity (see Section 4.4.2.1). Although not specifically + required by TCPCL, some networks or TLS implementations assume the + use of id-kp-clientAuth and id-kp-serverAuth are needed for, + respectively, the client-side and server-side of TLS authentication. + For interoperability, a TCPCL end-entity certificate MAY contain an + Extended Key Usage with both id-kp-clientAuth and id-kp-serverAuth + values. When allowed by CA policy, a TCPCL end-entity certificate SHOULD contain a PKIX Key Usage extension in accordance with Section 4.2.1.3 of [RFC5280]. The PKIX Key Usage bit which is consistent with TCPCL security using TLS 1.3 is digitalSignature. The specific algorithms used during the TLS handshake will determine which of those key uses are exercised. Earlier versions of TLS can mandate use of the bits keyEncipherment or keyAgreement. When allowed by CA policy, a TCPCL end-entity certificate SHOULD contain an Online Certificate Status Protocol (OCSP) URI within an Authority Information Access extension in accordance with Section 4.2.2.1 of [RFC5280]. 4.4.2.1. PKIX OID Allocations - This document defines a PKIX Other Name Form identifier of "id-on- - bundleEID" in Section 9.9 which can be used as the "type-id" in a - subjectAltName entry of type otherName. The "bundleEID" value - associated with otherName type-id "id-on-bundleEID" SHALL be a URI, + This document defines a PKIX Other Name Form identifier of id-on- + bundleEID in Appendix B which can be used as the type-id in a + subjectAltName entry of type otherName. The BundleEID value + associated with otherName type-id id-on-bundleEID SHALL be a URI, encoded as an IA5String, with a scheme which is present in the IANA "Bundle Protocol URI Scheme Type" registry [IANA-BUNDLE]. Although this otherName form allows any Endpoint ID to be present, the NODE-ID defined in Section 4.4.1 limits its use to contain only a Node ID. - This document defines a PKIX Extended Key Usage key purpose "id-kp- - bundleSecurity" in Section 9.10 which can be used to restrict a - certificate's use. The "id-kp-bundleSecurity" purpose can be - combined with other purposes in the same certificate. + This document defines a PKIX Extended Key Usage key purpose id-kp- + bundleSecurity in Appendix B which can be used to restrict a + certificate's use. The id-kp-bundleSecurity purpose can be combined + with other purposes in the same certificate. 4.4.3. TLS Handshake The use of TLS is negotiated using the Contact Header as described in Section 4.3. After negotiating an Enable TLS parameter of true, and before any other TCPCL messages are sent within the session, the session entities SHALL begin a TLS handshake in accordance with [RFC8446]. By convention, this protocol uses the entity which initiated the underlying TCP connection (the active peer) as the "client" role of the TLS handshake request. @@ -1503,25 +1505,25 @@ accordance with Section 6 of [RFC6125] using the Node ID of the peer's SESS_INIT message as the NODE-ID reference identifier. If the NODE-ID validation result is Failure or if the result is Absent and security policy requires an authenticated Node ID, the entity SHALL terminate the session (with a reason code of "Contact Failure"). 4.4.5. Policy Recommendations A RECOMMENDED security policy is to enable the use of OCSP checking during TLS handshake. A RECOMMENDED security policy is that if an - Extended Key Usage is present that it needs to contain "id-kp- - bundleSecurity" (of Section 4.4.4.1) to be usable with TCPCL - security. A RECOMMENDED security policy is to require a validated - Node ID (of Section 4.4.4.3) and to ignore any network-level - identifier (of Section 4.4.4.2). + Extended Key Usage is present that it needs to contain id-kp- + bundleSecurity (of Section 4.4.2.1) to be usable with TCPCL security. + A RECOMMENDED security policy is to require a validated Node ID (of + Section 4.4.4.3) and to ignore any network-level identifier (of + Section 4.4.4.2). This policy relies on and informs the certificate requirements in Section 4.4.3. This policy assumes that a DTN-aware CA (see Section 3.4) will only issue a certificate for a Node ID when it has verified that the private key holder actually controls the DTN node; this is needed to avoid the threat identified in Section 8.9. This policy requires that a certificate contain a NODE-ID and allows the certificate to also contain network-level identifiers. A tailored policy on a more controlled network could relax the requirement on Node ID validation and allow just network-level identifiers to @@ -2627,23 +2629,23 @@ transferred is in fact the node which the BP Agent expects it to be. In circumstances where certificates can only be issued to DNS names, Node ID validation is not possible but it could be reasonable to assume that a trusted host is not going to present an invalid Node ID. Determining when a DNS-ID/IPADDR-ID authentication can be trusted to validate a Node ID is also a policy matter outside of the scope of this document. One mitigation to arbitrary entities with valid PKIX certificates impersonating arbitrary Node IDs is the use of the PKIX Extended Key - Usage key purpose "id-kp-bundleSecurity" in Section 9.10. When this - Extended Key Usage is present in the certificate, it represents a - stronger assertion that the private key holder should in fact be + Usage key purpose id-kp-bundleSecurity (see Section 4.4.2.1). When + this Extended Key Usage is present in the certificate, it represents + a stronger assertion that the private key holder should in fact be trusted to operate as a DTN Node. 8.10. Threat: Denial of Service The behaviors described in this section all amount to a potential denial-of-service to a TCPCL entity. The denial-of-service could be limited to an individual TCPCL session, could affect other well- behaving sessions on an entity, or could affect all sessions on a host. @@ -3048,78 +3050,74 @@ +------------+--------------------------+ | 0x03 | Message Unexpected | +------------+--------------------------+ | 0x04--0xEF | Unassigned | +------------+--------------------------+ | 0xF0--0xFF | Private/Experimental Use | +------------+--------------------------+ Table 17: MSG_REJECT Reason Codes -9.9. Object Identifier for PKIX Other Name Forms +9.9. Object Identifier for PKIX Module Identifier + + IANA has created, under the "Structure of Management Information + (SMI) Numbers" registry [IANA-SMI], a sub-registry titled "SMI + Security for PKIX Module Identifier". The table is updated to + include a row "id-mod-dtn-tcpclv4-2021" for identifying the module in + Appendix B as in the following table. + + +=========+=========================+=====================+ + | Decimal | Description | References | + +=========+=========================+=====================+ + | MOD-TBD | id-mod-dtn-tcpclv4-2021 | This specification. | + +---------+-------------------------+---------------------+ + + Table 18 + +9.10. Object Identifier for PKIX Other Name Forms IANA has created, under the "Structure of Management Information (SMI) Numbers" registry [IANA-SMI], a sub-registry titled "SMI Security for PKIX Other Name Forms". The other name forms table is updated to include a row "id-on-bundleEID" for identifying DTN Endpoint IDs as in the following table. +=========+=================+=====================+ | Decimal | Description | References | +=========+=================+=====================+ | ON-TBD | id-on-bundleEID | This specification. | +---------+-----------------+---------------------+ - Table 18 - - This also corresponds with the following SMI, in ASN.1 syntax of - [X.680], for that otherName type-id and value: - - - -- The otherName type-value sequence - bundleEID OTHER-NAME ::= { BundleEID IDENTIFIED BY { id-on-bundleEID }} - - id-on-bundleEID OBJECT IDENTIFIER ::= { - iso(1) identified-organization(3) dod(6) internet(1) - security(5) mechanisms(5) pkix(7) on(8) ON-TBD } + Table 19 - -- Same encoding as GeneralName of uniformResourceIdentifier - BundleEID ::= IA5String - - The use of this OID is defined in Section 4.4.1 and Section 4.4.2. + The formal structure of the associated other name form is in + Appendix B. The use of this OID is defined in Section 4.4.1 and + Section 4.4.2. -9.10. Object Identifier for PKIX Extended Key Usage +9.11. Object Identifier for PKIX Extended Key Usage IANA has created, under the "Structure of Management Information (SMI) Numbers" registry [IANA-SMI], a sub-registry titled "SMI Security for PKIX Extended Key Purpose". The extended key purpose table is updated to include a purpose "id-kp-bundleSecurity" for identifying DTN endpoints as in the following table. +=========+======================+=====================+ | Decimal | Description | References | +=========+======================+=====================+ | KP-TBD | id-kp-bundleSecurity | This specification. | +---------+----------------------+---------------------+ - Table 19 - - This also corresponds with the following SMI, in ASN.1 syntax of - [X.680], for that key purpose: - - - id-kp-bundleSecurity OBJECT IDENTIFIER ::= { - iso(1) identified-organization(3) dod(6) internet(1) - security(5) mechanisms(5) pkix(7) kp(3) KP-TBD } - + Table 20 - The use of this OID is defined in Section 4.4.2. + The formal definition of this EKU is in Appendix B. The use of this + OID is defined in Section 4.4.2. 10. Acknowledgments This specification is based on comments on implementation of [RFC7242] provided from Scott Burleigh. 11. References 11.1. Normative References @@ -3233,20 +3231,25 @@ [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007, . [RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for Transport Layer Security (TLS)", RFC 5489, DOI 10.17487/RFC5489, March 2009, . + [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the + Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, + DOI 10.17487/RFC5912, June 2010, + . + [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [RFC7122] Kruse, H., Jero, S., and S. Ostermann, "Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP)", RFC 7122, DOI 10.17487/RFC7122, March 2014, @@ -3356,68 +3359,120 @@ * Added MSG_REJECT message to indicate an unknown or unhandled message was received. * Added TLS connection security mechanism. * Added "Not Acceptable", "Extension Failure", and "Session Terminating" XFER_REFUSE reason codes. * Added "Resource Exhaustion" SESS_TERM reason code. -Appendix B. Example of bundleEID Other Name Form +Appendix B. ASN.1 Module + + The following ASN.1 module formally specifies the BundleEID + structure, its Other Name form, and the bundleSecurity Extended Key + Usage in the syntax of [X.680]. This specification uses the ASN.1 + definitions from [RFC5912] with the 2002 ASN.1 notation used in that + document. + + + DTN-TCPCLPv4-2021 + { iso(1) identified-organization(3) dod(6) + internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-dtn-tcpclv4-2021(MOD-TBD) } + + DEFINITIONS IMPLICIT TAGS ::= + BEGIN + + IMPORTS + OTHER-NAME + FROM PKIX1Implicit-2009 -- [RFC5912] + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pkix1-implicit-02(59) } + + id-pkix + FROM PKIX1Explicit-2009 -- [RFC5912] + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pkix1-explicit-02(51) } ; + + id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } + + id-on OBJECT IDENTIFIER ::= { id-pkix 8 } + + DTNOtherNames OTHER-NAME ::= { on-bundleEID, ... } + + -- The otherName definition for Bundle EID + on-bundleEID OTHER-NAME ::= { + BundleEID IDENTIFIED BY { id-on-bundleEID } + } + + id-on-bundleEID OBJECT IDENTIFIER ::= { id-on ON-TBD } + + -- Same encoding as GeneralName of uniformResourceIdentifier + BundleEID ::= IA5String + + -- The Extended Key Usage key for bundle security + id-kp-bundleSecurity OBJECT IDENTIFIER ::= { id-kp KP-TBD } + + END + + +Appendix C. Example of the BundleEID Other Name Form EDITOR NOTE: The encoded hex part "0b" and OID segment "11" are to be replaced by ON-TBD allocated value. It was necessary to choose some OID value, so I chose the first not-allocated code point. This non-normative example demonstrates an otherName with a name form - of "bundleEID" to encode the Node ID "dtn://example/". + of BundleEID to encode the Node ID "dtn://example/". The hexadecimal form of the DER encoding of the otherName is: a01c06082b0601050507080ba010160e64746e3a2f2f6578616d706c652f And the text decoding in Figure 28 is an output of Peter Gutmann's "dumpasn1" program. 0 28: [0] { 2 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 8 11' 12 16: [0] { 14 14: IA5String 'dtn://example/' : } : } - Figure 28: Visualized decoding of the bundleEID + Figure 28: Visualized decoding of the on-bundleEID Authors' Addresses Brian Sipos RKF Engineering Solutions, LLC 7500 Old Georgetown Road Suite 1275 Bethesda, MD 20814-6198 United States of America - Email: BSipos@rkf-eng.com + Email: brian.sipos+ietf@gmail.com Michael Demmer University of California, Berkeley Computer Science Division 445 Soda Hall Berkeley, CA 94720-1776 United States of America Email: demmer@cs.berkeley.edu - Joerg Ott Aalto University Department of Communications and Networking PO Box 13000 FI-02015 Aalto Finland + Email: ott@in.tum.de Simon Perreault Quebec QC Canada Email: simon@per.reau.lt