FW: DISCUSS and COMMENT on: draft-rja-ripv2-auth-03.txt

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

FYI, as a result of my initial findings and further comments
by Dan and Mike, I have recorded the following DISCUSS.

Thanks to Dan and Mike for their very fast review and comments.

Bert
p.s. I will be leaving for a one week vacation in 2 hours.

-----Original Message-----
From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org]On Behalf Of
Wijnen, Bert (Bert)
Sent: Friday, December 02, 2005 10:28
To: Russ Housley (E-mail); Ran Atkinson (E-mail); matthew.fanto@nist.gov
Cc: Mike Heard (E-mail); Dan Romascanu (E-mail); Iesg (E-mail)
Subject: DISCUSS and COMMENT on: draft-rja-ripv2-auth-03.txt


Russ (and Ran and Matthew),
as I mentioned during the IESG telechat yesterday, 
I only became aware of teh SNMP impacts of this document
pretty late (right before and during the telechat).
So I checked with MIB doctors, and here is the DISCUSS
text that I now recorded in the ID-tracker.

For completeness, I have also added the COMMENTs that
I had recorded earlier.

Discuss:
[2005-12-02] 
Main point of my DISCUSS (sorry for being late, but I did
verbally say so during IESG telechat on Dec 1st):

It's perfectly reasonable to say "use a key management protocol
to managage keys, not SNMPv3"  but it is less reasonable to 
demand that there be no way to read e.g. authentication type
via SNMPv3.

Thanks to MIB Doctors Dan Romascanu and Mike HEard for review
and help formulating the issue and details:

Section 5.2 starts off with:

  Also, the use of SNMP, even SNMPv3 with cryptographic
  authentication and cryptographic confidentiality enabled,
  to read or write RIPv2 Security Associations, or any component
  of the security association (for example the cryptographic key),
  is NOT RECOMMENDED.  This practice would create a potential for a
  cascading vulnerability, whereby a compromise in the SNMP security
  implementation would necessarily lead to a compromise not only
  of the local routing table (which could be accessed via SNMP)
  but also of all other routers that receive RIPv2 packets
  (directly or indirectly) from the compromised router.  Similarly,
  the use of other protocols (e.g. RADIUS, Diameter) to configure
  the security association is also NOT RECOMMENDED.  Instead, a key
  management protocol approved by the IETF should always be used
  for automated configuration of RIPv2 Security Associations.
  Recent IRTF and IETF work into multicast key manaagement appears
  promising in this regard.

This is problematic. Beyond the judgment value about different
security methods that we would leave to the security experts to judge
about, defining SNMPv3 as NOT RECOMMENDED, even for read operations
seems extreme and not in synch with the OPS area recommendations,
boilerplates, etc. (Ran Atkinson was somehwat involved in that 
several years back).

Further it states:

  Also, the use of SNMP to configure which form of RIPv2
  authentication is in use is also NOT RECOMMENDED because of a
  similar cascading failure issue.  Any future revision of the
  RIPv2 Management Information Base (MIB) should deprecate or omit
  any MIB objects that would permit modification of the RIPv2
  Authentication mode (e.g. none, cleartext password,
  RIPv2 Cryptographic Authentication) in use.

This seems OK, but we would add a reference to the document that
needs to be modified. Mike has looked at RFC 1724 and believes
that that is the document in question.  The offending object is
rip2IfConfAuthType.  It needs to have a new enum value added to
accomodate the new auth type specified in
draft-rja-ripv2-auth-03.txt.  In addition, the compliance statement
does not have a MIN-ACCESS for this read-create object;  at a
minimum, a new compliance statement should be written that allows
this object to be implemented as read-only.

rip2IfConfAuthKey is the object with the key, and it also lacks a
MIN-ACCESS clause.  Since this object always returns ''H when read,
it is reasonable for its MIN-ACCESS to be not-accessible.  (It would
also be OK to deprecate or obsolete the object, I think.)

It would also be useful to mention what means of configuration
are acceptable if SNMPv3 is not good enough. 

The next piece of text is:

      Further, for similar reasons, any future revisions to the
  RIPv2 Management Information Base (MIB) SHOULD deprecate or omit any
  MIB objects that would permit reading or writing any RIPv2 Security
  Association, or any RIPv2 Security Association component (for example
  the cryptographic key).

Again, too extreme, when it comes to read operations.

      Also, it is RECOMMENDED that any future revisions to the RIPv2
  Management Information Base (MIB) consider adding MIB objects to hold
  information about any RIPv2 security events that might have occurred
  and MIB objects that could be used to read the set of security events
  that have been logged by the RIPv2 subsystem.  Each security event
  mentioned in this document is also RECOMMENDED for inclusion in future
  versions of RIPv2 SNMP MIB as an INFORM object.

The intent seems OK to me, the terminology is wrong. Instead of '
inclusion in future versions of RIPv2 SNMP MIB as an INFORM object' it
should say 'inclusion of appropriate notifications and MIB objects in
future versions of the RIPv2 MIB module'. (addresses the original 
comment that I had put in yesterday, dec 1st).

Comment:
[2005-12-01] Security Considerations, section 5.2, last para states

  that have been logged by the RIPv2 subsystem.  Each security event
  mentioned in this document is also RECOMMENDED for inclusion in future
  versions of RIPv2 SNMP MIB as an INFORM object.

There is no "INFORM object". 
I think what is meant he is an object that has a MAX ACCESS that
at least allows acces level of "accessible-for-notify".

Further comments from AAA_doctor Jari Arkko 

>  o draft-rja-ripv2-auth-03.txt
>    RIPv2 Cryptographic Authentication (Proposed Standard) - 1 of 1 
>    Token: Russ Housley
>
I reviewed this spec. Overall, its good, I have no substantive
comments. A couple of editorial issues in case you have an
opportunity to revise the spec:

- Section 5.4 talks about "recent work in the IETF" and then
  points to references from -95. Maybe this part needs an
  update :-)

- Informational references include pointers to the original
  IPsec RFCs. I would suggest replacing these RFCs with
  the newest that are available.

- I would have expected to see SHA-256 et al be mentioned
  earlier on. They may be related to SHA-1 but FIPS-180-2
  considers them separate algorithms, and for pure ease
  of finding documents, I think the abstract should mention
  all the algorithms.

--Jari