RFC912 - Authentication service

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group Mike StJohns

Request for Comments: 912 TPSC

September 1984

Authentication Service

STATUS OF THIS MEMO

This RFCsuggests a proposed protocol for the ARPA-Internet

community, and requests discussion and suggestions for improvements.

Distribution of this memo is unlimited.

INTRODUCTION

The Authentication Server provides a means to determine the identity

of a user of a particular TCP connection. Given a TCP port number

pair, it returns a character string which identifies the owner of

that connection on the server's system. Suggested uses include

automatic identification and verification of a user during an FTP

session, additional verification of a TAC dial up user, and Access

verification for a generalized network file server.

OVERVIEW

This is a connection based application on TCP. A server listens for

TCP connections on TCP port 113 (decimal). Once a connection is

established, the server reads one line of data which specifies the

connection of interest. If it exists, the system dependent user

identifier of the connection of interest is sent out the connection.

The service closes the connection after sending the user identifier.

RESTRICTIONS

Queries are permitted only for fully specified connections. The

local/foreign host pair used to fully specify the connection are

taken from the query connection. This means a user on Host A may

only query the server on Host B about connections between A and B.

QUERY/RESPONSE FORMAT

The server accepts simple text query requests of the form

<local-port>, <foreign-port>

where <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:

RFC912 September 1984

Authentication Service

23, 6191

The response is of the form

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

where <local-port>, <foreign-port> are the same pair as the query,

<response-type> is a keyWord identifying the type of response, and

<additional info> is context dependent.

For example:

23, 6191 : USERID : StJohns

RESPONSE TYPES

A response can be one of two types:

USERID

In this case, <additional-info> is the printable representation of

the user identifier of the owner of the connection. The format of

the returned user identifier is completely system dependent.

ERROR

For some reason the owner of the TCP port could not be determined,

<additional-info> tells why. The following are suggested values

of <additional-info> and their meanings.

INVALID PORT

Either the local or foreign port was improperly specified.

NO USER

The connection specified by the port pair is not currently

in use.

UNKNOWN ERROR

Can't determine connection owner; reason unknown.

Other values may be specified as necessary.

RFC912 September 1984

Authentication Service

CAVEATS

Unfortunately, the trustworthiness of the various host systems that

might implement an authentication server will vary quite a bit. It

is up to the various applications that will use the server to

determine the amount of trust they will place in the returned

information. It may be appropriate in some cases restrict the use of

the server to within a locally controlled subnet.

APPLICATIONS

1) Automatic user authentication for FTP.

2) Verification for privileged network operations. For example,

having the server start or stop special purpose servers.

DISCLAIMER

I designed this protocol to allow me to eliminate the bother of

having to identify myself before continuing an FTP session.

Since I started work on it, other applications appeared. I have

tried to consider all of our applications while still making this as

general as possible.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航