]>
Commit | Line | Data |
---|---|---|
1 | ||
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group M. St. Johns | |
8 | Request for Comments: 1413 US Department of Defense | |
9 | Obsoletes: 931 February 1993 | |
10 | ||
11 | ||
12 | Identification Protocol | |
13 | ||
14 | Status of this Memo | |
15 | ||
16 | This RFC specifies an IAB standards track protocol for the Internet | |
17 | community, and requests discussion and suggestions for improvements. | |
18 | Please refer to the current edition of the "IAB Official Protocol | |
19 | Standards" for the standardization state and status of this protocol. | |
20 | Distribution of this memo is unlimited. | |
21 | ||
22 | 1. INTRODUCTION | |
23 | ||
24 | The Identification Protocol (a.k.a., "ident", a.k.a., "the Ident | |
25 | Protocol") provides a means to determine the identity of a user of a | |
26 | particular TCP connection. Given a TCP port number pair, it returns | |
27 | a character string which identifies the owner of that connection on | |
28 | the server's system. | |
29 | ||
30 | The Identification Protocol was formerly called the Authentication | |
31 | Server Protocol. It has been renamed to better reflect its function. | |
32 | This document is a product of the TCP Client Identity Protocol | |
33 | Working Group of the Internet Engineering Task Force (IETF). | |
34 | ||
35 | 2. OVERVIEW | |
36 | ||
37 | This is a connection based application on TCP. A server listens for | |
38 | TCP connections on TCP port 113 (decimal). Once a connection is | |
39 | established, the server reads a line of data which specifies the | |
40 | connection of interest. If it exists, the system dependent user | |
41 | identifier of the connection of interest is sent as the reply. The | |
42 | server may then either shut the connection down or it may continue to | |
43 | read/respond to multiple queries. | |
44 | ||
45 | The server should close the connection down after a configurable | |
46 | amount of time with no queries - a 60-180 second idle timeout is | |
47 | recommended. The client may close the connection down at any time; | |
48 | however to allow for network delays the client should wait at least | |
49 | 30 seconds (or longer) after a query before abandoning the query and | |
50 | closing the connection. | |
51 | ||
52 | ||
53 | ||
54 | ||
55 | ||
56 | ||
57 | ||
58 | St. Johns [Page 1] | |
59 | \f | |
60 | RFC 1413 Identification Protocol February 1993 | |
61 | ||
62 | ||
63 | 3. RESTRICTIONS | |
64 | ||
65 | Queries are permitted only for fully specified connections. The | |
66 | query contains the local/foreign port pair -- the local/foreign | |
67 | address pair used to fully specify the connection is taken from the | |
68 | local and foreign address of query connection. This means a user on | |
69 | address A may only query the server on address B about connections | |
70 | between A and B. | |
71 | ||
72 | 4. QUERY/RESPONSE FORMAT | |
73 | ||
74 | The server accepts simple text query requests of the form: | |
75 | ||
76 | <port-on-server> , <port-on-client> | |
77 | ||
78 | where <port-on-server> is the TCP port (decimal) on the target (where | |
79 | the "ident" server is running) system, and <port-on-client> is the | |
80 | TCP port (decimal) on the source (client) system. | |
81 | ||
82 | N.B - If a client on host A wants to ask a server on host B about a | |
83 | connection specified locally (on the client's machine) as 23, 6191 | |
84 | (an inbound TELNET connection), the client must actually ask about | |
85 | 6191, 23 - which is how the connection would be specified on host B. | |
86 | ||
87 | For example: | |
88 | ||
89 | 6191, 23 | |
90 | ||
91 | The response is of the form | |
92 | ||
93 | <port-on-server> , <port-on-client> : <resp-type> : <add-info> | |
94 | ||
95 | where <port-on-server>,<port-on-client> are the same pair as the | |
96 | query, <resp-type> is a keyword identifying the type of response, and | |
97 | <add-info> is context dependent. | |
98 | ||
99 | The information returned is that associated with the fully specified | |
100 | TCP connection identified by <server-address>, <client-address>, | |
101 | <port-on-server>, <port-on-client>, where <server-address> and | |
102 | <client-address> are the local and foreign IP addresses of the | |
103 | querying connection -- i.e., the TCP connection to the Identification | |
104 | Protocol Server. (<port-on-server> and <port-on-client> are taken | |
105 | from the query.) | |
106 | ||
107 | For example: | |
108 | ||
109 | 6193, 23 : USERID : UNIX : stjohns | |
110 | 6195, 23 : ERROR : NO-USER | |
111 | ||
112 | ||
113 | ||
114 | St. Johns [Page 2] | |
115 | \f | |
116 | RFC 1413 Identification Protocol February 1993 | |
117 | ||
118 | ||
119 | 5. RESPONSE TYPES | |
120 | ||
121 | A response can be one of two types: | |
122 | ||
123 | USERID | |
124 | ||
125 | In this case, <add-info> is a string consisting of an | |
126 | operating system name (with an optional character set | |
127 | identifier), followed by ":", followed by an | |
128 | identification string. | |
129 | ||
130 | The character set (if present) is separated from the | |
131 | operating system name by ",". The character set | |
132 | identifier is used to indicate the character set of the | |
133 | identification string. The character set identifier, | |
134 | if omitted, defaults to "US-ASCII" (see below). | |
135 | ||
136 | Permitted operating system names and character set | |
137 | names are specified in RFC 1340, "Assigned Numbers" or | |
138 | its successors. | |
139 | ||
140 | In addition to those operating system and character set | |
141 | names specified in "Assigned Numbers" there is one | |
142 | special case operating system identifier - "OTHER". | |
143 | ||
144 | Unless "OTHER" is specified as the operating system | |
145 | type, the server is expected to return the "normal" | |
146 | user identification of the owner of this connection. | |
147 | "Normal" in this context may be taken to mean a string | |
148 | of characters which uniquely identifies the connection | |
149 | owner such as a user identifier assigned by the system | |
150 | administrator and used by such user as a mail | |
151 | identifier, or as the "user" part of a user/password | |
152 | pair used to gain access to system resources. When an | |
153 | operating system is specified (e.g., anything but | |
154 | "OTHER"), the user identifier is expected to be in a | |
155 | more or less immediately useful form - e.g., something | |
156 | that could be used as an argument to "finger" or as a | |
157 | mail address. | |
158 | ||
159 | "OTHER" indicates the identifier is an unformatted | |
160 | character string consisting of printable characters in | |
161 | the specified character set. "OTHER" should be | |
162 | specified if the user identifier does not meet the | |
163 | constraints of the previous paragraph. Sending an | |
164 | encrypted audit token, or returning other non-userid | |
165 | information about a user (such as the real name and | |
166 | phone number of a user from a UNIX passwd file) are | |
167 | ||
168 | ||
169 | ||
170 | St. Johns [Page 3] | |
171 | \f | |
172 | RFC 1413 Identification Protocol February 1993 | |
173 | ||
174 | ||
175 | both examples of when "OTHER" should be used. | |
176 | ||
177 | Returned user identifiers are expected to be printable | |
178 | in the character set indicated. | |
179 | ||
180 | The identifier is an unformatted octet string - - all | |
181 | octets are permissible EXCEPT octal 000 (NUL), 012 (LF) | |
182 | and 015 (CR). N.B. - space characters (040) following the | |
183 | colon separator ARE part of the identifier string and | |
184 | may not be ignored. A response string is still | |
185 | terminated normally by a CR/LF. N.B. A string may be | |
186 | printable, but is not *necessarily* printable. | |
187 | ||
188 | ERROR | |
189 | ||
190 | For some reason the port owner could not be determined, <add-info> | |
191 | tells why. The following are the permitted values of <add-info> and | |
192 | their meanings: | |
193 | ||
194 | INVALID-PORT | |
195 | ||
196 | Either the local or foreign port was improperly | |
197 | specified. This should be returned if either or | |
198 | both of the port ids were out of range (TCP port | |
199 | numbers are from 1-65535), negative integers, reals or | |
200 | in any fashion not recognized as a non-negative | |
201 | integer. | |
202 | ||
203 | NO-USER | |
204 | ||
205 | The connection specified by the port pair is not | |
206 | currently in use or currently not owned by an | |
207 | identifiable entity. | |
208 | ||
209 | HIDDEN-USER | |
210 | ||
211 | The server was able to identify the user of this | |
212 | port, but the information was not returned at the | |
213 | request of the user. | |
214 | ||
215 | UNKNOWN-ERROR | |
216 | ||
217 | Can't determine connection owner; reason unknown. | |
218 | Any error not covered above should return this | |
219 | error code value. Optionally, this code MAY be | |
220 | returned in lieu of any other specific error code | |
221 | if, for example, the server desires to hide | |
222 | information implied by the return of that error | |
223 | ||
224 | ||
225 | ||
226 | St. Johns [Page 4] | |
227 | \f | |
228 | RFC 1413 Identification Protocol February 1993 | |
229 | ||
230 | ||
231 | code, or for any other reason. If a server | |
232 | implements such a feature, it MUST be configurable | |
233 | and it MUST default to returning the proper error | |
234 | message. | |
235 | ||
236 | Other values may eventually be specified and defined in future | |
237 | revisions to this document. If an implementer has a need to specify | |
238 | a non-standard error code, that code must begin with "X". | |
239 | ||
240 | In addition, the server is allowed to drop the query connection | |
241 | without responding. Any premature close (i.e., one where the client | |
242 | does not receive the EOL, whether graceful or an abort should be | |
243 | considered to have the same meaning as "ERROR : UNKNOWN-ERROR". | |
244 | ||
245 | FORMAL SYNTAX | |
246 | ||
247 | <request> ::= <port-pair> <EOL> | |
248 | ||
249 | <port-pair> ::= <integer> "," <integer> | |
250 | ||
251 | <reply> ::= <reply-text> <EOL> | |
252 | ||
253 | <EOL> ::= "015 012" ; CR-LF End of Line Indicator | |
254 | ||
255 | <reply-text> ::= <error-reply> | <ident-reply> | |
256 | ||
257 | <error-reply> ::= <port-pair> ":" "ERROR" ":" <error-type> | |
258 | ||
259 | <ident-reply> ::= <port-pair> ":" "USERID" ":" <opsys-field> | |
260 | ":" <user-id> | |
261 | ||
262 | <error-type> ::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR" | |
263 | | "HIDDEN-USER" | <error-token> | |
264 | ||
265 | <opsys-field> ::= <opsys> [ "," <charset>] | |
266 | ||
267 | <opsys> ::= "OTHER" | "UNIX" | <token> ...etc. | |
268 | ; (See "Assigned Numbers") | |
269 | ||
270 | <charset> ::= "US-ASCII" | ...etc. | |
271 | ; (See "Assigned Numbers") | |
272 | ||
273 | <user-id> ::= <octet-string> | |
274 | ||
275 | <token> ::= 1*64<token-characters> ; 1-64 characters | |
276 | ||
277 | <error-token> ::= "X"1*63<token-characters> | |
278 | ; 2-64 chars beginning w/X | |
279 | ||
280 | ||
281 | ||
282 | St. Johns [Page 5] | |
283 | \f | |
284 | RFC 1413 Identification Protocol February 1993 | |
285 | ||
286 | ||
287 | <integer> ::= 1*5<digit> ; 1-5 digits. | |
288 | ||
289 | <digit> ::= "0" | "1" ... "8" | "9" ; 0-9 | |
290 | ||
291 | <token-characters> ::= | |
292 | <Any of these ASCII characters: a-z, A-Z, | |
293 | - (dash), .!@#$%^&*()_=+.,<>/?"'~`{}[]; > | |
294 | ; upper and lowercase a-z plus | |
295 | ; printables minus the colon ":" | |
296 | ; character. | |
297 | ||
298 | <octet-string> ::= 1*512<octet-characters> | |
299 | ||
300 | <octet-characters> ::= | |
301 | <any octet from 00 to 377 (octal) except for | |
302 | ASCII NUL (000), CR (015) and LF (012)> | |
303 | ||
304 | Notes on Syntax: | |
305 | ||
306 | 1) To promote interoperability among variant | |
307 | implementations, with respect to white space the above | |
308 | syntax is understood to embody the "be conservative in | |
309 | what you send and be liberal in what you accept" | |
310 | philosophy. Clients and servers should not generate | |
311 | unnecessary white space (space and tab characters) but | |
312 | should accept white space anywhere except within a | |
313 | token. In parsing responses, white space may occur | |
314 | anywhere, except within a token. Specifically, any | |
315 | amount of white space is permitted at the beginning or | |
316 | end of a line both for queries and responses. This | |
317 | does not apply for responses that contain a user ID | |
318 | because everything after the colon after the operating | |
319 | system type until the terminating CR/LF is taken as | |
320 | part of the user ID. The terminating CR/LF is NOT | |
321 | considered part of the user ID. | |
322 | ||
323 | 2) The above notwithstanding, servers should restrict the | |
324 | amount of inter-token white space they send to the | |
325 | smallest amount reasonable or useful. Clients should | |
326 | feel free to abort a connection if they receive 1000 | |
327 | characters without receiving an <EOL>. | |
328 | ||
329 | 3) The 512 character limit on user IDs and the 64 | |
330 | character limit on tokens should be understood to mean | |
331 | as follows: a) No new token (i.e., OPSYS or ERROR-TYPE) | |
332 | token will be defined that has a length greater than 64 | |
333 | and b) a server SHOULD NOT send more than 512 octets of | |
334 | user ID and a client MUST accept at least 512 octets of | |
335 | ||
336 | ||
337 | ||
338 | St. Johns [Page 6] | |
339 | \f | |
340 | RFC 1413 Identification Protocol February 1993 | |
341 | ||
342 | ||
343 | user ID. Because of this limitation, a server MUST | |
344 | return the most significant portion of the user ID in | |
345 | the first 512 octets. | |
346 | ||
347 | 4) The character sets and character set identifiers should | |
348 | map directly to those defined in or referenced by RFC 1340, | |
349 | "Assigned Numbers" or its successors. Character set | |
350 | identifiers only apply to the user identification field | |
351 | - all other fields will be defined in and must be sent | |
352 | as US-ASCII. | |
353 | ||
354 | 5) Although <user-id> is defined as an <octet-string> | |
355 | above, it must follow the format and character set | |
356 | constraints implied by the <opsys-field>; see the | |
357 | discussion above. | |
358 | ||
359 | 6) The character set provides context for the client to | |
360 | print or store the returned user identification string. | |
361 | If the client does not recognize or implement the | |
362 | returned character set, it should handle the returned | |
363 | identification string as OCTET, but should in addition | |
364 | store or report the character set. An OCTET string | |
365 | should be printed, stored or handled in hex notation | |
366 | (0-9a-f) in addition to any other representation the | |
367 | client implements - this provides a standard | |
368 | representation among differing implementations. | |
369 | ||
370 | 6. Security Considerations | |
371 | ||
372 | The information returned by this protocol is at most as trustworthy | |
373 | as the host providing it OR the organization operating the host. For | |
374 | example, a PC in an open lab has few if any controls on it to prevent | |
375 | a user from having this protocol return any identifier the user | |
376 | wants. Likewise, if the host has been compromised the information | |
377 | returned may be completely erroneous and misleading. | |
378 | ||
379 | The Identification Protocol is not intended as an authorization or | |
380 | access control protocol. At best, it provides some additional | |
381 | auditing information with respect to TCP connections. At worst, it | |
382 | can provide misleading, incorrect, or maliciously incorrect | |
383 | information. | |
384 | ||
385 | The use of the information returned by this protocol for other than | |
386 | auditing is strongly discouraged. Specifically, using Identification | |
387 | Protocol information to make access control decisions - either as the | |
388 | primary method (i.e., no other checks) or as an adjunct to other | |
389 | methods may result in a weakening of normal host security. | |
390 | ||
391 | ||
392 | ||
393 | ||
394 | St. Johns [Page 7] | |
395 | \f | |
396 | RFC 1413 Identification Protocol February 1993 | |
397 | ||
398 | ||
399 | An Identification server may reveal information about users, | |
400 | entities, objects or processes which might normally be considered | |
401 | private. An Identification server provides service which is a rough | |
402 | analog of the CallerID services provided by some phone companies and | |
403 | many of the same privacy considerations and arguments that apply to | |
404 | the CallerID service apply to Identification. If you wouldn't run a | |
405 | "finger" server due to privacy considerations you may not want to run | |
406 | this protocol. | |
407 | ||
408 | 7. ACKNOWLEDGEMENTS | |
409 | ||
410 | Acknowledgement is given to Dan Bernstein who is primarily | |
411 | responsible for renewing interest in this protocol and for pointing | |
412 | out some annoying errors in RFC 931. | |
413 | ||
414 | References | |
415 | ||
416 | [1] St. Johns, M., "Authentication Server", RFC 931, TPSC, January | |
417 | 1985. | |
418 | ||
419 | [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, | |
420 | USC/Information Sciences Institute, July 1992. | |
421 | ||
422 | Author's Address | |
423 | ||
424 | Michael C. St. Johns | |
425 | DARPA/CSTO | |
426 | 3701 N. Fairfax Dr | |
427 | Arlington, VA 22203 | |
428 | ||
429 | Phone: (703) 696-2271 | |
430 | EMail: stjohns@DARPA.MIL | |
431 | ||
432 | ||
433 | ||
434 | ||
435 | ||
436 | ||
437 | ||
438 | ||
439 | ||
440 | ||
441 | ||
442 | ||
443 | ||
444 | ||
445 | ||
446 | ||
447 | ||
448 | ||
449 | ||
450 | St. Johns [Page 8] | |
451 | \f |