From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7443.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc7443.txt (limited to 'doc/rfc/rfc7443.txt') diff --git a/doc/rfc/rfc7443.txt b/doc/rfc/rfc7443.txt new file mode 100644 index 0000000..e2d61e2 --- /dev/null +++ b/doc/rfc/rfc7443.txt @@ -0,0 +1,283 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Patil +Request for Comments: 7443 T. Reddy +Category: Informational G. Salgueiro +ISSN: 2070-1721 Cisco + M. Petit-Huguenin + Impedance Mismatch + January 2015 + + + Application-Layer Protocol Negotiation (ALPN) Labels + for Session Traversal Utilities for NAT (STUN) Usages + +Abstract + + Application-Layer Protocol Negotiation (ALPN) labels for Session + Traversal Utilities for NAT (STUN) usages, such as Traversal Using + Relays around NAT (TURN) and NAT discovery, are defined in this + document to allow an application layer to negotiate STUN usages + within the Transport Layer Security (TLS) connection. ALPN protocol + identifiers defined in this document apply to both TLS and Datagram + Transport Layer Security (DTLS). + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7443. + + + + + + + + + + + + + + +Patil, et al. Informational [Page 1] + +RFC 7443 ALPN for STUN/TURN January 2015 + + +Copyright Notice + + Copyright (c) 2015 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 + (http://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 and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 + 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 + 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4.1. Normative References . . . . . . . . . . . . . . . . . . 4 + 4.2. Informative References . . . . . . . . . . . . . . . . . 4 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 4 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 + +1. Introduction + + STUN can be securely transported using TLS-over-TCP (referred to as + TLS [RFC5246]), as specified in [RFC5389], or TLS-over-UDP (referred + to as DTLS [RFC6347]), as specified in [RFC7350]. + + ALPN [RFC7301] enables an endpoint to positively identify an + application protocol in TLS/DTLS and distinguish it from other TLS/ + DTLS protocols. With ALPN, the client sends the list of supported + application protocols as part of the TLS/DTLS ClientHello message. + The server chooses a protocol and sends the selected protocol as part + of the TLS/DTLS ServerHello message. Application protocol + negotiation can thus be accomplished within the TLS/DTLS handshake, + without adding network round-trips. + + STUN protocol usages, such as TURN [RFC5766], can be used to identify + the purpose of a flow without initiating a session. + + This document proposes the following ALPN labels to identify STUN + protocol [RFC5389] usages. + + + + + +Patil, et al. Informational [Page 2] + +RFC 7443 ALPN for STUN/TURN January 2015 + + + 'stun.turn': Label to identify the specific use of STUN over (D)TLS + for TURN (Section 4.6 of [RFC7350]). + + 'stun.nat-discovery': Label to identify the specific use of STUN + over (D)TLS for NAT discovery (Section 4.1 of [RFC7350]). + +2. IANA Considerations + + The following entries have been added to the "Application-Layer + Protocol Negotiation (ALPN) Protocol IDs" registry established by + [RFC7301]. + + The "stun.turn" label identifies the use of TURN usage (D)TLS: + + Protocol: Traversal Using Relays around NAT (TURN) + + Identification Sequence: 0x73 0x74 0x75 0x6E 0x2E 0x74 0x75 0x72 + 0x6E ("stun.turn") + + Specification: This document (RFC 7443) + + The "stun.nat-discovery" label identifies the use of STUN for the + purposes of NAT discovery over (D)TLS: + + Protocol: NAT discovery using Session Traversal Utilities for NAT + (STUN) + + Identification Sequence: 0x73 0x74 0x75 0x6E 0x2E 0x6e 0x61 0x74 + 0x2d 0x64 0x69 0x73 0x63 0x6f 0x76 0x65 0x72 0x79 + ("stun.nat-discovery") + + Specification: This document (RFC 7443) + +3. Security Considerations + + The ALPN STUN protocol identifier does not introduce any specific + security considerations beyond those detailed in the TLS ALPN + Extension specification [RFC7301]. It also does not impact the + security of TLS/DTLS session establishment or application data + exchange. + + + + + + + + + + + +Patil, et al. Informational [Page 3] + +RFC 7443 ALPN for STUN/TURN January 2015 + + +4. References + +4.1. Normative References + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008, + . + + [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for NAT (STUN)", RFC 5389, + October 2008, . + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, January 2012, + . + + [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, + "Transport Layer Security (TLS) Application-Layer Protocol + Negotiation Extension", RFC 7301, July 2014, + . + + [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport + Layer Security (DTLS) as Transport for Session Traversal + Utilities for NAT (STUN)", RFC 7350, August 2014, + . + +4.2. Informative References + + [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using + Relays around NAT (TURN): Relay Extensions to Session + Traversal Utilities for NAT (STUN)", RFC 5766, April 2010, + . + +Acknowledgements + + This work benefited from the discussions and invaluable input by the + various members of the TRAM working group. These include Simon + Perrault, Paul Kyzivat, Brandon Williams, and Andrew Hutton. Special + thanks to Martin Thomson and Oleg Moskalenko for their constructive + comments, suggestions, and early reviews that were critical to the + formulation and refinement of this document. + + Barry Leiba, Stephen Farrell, Adrian Farrel, and Richard Barnes + provided useful feedback during IESG review. Thanks to Russ Housley + for his Gen-ART review and Adam Langley for his IETF LC review + comments as TLS expert. + + + + + +Patil, et al. Informational [Page 4] + +RFC 7443 ALPN for STUN/TURN January 2015 + + + The authors would also like to express their gratitude to the TRAM WG + chairs Gonzalo Camarillo and especially Simon Perrault, who also + acted as document shepherd. Lastly, we also want to thank the + Transport Area Director Spencer Dawkins for his support and careful + reviews. + +Authors' Addresses + + Prashanth Patil + Cisco Systems, Inc. + Bangalore + India + + EMail: praspati@cisco.com + + + Tirumaleswar Reddy + Cisco Systems, Inc. + Cessna Business Park, Varthur Hobli + Sarjapur Marathalli Outer Ring Road + Bangalore, Karnataka 560103 + India + + EMail: tireddy@cisco.com + + + Gonzalo Salgueiro + Cisco Systems, Inc. + 7200-12 Kit Creek Road + Research Triangle Park, NC 27709 + United States + + EMail: gsalguei@cisco.com + + + Marc Petit-Huguenin + Impedance Mismatch + United States + + EMail: marc@petit-huguenin.org + + + + + + + + + + + +Patil, et al. Informational [Page 5] + -- cgit v1.2.3