amanda@intercon.com (Amanda Walker) (11/11/89)
In article <1802@gazette.bcm.tmc.edu>, sob@watson.bcm.tmc.edu (Stan Barber) writes: > One other thing that has been suggested are a TIME command to get the > server's current view of time. This would be a good thing, since the NEWGROUPS and NEWNEWS commands take their arguments in server-based time. Some of us (who, me?) try to deduce what time the server thinks it is by attempting to parse the initial banner line, but this is definitely a hack... -- Amanda Walker <amanda@intercon.com>
amanda@intercon.com (Amanda Walker) (11/12/89)
In article <BOB.89Nov10164646@archer.MorningStar.Com>, bob@MorningStar.Com (Bob Sutterfield) writes: > In article <1802@gazette.bcm.tmc.edu>, sob@watson.bcm.tmc.edu (Stan Barber) writes: > One other thing that has been suggested are a TIME command to get > the server's current view of time. > > What about transmission delay, and all the other things that you have > to worry about if you're even going to bother starting to think about > time synchronization? You might as well invent a time protocol... > [ lots of good stuff about NTP ] This, of course, does address the problem quite handily. One of the reasons I used the approach I did in some prototype software (which turned out to be unnecessary for completely unrelated reasons) is that the NEWNEWS and NEWGROUPS commands take magic cookies (times) as arguments but give you no way to obtain them except by hoping your clocks are in sync. The only reason that figuring out the server's idea of the time works at all is that NNTP currently gives you a static view of the news base (i.e. what's there when a session starts up). My eventual approach was to ignore NEWNEWS and NEWGROUPS. It was faster to just parse the active file, which gave me the information I needed without having to do anything funky. However, passive NNTP feeds use NEWNEWS and NEWGROUPS, so the problem isn't completely amenable to workarounds within the NNTP protocol itself. NTP is probably the way to go. I wonder if a lonely standalone network (like ours :-)) could run NTP and sync up by modem with an NBS (or is it NIST these days?) modem-equipped cesium clock every so often? That could be nifty... (especially when said clock is only a local call :-)). -- Amanda Walker <amanda@intercon.com>
brian@ucsd.Edu (Brian Kantor) (11/13/89)
I think the proposed DATE command (which would return the NNTP server's idea of date and time as MMDDYY HHMMSS or something) is probably a good enough idea that it's worth adding as an optional command. Why? Well, it handles the timezone problem, which isn't solvable any other easy way (I mean really, there are adjoining towns which either do or don't observe summer time), and it's a cheap and easy hack. People who want to use it and don't want to go to the trouble of using NTP to get a precise time may do so. And there are commands in NNTP that require MMDDYY HHMMSS arguments. It suits my sense of symmetry and completeness that we should be able to provide some sort of reference point without having to go outside the protocol. But the winning argument came from some people who are using NNTP over non-TCP (in fact, non-internet-protocol) links. There is no time protocol that they can use. So I think I'll add it to the spec as an optional thing. - Brian
brian@ucsd.Edu (Brian Kantor) (11/13/89)
Mark, you are reading too much into the spec. A more precise statement of the semantics of the USER command is USER <site-dependent-string> i.e., the spec doesn't call for ANY specific syntax or content of the string following the USER command. That means that login procedures for the NNTP server at any particular host are as configurable as is the interactive (user terminal) login itself. If that requires a specific n-tuple of parameters, so be it. N can always be 1 if that's the way your host wants to do it. Specification or requirement of encryption and of user identification and/or verification does not belong in the NNTP spec. All we have to do is provide a facility for in-band exchange of tokens for the people who want to do that. If it is desired to have a specification of the methods of user verification used over the internet, that should be the subject of a separate RFC. As it would undoubtedly apply to telnet, rlogin, ftp, smtp, and nntp, it is a matter which needs careful consideration and shouldn't be hacked into one particular transport protocol specification. I hope you can see why I'm trying so hard to keep these separate! - Brian
lear@GENBANK.BIO.NET (Eliot Lear) (11/13/89)
I've got several comments on the proposed extensions. First, there exists an authentication group within the IETF which deals with authentication issues, headed up by Jeff Schiller, I believe. We should probably be talking to him as to what type of hooks should be left in. Also, my understanding is that there either has been or will be shortly a decree that says that no protocol may move beyond ``proposed standard'' unless the security issues have been addressed. So the hooks should be there. It would also be nice if a simple demonstration of those hooks were included in an implementation, but that brings up oodles of arguments about expectations, etc... When you write the spec, it should be OK (and possibly recommended) for a server to always return a 200 level code, regardless of whether the user passed the challenge. That way, you don't have someone hacking passwords, or other fun stuff. This would probably also have at least the feel of the KISS (keep it simple, stupid). Also, there should be no reason why HOSTS couldn't authenticate themselves in this system. Speaking of response codes, as long as you're doing a new version, care to bring the response codes in line with SMTP, FTP, etc? I realize this could be messy for code trying to deal with both implementations, but if you were to fix this stuff, you'd probably want to run on another port. For example, how about 5xx you blew it, as opposed to a temporary error (if you should even want to do such a thing). 'best, -- Eliot Lear [lear@net.bio.net]
gnb@bby.oz (Gregory N. Bond) (11/13/89)
In article <1546@intercon.com> amanda@intercon.com (Amanda Walker) writes:
NTP is probably the way to go. I wonder if a lonely standalone network
(like ours :-)) could run NTP and sync up by modem with an NBS (or is it
NIST these days?) modem-equipped cesium clock every so often? That could
be nifty... (especially when said clock is only a local call :-)).
(This is off the topic of nntp, but...)
We run ntp here on an isolated network. It runs quite happily. I did
some tests to find the machine with the most stable clock. (By sheer
chance it was the workstation on my desk). This is set up to use the
local clock as a stratum-3 server. All the file severs peer with my
workstation and one other server. One server with an almost-as-stable
clock has a stratum-4 local clock server. All workstations are peered
to their server.
Thus all machines are synced to my workstation, and if that's down
they resync to the other server, otherwise they run free. Works like
a charm. I'd be happy to share experiences and ntp.conf files if
anyone is interested.
Greg.
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnbmark@cblpf.ATT.COM (Mark Horton) (11/14/89)
In article <10125@ucsd.Edu> brian@ucsd.edu (Brian Kantor) writes: >Mark, you are reading too much into the spec. A more precise statement >of the semantics of the USER command is > > USER <site-dependent-string> > >i.e., the spec doesn't call for ANY specific syntax or content of the >string following the USER command. That means that login procedures >for the NNTP server at any particular host are as configurable as is the >interactive (user terminal) login itself. If that requires a specific >n-tuple of parameters, so be it. N can always be 1 if that's the way >your host wants to do it. The whole point of a standard is to standardize things. If the standard says "do whatever you want" you haven't accomplished anything. I should be able to take two implementations of NNTP (say mine and the one my feed is running) and expect them to talk to each other, possibly with some configuration that doesn't require me to have source. I should also be able to implement my local user policy without breaking interoperability with my neighbor. If we restrict the USER line to only apply to END-USER-to-SERVER authentication, then we're OK. But your examples seem to imply using this for PEER-SERVER-to-PEER-SERVER login, and I think that should be kept separate, and if it happens, it's critical that this one be standardized (and, of course, configurable so it can be turned off.) >Specification or requirement of encryption and of user identification >and/or verification does not belong in the NNTP spec. All we have to >do is provide a facility for in-band exchange of tokens for the people >who want to do that. This sounds reasonable, with one caveat. There should be a requirement that any text in the "Please send a password" response be displayed to the user. There will be some implementations where the password depends on the string sent, especially when hand-held authenticators are used. There might be a different code for this case if you like. Mark