RFC 4248

The telnet URI Scheme

📅 published October 2005, from ietf

RFC 4248: The telnet URI Scheme 🎀

okay bestie, this is RFC 4248 and it's giving standards-track main character energy 💅✨

  • Network Working Group: IETF 🌸
  • Author: Paul Hoffman, VPN Consortium 🧚
  • Category: Standards Track 👑
  • Date: October 2005 🍓
  • Obsoletes: 1738 💀

Status of This Memo

ngl this section is the official "here's what this doc is" disclaimer 🙈 It's an Internet standards track protocol for the Internet community, and it's basically asking everyone to talk about it and suggest improvements 💜 For the current standardization state and status, check the latest edition of the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🦋

Copyright (C) The Internet Society (2005) 🌈

Abstract

so this doc spells out the telnet Uniform Resource Identifier (URI) scheme, which was first written up in RFC 1738 🦋 The whole point is to make RFC 1738 obsolete while keeping the info about this scheme on standards track 🫶

1. Introduction ✨

URIs were first defined in [RFC2396], which was then updated by [RFC3986] 💖 Those docs also explain how to define schemes for URIs 🎀

Lowkey the first definition for a lot of URI schemes showed up in [RFC1738] 🌸 Since that doc is now obsolete, this one copies the telnet URI scheme over so that material can stay on standards track 🔥

2. Scheme Definition

okay so the Telnet URL scheme is used to point at interactive services that you can reach with the Telnet protocol [STD8] 💅

A telnet URL looks like this 👑

telnet://<user>:<password>@<host>:<port>/

The final "/" can be left off 🍓 If :<port> is left out, the port defaults to 23 ✨ The :<password> is optional, and so is the whole <user>:<password> part 🙈 Few implementations handle the user name and password very well, if at all 💀

This URL doesn't point to a data object 🦋 It points to an interactive service instead 🧚 Remote interactive services are all over the place when it comes to how they let you log in, so in practice the <user> and <password> you give are advisory only 🫶 Clients that open a telnet URL just tell the user the suggested username and password 💜

Also, a bunch of RFCs have added services to Telnet for better authentication, encryption of traffic, or both 🌈 Those RFCs didn't make up new URI schemes for Telnet to call those services, the way "https" is its own scheme separate from "http" 🎀 Some modern telnet clients try to use those more-secure versions of Telnet when they resolve a "telnet" URL ⭐

3. Security Considerations

Security is serious here, bestie 💀 There are lots of security considerations for URI schemes, and they're discussed in [RFC3986] 🔥

Telnet normally sends passwords in the clear for authentication, and normally gives you no privacy 😭 In normal telnet, both the user's identity and their password are exposed with zero protection 💀 After that, the entire contents of the Telnet session are exposed with zero protection too 💀

Lots of extensions have been added to Telnet to make it more secure in different ways 🛡️ In particular, [RFC2941] gives a framework built on a telnet option, and a lot of other security extensions have leveraged off of it 🎀 These extensions are definitely worthwhile for fixing the obvious problems with exposing the user's name, password, and session plaintext in the clear 🫶

Here's the tea 🍵 Some modern telnet clients try to use those more-secure versions of Telnet when they resolve a "telnet" URL, but other telnet clients don't 😭 So a user can't count on this kind of security unless it's explicitly enabled AND the results of the security negotiation are checked 🔥

4. Normative References

[STD8]     Postel, J. and J. Reynolds, "Telnet Protocol
           Specification", STD 8, RFC 854, May 1983.

5. Informative References

[RFC1738]  Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
           Resource Locators (URL)", RFC 1738, December 1994.

[RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
           Resource Identifiers (URI): Generic Syntax", RFC 2396,
           August 1998.

[RFC2941]  Ts'o, T. and J. Altman, "Telnet Authentication Option",
           RFC 2941, September 2000.

[RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
           Resource Identifier (URI): Generic Syntax", STD 66,
           RFC 3986, January 2005.

Author's Address 🧚

Paul Hoffman
VPN Consortium
127 Segre Place
Santa Cruz, CA  95060
US

EMail: paul.hoffman@vpnc.org

Copyright (C) The Internet Society (2005) 🌈

This document is subject to the rights, licenses and restrictions contained in BCP 78, 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 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 on 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 on whether any license under those rights might or might not be available 🤷‍♀️ It also doesn't claim it has made any independent effort to identify any such rights 💜 Info on how rights work for RFC documents is in BCP 78 and BCP 79 📚

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users to use these proprietary rights can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🦋

The IETF invites any interested party to tell it about any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to implement this standard 🫶 Send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society 🌸 periodt, that's the whole RFC ✨

📦 where this page comes from