RFC 931

Authentication Server 🎀

Okay bestie, this one is RFC 931 💖. It's from the Network Working Group, written by Mike StJohns of TPSC, and it's dated January 1985. It supersedes RFC 912 ✨, and it doesn't list anything it updates. Let's go!

---

Status of This Memo 💅

This RFC suggests a proposed protocol for the ARPA-Internet community and asks for discussion and suggestions for improvements. It's the second draft of the proposal (superseding RFC 912) 🌸. It adds a more formal description of the syntax for the request and response dialog, plus a change so the type of user identification returned gets specified. Distribution of this memo is unlimited 🦋.

Introduction 🧚

The Authentication Server Protocol lets you figure out who the user is on a particular TCP connection 👑. You give it a TCP port number pair, and it sends back a character string that names the owner of that connection on the server's system. Suggested uses include automatic identification and verification of a user during an FTP session, extra verification for a TAC dial-up user, and access verification for a generalized network file server 💜.

Overview 🌈

This is a connection-based application on TCP, and it's giving very focused ✨. A server listens for TCP connections on TCP port 113 (decimal). Once a connection is established, the server reads one line of data that says which connection you're asking about. If that connection exists, the system-dependent user identifier of the connection gets sent back out. Then the service closes the connection after sending the user identifier 🔥.

Restrictions 🙈

Queries are only allowed for fully specified connections. The local and foreign host pair that fully specifies the connection is taken from the query connection. So a user on Host A can only query the server on Host B about connections between A and B. Not a free-for-all, bestie 💅.

Query/Response Format 💖

The server accepts simple text query requests that look like this:

<local-port>, <foreign-port>

Here, <local-port> is the TCP port (decimal) on the target (server) system, and <foreign-port> is the TCP port (decimal) on the source (user) system.

For example:

23, 6191

The response looks like this:

<local-port>, <foreign-port> : <response-type> : <additional-info>

The <local-port>,<foreign-port> pair is the same as the query. <response-type> is a keyword that says what kind of response it is, and <additional info> depends on the context 🦋.

For example:

23, 6191 : USERID : MULTICS : StJohns.DODCSC.a
23, 6193 : USERID : TAC : MCSJ-MITMUL
23, 6195 : ERROR : NO-USER

Response Types 🎀

A response can be one of two types.

USERID 🌸

In this case, <additional-info> is a string made of an operating system name, then a ":", then a user identification string in a format that's specific to the operating system named. Permitted operating system names are specified in RFC-923, "Assigned Numbers" or its successors. The only other names allowed are "TAC" (for a BBN Terminal Access Controller) and "OTHER" (for any other operating system not yet registered with the NIC) ✨.

ERROR 😭

For some reason, the owner of <TCP-port> couldn't be determined, and <additional-info> tells you why. Here are the suggested values of <additional-info> and what they mean 🙈.

INVALID-PORT

The local or foreign port was improperly specified.

NO-USER

The connection specified by the port pair isn't currently in use.

UNKNOWN-ERROR

The connection owner can't be determined, and the reason is unknown. Other values may be specified as necessary.

Caveats 💀

Unfortunately, how trustworthy the various host systems are that might run an authentication server will vary quite a bit 😬. It's up to the applications that use the server to decide how much trust to put in the returned information. In some cases, it may be appropriate to restrict use of the server to within a locally controlled subnet 🔒.

Applications 👑

1. Automatic user authentication for FTP

A user-FTP may send a USER command with no argument to the server-FTP to ask for automatic authentication. The server-FTP will reply with a 230 (user logged in) if it can use the authentication. It will reply with a 530 (not logged in) if it can't authenticate the user. It will reply with a 500 or 501 (syntax or parameter problem) if it doesn't implement automatic authentication. Please note that no change is needed to currently implemented servers to handle the request for authentication. They will reject it normally as a parameter problem. This is a suggested implementation for experimental use only 🧪.

2. Verification for privileged network operations. For example, having the server start or stop special purpose servers 🔥.
3. Elimination of "double login" for TAC and other TELNET users.

This will be implemented as a TELNET option 🫶.

Formal Syntax 🍓

The grammar is below, and it's giving very precise energy 💅:

<request>     ::= <port-pair> <CR> <LF>

<port-pair>   ::= <integer-number> "," <integer-number>

<reply>       ::= <reply-text> <CR> <LF>

<reply-text>  ::= <error-reply> | <auth-reply>

<error-reply> ::= <port-pair> ":" ERROR ":" <error-type>

<auth-reply>  ::= <port-pair> ":" USERID ":" <opsys> ":" <user-id>

<error-type>  ::= INVALID-PORT | NO-USER | UNKNOWN-ERROR

<opsys>       ::= TAC | OTHER | MULTICS | UNIX ...etc.
                  (See "Assigned Numbers")

Notes on syntax, because these matter 👀:

1. White space (blanks and tab characters) between tokens isn't important and may be ignored.
2. White space, the token separator character (":"), and the port pair separator character (",") must be quoted if they're used within a token. The quote character is a back-slash, ASCII 92 (decimal) ("\"). For example, a quoted colon is "\:". The back-slash must also be quoted if it's needed to represent itself ("\\") 💖.

Notes on User Identification Format 🌈

The user identifier the server returns should be the standard one for the system. For example, the standard Multics identifier is a PERSONID, then a ".", then a PROJECTID, then a ".", then an INSTANCE TAG of one character. An instance tag of "a" identifies an interactive user, an instance tag of "m" identifies an absentee job (batch job) user, and an instance tag of "z" identifies a daemon (background) user ✨.

Each set of operating system users has to reach a consensus on what the OFFICIAL user identification for their systems will be. Until they register that information, they must use the "OTHER" tag to specify their user identification 🎀.

Notes on User Identification Translation 🦋

Once you have a user identifier from a remote system, you need a way to translate it into an identifier that's meaningful on the local system. The following is a sketchy outline of a table-driven scheme for doing this 🧚.

The table has four columns. The first three are used to match against, and the fourth is the result:

USERID              Opsys     Address     Result
MCSJ-MITMUL         TAC       26.*.*.*    StJohns
*                   MULTICS   192.5.42.*  =
*                   OTHER     10.0.0.42   anonymous
MSJ                 ITS       10.3.0.44   StJohns

The table above is a sample for a Multics system on MILNET at the Pentagon. When an authentication comes back, the application using the userid just looks for the first match in the table. Check out the second line: it says any authentication coming from a Multics system on Net 192.5.42 is accepted in the same format 💜.

Obviously, various users will have to be registered to use this facility. But registration can happen at the same time the user receives their login identity from the system 🫶✨.