RFC 2944

Telnet Authentication: SRP

📅 published September 2000, from ietf

RFC 2944: Telnet Authentication: SRP 🎀

Part 1 of 2 💖

okay bestie, this is RFC 2944, "Telnet Authentication: SRP" 🦋 It was written by T. Wu at Standford University (yes, that's how the header spells it 😭). It's a Standards Track doc dated September 2000, and its title block doesn't list anything it obsoletes or updates. Basically it's the SRP flavour of the Telnet authentication option, plugged into the framework from RFC 2941 ✨

Status of This Memo

this doc specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 💅 for the standardization state and status of this protocol, check the current "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited 🌸

Copyright (C) The Internet Society (2000). All Rights Reserved. 🫶

Abstract

this one's giving scope 🔥 it sets up an authentication scheme for the Telnet protocol under the framework described in [RFC2941], using the Secure Remote Password Protocol (SRP) authentication mechanism. the specific mechanism, SRP-SHA1, is described in [RFC2945].

1. Command Names and Codes ✨

okay so here's the cast list of names and numbers 🧚 the authentication type is SRP, and the suboption commands are AUTH, REJECT, ACCEPT, CHALLENGE, RESPONSE, EXP, and PARAMS. no notes, just vibes:

   Authentication Types

      SRP          5

   Suboption Commands

      AUTH         0
      REJECT       1
      ACCEPT       2
      CHALLENGE    3
      RESPONSE     4

      EXP          8
      PARAMS       9

2. Command Meanings 💜

this is where the messages actually live, and they're iconic 🤩 every one gets its own little block so you can see the exact bytes, then a short explainer. no cap, read these closely.

2.1. AUTH Command 🎀

IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH IAC SE

so the client has handed over the username and is now ready to receive that user's field parameters ✨ nothing goes to the far side yet. this should only be sent after the IAC SB AUTHENTICATION NAME command has been issued. also, if the modifier byte (second byte of the authentication-type-pair) has any bits other than AUTH_WHO_MASK or AUTH_HOW_MASK set, both bytes get included in the session key hash described later 🔥 that's how it makes sure the authentication type pair was negotiated correctly, while staying backward-compatible with existing software. literally the best of both worlds.

2.2. PARAMS Command 🦋

IAC SB AUTHENTICATION REPLY <authentication-type-pair> PARAMS <values
of modulus, generator, and salt> IAC SE

this one passes the three parameter values used in the exponentiation over to the client 🧁 people usually call these n, g, and s.

2.3. EXP Command 💅

IAC SB AUTHENTICATION IS <authentication-type-pair> EXP <client's
exponential residue> IAC SE

here the client sends its exponential residue (aka A), computed against the parameters exchanged earlier 🌸

2.4. CHALLENGE Command 🌈

IAC SB AUTHENTICATION REPLY <authentication-type-pair> CHALLENGE
<server's exponential residue> IAC SE

the server sends its exponential residue, computed against those same parameters. this quantity is actually the sum of two residues, i.e. g^x + g^b 🤯 for the deep dive, see [SRP] and [RFC2945].

2.5. RESPONSE Command 👑

IAC SB AUTHENTICATION IS <authentication-type-pair> RESPONSE
<response from client> IAC SE

this is the client's receipt 🧾 it gives the server proof of the client's authenticity with a 160-bit (20 byte) response. main character energy ✨

2.6. ACCEPT Command 🫶

IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT
<server's response> IAC SE

yay, the authentication worked 🥳 the server builds its own proof of authenticity and includes it as sub-option data.

2.7. REJECT Command 🙈

IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT
<optional reason for rejection> IAC SE

not today 💀 this one means the authentication didn't succeed. if there's any more data in the sub-option, it's an ASCII text message explaining why.

the sizes are the tea ☕ PARAMS has three pieces of data, so each parameter gets a 16-bit (two byte) length specifier in network byte order. the EXP command has no count in front of its data, since there's only one piece in that suboption. CHALLENGE, RESPONSE, and ACCEPT don't have a count either, because they're all fixed in size.

3. Implementation Rules 🍓

okay so right now, only AUTH_CLIENT_TO_SERVER mode is supported 💖 SRP effectively does implicit mutual authentication because of the two-way proofs, but only AUTH_HOW_ONE_WAY is currently defined as an authentication mode. AUTH_HOW_MUTUAL is being reserved for an explicit mutual-authentication variant of SRP that'll be defined in future specs 🔮

all large number data sent in the arguments of the PARAMS and EXP commands must be in network byte order, i.e. most significant byte first. no padding is used 🧚

the SRP-SHA1 mechanism (see [RFC2945]) generates a 40-byte session key, which lets implementations use different keys for incoming and outgoing traffic, and that makes the encrypted session way more secure 🔐 it is recommended that the Telnet ENCRYPT method, if it is used, be able to take advantage of the longer session keys. so be ready to vibe with those longer keys 🎀

Continued in Part 2 → Section 4 🦋

Copyright (C) The Internet Society (2000). All Rights Reserved.

Okay so the big vibe here is: you're allowed to share this doc with your besties 🫶 and translate it, and you can make derivative works that comment on it, explain it, or help people actually implement it 🔥. You can copy, publish, and distribute all of that, in whole or in part, with no restrictions at all, as long as the copyright notice and this paragraph are on every single copy and derivative work 📋.

BUT the doc itself is off-limits for editing 🙅. You can't change it in any way, like deleting the copyright notice or the references to the Internet Society or other Internet orgs. The only exceptions are (1) developing Internet standards, where you have to follow the copyright procedures in the Internet Standards process, or (2) translating it into languages other than English 🌍.

The permissions here are perpetual, meaning the Internet Society and its successors or assigns won't ever take them back 💜.

This document and the information in it is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 💀 So no guarantees, bestie, just vibes ✨.

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society. 🎀

📦 where this page comes from