Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!tytso From: tytso@athena.mit.edu (Theodore Y. Ts'o) Newsgroups: news.software.nntp Subject: Re: NNTP 1.5 Patch 4 Keywords: NNTP 1.5 patch 4 Message-ID: <11466@bloom-beacon.MIT.EDU> Date: 16 May 89 18:45:51 GMT References: <157@lib.tmc.edu> <1720@ucsd.EDU> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: tytso@athena.mit.edu (Theodore Y. Ts'o) Organization: Massachusetts Institute of Technology Lines: 83 In article <1720@ucsd.EDU> brian@ucsd.edu (Brian Kantor) writes: >In fact, I'm going to suggest that servers supply a NEW code > 203 ready but I can't accept incoming news at this time >to indicate that both posting and incoming transfers should be deferred, >as this is useful both to clients and transfer agents. This is a wonderful idea! How about another code which prohibits (or at least strong discourages) news transfer agents from sending the server more articles. This could be used by the server while expire is running, so that it doesn't receive the same article from three or more sites. This would reduce the amount of disk space that would be chewed up by the duplicate articles, as well the extra computrons "rnews -U" would need to reject those articles. >Hmm. Looks like it's time to publish that update to RFC977. Any other >changes to the specification you wanna make? How about an extension to support authentication? I propose a new command which takes two parameters: AUTH When a client gives this command, it is trying to authenticate itself as , using the specified authentication system. It is up to the servers to use this authentication information as they see fit. Note that it is imperative that the servers remember what authentication system was used to authenticate that principal, since this should have some bearing about how the servers treat the authentication. The server can respond with the following codes (let response codes x5x be reserved for authentication related responses) 450) I don't support that authentication system; try another 350) I support that authentication system; send authenticator (which will be authentication system dependant) 351) I support that authentication system; here is some challenge information; send authenticator. 250) I accept the authentication. 451) I reject the authentication. Both the authenticator and the challenge are authentication system dependant. They should be transmitted in Netascii (7 bits only) and terminated by a single period on a line. If the authentication system requires that 8 bit data be transfered (such as Kerberos), then some form of encoding (ala uuencode) should be chosen. Depending on the authentication system, several cycles of authenticator/challenge information may be exchanged, with the server sending response code 350 or 351 demanding addition authenticator information from the client. When the server is satisified with the authenticaion process, it may send 250 or 451, accepting or rejecting the authenticaion. Every server should support the authentication system "weak", which always accepts the claimed principal without preforming any verification. The authentication system "none" ignores the claimed principal and clears any previously authenticated principal. Another standard authentication system would be "password", which request as an authenticator a password, which it would look up in a password database and accept if the passwords matched. The passwords may optionally be stored in an encrypted form, in which case the password given to the server would be encrytped and then compared against the password database. Other possible authenticaion systems would support the Kerberos protocol, or even some more esoteric zero-knowledge proof systems, which require an interactive authenticaion protocol --- this is why several cycles of authenticator/challenge information are supported. It is up to the individual server implementations to determine what sort of authorization decisions should be made. After a successful authentication, the server should store the pair (principal, auth_system) and make its authorization decision on _both_ both the principal and the authentication system that was used. What do people think? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Theodore Ts'o bloom-beacon!mit-athena!tytso 3 Ames St., Cambridge, MA 02139 tytso@athena.mit.edu Everybody's playing the game, but nobody's rules are the same!