Netnews Administration System (NAS)
draft-dfncis-netnews-admin-sys-07

[Note]: 'Re-review in light of new procedures for individual submissions via the RFC Editor.  This one has been in the IESG''s hands for two years!' added by Amy Vezza

[Ballot comment]
The IESG notes the following editorial issues with the draft that should
be addressed prior to publication:

There is no copyright or IPR boilerplate as requested in earlier AD review.

References need to be split into normative and informative groups.

The ABNF rules response-code, Bits, User-ID, Keyblock, Finger, Version,
Key-ID, and Location are referenced but never defined.  These may actually
be technical as well as editorial.

There are also a number of technical issues with this specification:

  The IESG notes that protocol levels, or versions, are used to extend this
  protocol. 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 the new version. Additionally, version numbers
  don't provide any means of returning per-capability parameters or limits.

  This protocol uses client IP address information for authentication
  purposes. This echoes similar usage in NNTP. While this technique
  has been successful for NNTP in many situations over the years, it
  is not clear it is sufficient going forward. In particular, although
  IP address spoofing attacks are rare, widespread use of dynamic
  address assignment and NAT have reduced both the ability for servers
  to be properly configured with proper client address information as
  well as the ability of an IP address to uniquely identify a single
  client.

  This protocol uses PGP to sign data transferred from one NAS server
  to another. However, it isn't clear that all of the details of
  how to assign and validate PGP keys are sufficiently specified to
  ensure inoperability.

  Finally, various internationalization issues, e.g.
  internationalized newsgroup names, have yet to be addressed in Netnews.
  Although it is clearly inappropriate to deal with Netnews
  internationalization in this specification, the IESG notes that
  changes may be necessary in this protocol once these issues
  are addressed elsewhere.

[Ballot comment]
The IESG notes the following editorial issues with the draft that should
be addressed prior to publication:

  There still no copyright or IPR boilerplate as requested in earlier AD
  review.

  References need to be split into normative and informative groups.

  The ABNF rules response-code, Bits, User-ID, Keyblock, Finger, Version,
  Key-ID, and Location are referenced but never defined.  The ABNF rule
  issues may actually be technical as well as editorial.

There are also a number of technical issues with this specification:

  The IESG notes that protocol levels, or versions, are used to extend this
  protocol. Version numbers are quite inflexible -- each time additions are
  made to the protocol compliant server has to implement all those additions
  plus all previous additions made at lower numbers before it can claim to
  implement the new version. Additionally, version numbers don't provide any
  means of returning per-capability parameters or limits.

  This protocol uses client IP address information for authentication
  purposes. This echoes similar usage in NNTP. While this technique
  has been successful for NNTP in many situations over the years, it
  is not clear it is sufficient going forward. In particular, although
  IP address spoofing attacks are rare, widespread use of dynamic
  address assignment and NAT have reduced both the ability for servers
  to be properly configured with proper client address information as
  well as the ability of an IP to uniquely identify a single client.

  This protocol uses PGP to sign data transferred from one NAS server
  to another. However, it isn't clear that all of the details of
  how to assign and validate PGP keys are sufficiently specified to
  insure inoperability.

  Finaally, various internationalization issues, e.g.
  internationalized newsgroup names, have yet to be addressed in Netnews.
  Although it is clearly inappropriate to deal with Netnews
  internationalization in this specification, the IESG notes that
  changes may be necessary in this protocol once these issues
  are addressed elsewhere.

[Note]: 'Re-review in light of new procedures for individual submissions via the RFC Editor.  This one has been in the IESG''s hands for two years!' added by Scott Hollenbeck

Additional IESG review notes for the RFC Editor:

Editorial issues:
There is no copyright or IPR boilerplate as requested in earlier AD review.

References need to be split into normative and informative groups.

The ABNF rules response-code, Bits, User-ID, Keyblock, Finger, Version,
Key-ID, and Location are referenced but never defined.  These may actually
be technical as well as editorial.

There are also a number of technical issues with this specification. The
IESG requests that the following IESG note be attached to the specification
if it is published:

  The IESG notes that protocol levels, or versions, are used to extend this
  protocol. 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 the new version. Additionally, version numbers
  don't provide any means of returning per-capability parameters or limits.

  This protocol uses client IP address information for authentication
  purposes. This echoes similar usage in NNTP. While this technique
  has been successful for NNTP in many situations over the years, it
  is not clear it is sufficient going forward. In particular, although
  IP address spoofing attacks are rare, widespread use of dynamic
  address assignment and NAT have reduced both the ability for servers
  to be properly configured with proper client address information as
  well as the ability of an IP address to uniquely identify a single
  client.

  This protocol uses PGP to sign data transferred from one NAS server
  to another. However, it isn't clear that all of the details of
  how to assign and validate PGP keys are sufficiently specified to
  ensure inoperability.

  Finally, various internationalization issues, e.g.
  internationalized newsgroup names, have yet to be addressed in Netnews.
  Although it is clearly inappropriate to deal with Netnews
  internationalization in this specification, the IESG notes that
  changes may be necessary in this protocol once these issues
  are addressed elsewhere.

