ietf-nntp WG Review of draft-dfncis-netnews-admin-sys-05.txt

Robert Schuettler rober at cis.fu-berlin.de
Thu Apr 17 07:54:50 PDT 2003


[ Proposed updates for NAS text at the very end. ]

On Mon, Apr 07, 2003 at 10:29:06AM -0700, ned.freed at mrochek.com wrote:

> Thanks for reminding me; I did an AD review a week or so ago but neglected
> to send the comments out to the list. Here they are:

Thanks for taking the time to look things over.

> The document does not have the necessary full copyright and intellectual
> property rights statements. This text needs to be added before the document can
> be accepted for publication.

I had hoped that the RFC Editor would help with that as part of the
process of re-formatting the Draft as an RFC.

> The draft should make it clear from the outset that it currently provides
> readonly access to a database of information about netnews and that no
> operations to write to the database are provided.

I am not sure I understand that point fully: Read-only access to NAS
information is indeed provided for clients in the "public branch",
but  servers _will_ update their information from other NAS-servers
in the "authoritative branch". Servers will collect data via the
GETP and GETA commands and then _write_ the new information to their
database.

> I'm a bit concerned about the use of protocol versions rather than a
> capabilities discovery scheme for future protocol extensions. Version numbers
> are quite inflexible -- each time additions are made to the protocol a
> compliant server has to implement all those additions plus all previous
> additions made at lower numbers before it can claim to implement that version.
> Additionally, version numbers don't provide any means of returning
> per-capability parameters or limits. Given that this protocol is currently
> deployed I don't insist on changing schemes, but it may make sense for version
> 2, should it come to pass, to introduce a capabilities command of some sort and
> be the last version number you assign.

Both approaches (protocol level / query for features) have their
advantages. One advantage of the protocol level approach is the
definition of a precise communication level through one short command
(and answer) which can especially be nice when NAS goes UDP. But we
agree that the request for features should be implemented in protocol
level 2.

> The security considerations section needs work.  First of all, at least some
> reference should be made to the use of PGP keys throughout the document. It
> isn't necessary to explain the use of PGP keys in any detail, but it at least
> needs to be mentioned.

We agree that the security issues need work. The use of PGP in the
current protocol level is just a starting point. Secure communication
between server and client, authentification, etc. are issues that need
to be dealt with in the future. In this version we tried to create a
useable protocol that allows real-life use of NAS quickly and provides
room for future enhancements - rather than to solve everything at once.

> The claim that "security issues are only vital for the server-server
> communication" is a serious stretch. Again, this protocol provides access to
> PGP keys. I'm no expert, but it seems to me that all sorts of mischief would be
> possible if a bogus server were to hand out the wrong keys to clients.
> Alternately, it could omit or hand out incorrect information about the netnews
> hierarchy.  I don't see a facility in this protocol for a client to validate
> that it is talking to a legitimate server. Nor does there appear to be a way to
> secure the connection to the NAS server. Again, this issue should be discussed
> in the security considerations section.
> 
> The fact that validation of client IP addresses is currently the only form of
> client authentication is probably OK for an experimental protocol, but it needs
> to be mentioned in section 6.2 as well as in the security considerations
> section.

Here's a proposal for an update of the sections in question:

---8<--[old]------------------------------------------------------------

9.  Security Considerations

   Security issues are only vital for the server-server	communication,
   since we want a strict hierarchical model of	the netnews
   administration system. So we	want to	be sure	that only authorized
   clients connect to an authoritative server.

   Every server	has the	possibility to deny some commands or the whole
   connection based on the client's IP number or on username/password
   combination.

Note: A	stronger authentication	scheme will be provided	in a higher
protocol level.

---8<--[new]------------------------------------------------------------

9.  Security Considerations

   Security issues are only addressed in respect to server-server
   communication in this protocol level. Username and password
   combinations in the GETA and GETP commands can be used to make sure
   that connections are only accepted from authorized clients. PGP keys
   according to [RFC2240] are used to sign NAS data in server-server
   communication in order to validate that data is authentic and has
   not been tampered with.
   
   Every server does have the possibility (in both server-server and
   server-client communication) to deny some commands or the whole
   connection based on the client's IP number.

   No mechanisms are defined in the current protocol level to allow a
   client to validate that it is talking to a legitimate server and/or
   that the data it receives is authentic.

   A stronger authentication scheme will be provided in a higher
   protocol level.

---8<--[old]------------------------------------------------------------

6.2.  Connection Setup

   NAS typically uses port 991,	which is reserved by IANA [IANA-PN]. If
   a connection	is set up by the client, the server answers immediately
   (without a request) with the	greeting message, which	will start with
   code	200:

   --> 200 Welcome!
       nas.example.org ready
       .

   If a	connection is refused because the client has no	permission
   to access the server, the answer code is 434. When the server
   is currently	out of service,	the answer code	is 404.

    Examples:

---8<--[new]------------------------------------------------------------

6.2.  Connection Setup

   NAS typically uses port 991,	which is reserved by IANA [IANA-PN]. If
   a connection	is set up by the client, the server answers immediately
   (without a request) with the	greeting message, which	will start with
   code	200:

   --> 200 Welcome!
       nas.example.org ready
       .

   If a	connection is refused because the client has no	permission to
   access the server, the answer code is 434. That decision can be made
   on connection startup based on the client's IP address. When the
   server is currently out of service, the answer code is 404.

    Examples:

---8<-------------------------------------------------------------------

Best regards, Robert Schuettler

-- 
Robert Schuettler                         | rober at cis.fu-berlin.de
Freie Universitaet Berlin                 | 
Zentraleinrichtung fuer Datenverarbeitung | http://www.zedat.fu-berlin.de



More information about the ietf-nntp mailing list