[Ballot comment]
This document has numerous security issues, such address-based authentication, plaintext passwords with no cryptography, and inadequate specification of how to actually use PGP per this document.  That said, it is an individual Experimental submission, so I won't block it.

[Ballot comment]
Uses IP addresses in example that are not inline with RFC3330, here is one
of those incorrect examples (there are multiple):

  Example:

  <-- INFO
  --> 101 Information follows
      Server: nas.example.org (192.168.192.100)
      Uptime: 2 weeks, 3 days, 5 hours, 9 minutes
      Software: NAS 1.0
      Client: client.example.org (192.168.0.200)
      Connection: 9 minutes
      Highest protocol level supported: 1
      Requested protocol level: 1
      Protocol level used: 1
      .

And there are exmples that do not follow rfc2606 for domain names in examples,
here is one of them:

  Examples

  <-- HIER de
  --> 611 Data coming
      Name: de
      Status: Complete
      Serial: 20020823120306
      Description: Internationale deutschsprachige Newsgruppen
      Netiquette: http://www.dana.de/de/netiquette.html
      FAQ: http://www.dana.de/de/neue-de-gruppe.html
      Ctl-Send-Adr: moderator@dana.de
      Ctl-Newsgroup: de.admin.news.announce
      Mod-Wildcard: %s@moderators.dana.de
      Language: DE
      Charset: ISO-8859-1
      Encoding: text/plain
      Newsgroup-Type: Discussion
      Hier-Type: Global
      Comp-Length: 14
      Date-Create: 19920106000000

I wonder if a reference likethis:

  [IANA-CS] IANA: Character Sets,
            ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets

would not be betetr given as:

  [IANA-CS] IANA: Character Sets,
            http://www.iana.org/assignments/character-sets

In fact, the first one tells you:
The Character Sets Registry has moved to the following:

http://www.iana.org/assignments/character-sets

For all registries, please see the following:

http://www.iana.org/numbers.htm


Updated May 01 2001

[Ballot comment]
The RFC Editor needs to make sure the technical issues are addressed somehow. If they are addressed well, the IESG note is not needed. Advice of the RFC Editor sought.

[Note]: 'Re-review in light of new procedures for individual submissions via the RFC Editor.  This one has been in the IESG''s hands for two years!' added by Scott Hollenbeck

Touched base with Steve Bellovin via email.  I also sent the following to the author with a request to fix these issues before the IESG does anything else with the document:

There still no copyright or IPR boilerplate as requested in earlier AD review.

References need to be split into normative and informative groups.

The ABNF rules response-code, Bits, User-ID, Keyblock, Finger, Version, Key-ID, and Location are referenced but never defined.

Draft note:

The IESG notes the following editorial issues with the draft that need to
be addressed prior to publication:

  There still no copyright or IPR boilerplate as requested in earlier AD
  review.

  References need to be split into normative and informative groups.

  The ABNF rules response-code, Bits, User-ID, Keyblock, Finger, Version,
  Key-ID, and Location are referenced but never defined.

(The last of these may actually be technical as well as editorial.)

There are also a number of technical issues with this specification. The
IESG requests that the following IESG note be attached to the specification
if it is published:

  The IESG notes that protocol levels, or versions, are used to extend this
  protocol. Version numbers are quite inflexible -- each time additions are
  made to the protocol compliant server has to implement all those additions
  plus all previous additions made at lower numbers before it can claim to
  implement the new version Additionally, version numbers don't provide any
  means of returning per-capability parameters or limits.

  This protocol uses client IP address information for authentication
  purposes. This echoes similar usage in NNTP. While this technique
  has been successful for NNTP in many situations over the years, it
  is not clear it is sufficient going forward. In particular, although
  IP address spoofing attacks are rare, widespread use of dynamic
  address assignment and NAT have reduced both the ability for servers
  to be properly configured with proper client address information as
  well as the ability of an IP to uniquely identify a single client.

  This protocol uses PGP to sign data transferred from one NAS server
  to another. However, it isn't clear that all of the details of
  how to assign and validate PGP keys are sufficiently specified to
  insure inoperability.

  Finaally, various internationalization issues, e.g.
  internationalized newsgroup names, have yet to be addressed in Netnews.
  Although it is clearly inappropriate to deal with Netnews
  internationalization in this specification, the IESG notes that
  changes may be necessary in this protocol once these issues
  are addressed elsewhere.

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.

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'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.

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.

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.

That's it. I note in passing that given the security issues raised
above an IESG warning note might be attached even if they are described
in the security considerations section.

State Changes to Expert Review                                    from AD to write --Don't publish                      by Ned Freed