RIPv2 Cryptographic Authentication
Note: This ballot was opened for revision 06 and is now closed.
(Scott Hollenbeck) Discuss
Discuss (2005-11-23 for -)
The abstract says: "This note describes a revision to the RIPv2 Cryptographic Authentication mechanism originally specified in RFC-2082". Is this document supposed to update or obsolete RFC 2082? The text doesn't say for sure, and there's no reference. Section 2.1 (and elsewhere): "8 byte header with an array of 20 byte records". "octet" would be better than "byte" if 8-bit values are being described.
(Bert Wijnen) (was No Objection) Discuss
Discuss (2005-12-02 for -)
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 for -)
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
(Alex Zinin) Discuss
Discuss (2005-12-01 for -)
This document is subject to provisions of 1264, even though it is not coming from the RTG area. Can we have the implementation status for it? > 2.1. RIPv2 PDU Format Please add an illustration showing lengths of the fields and their arrangement in the RIPv2 message. > KEY-IDENTIFIER (KEY-ID) > The unsigned 8-bit KEY-ID value is used to identify the RIPv2 > Security Association in use for this packet. The receiver uses > the combination of the interface the packet was receive upon and > this value to uniquely identify the appropriate Security > Association. The sender selects which RIPv2 Security Association > to use based on the outbound interface for this RIPv2 packet and > then places the correct KEY-ID value into that packet. What if the sender has multiple active SAs on an interface. > SEQUENCE NUMBER > This is an unsigned 32-bit number. For a given KEY-ID value, > this number MUST NOT decrease. In normal operation, the operator > should rekey the RIPv2 session prior to reaching the maximum > value. The initial value used in the sequence number is > arbitrary. Please say that this is the outbound sequence number > START TIME > This is a local representation of the day and time that > this Security Association first becomes valid. > > STOP TIME > This is a local representation of the day and time that > this Security Association becomes invalid (i.e. when it expires). > It is permitted, but not recommended, for an operator to configure > this to be "never expire". The "never expire" value is not > recommended operational practice because it reduces security > as compared with periodic rekeying. Are these activation times for sending or for inbound message validation, or both? > When creating the RIPv2 Packet, the follow process is followed: > > (1) The packet length field of the RIPv2 header indicates the > size of the main body of the RIPv2 packet. > > (2) An appropriate RIPv2 Security Association is selected for > use with this packet. How is it selected? > The Authentication Data Offset, > Key Identifier, and Authentication Data size fields are > filled in appropriately. > 2.3.2. Message Reception > > > When the message is received, the process is reversed: > > (1) The received Authentication Data is set aside and stored > for later use, > > (2) The appropriate RIPv2 Security Association is determined > from the value of the Key Identifier field and the interface > the packet was received on. Nowhere in the algorithm is the SA's start/stop times are checked. > (6) If the neighbor has been heard from recently enough to have viable > routes in the local routing table, and the received sequence number > is less than the last sequence number received, then the message > MUST be discarded unprocessed. If the received sequence number > is less than the last sequence number received, that fact SHOULD > be logged as a security event. This logged security event SHOULD > indicate at least the day/time that the bad packet was received, > the Source IP Address of the received RIPv2 packet, the Key-ID > field value, and the fact that an out of order RIPv2 Sequence > Number was received. > > When connectivity to the neighbor has been lost, the receiver > SHOULD be ready to accept either: > - a message with a sequence number of zero. > - a message with a higher sequence number than > the last received sequence number. You need to say somewhere earlier in the text, that neighbor-specific state needs to be maintained. Simple RIP implementations (without demand-circuit extensions) do not normally maintain it, and get away with keeping soft state for routes only. > NOTA BENE: > A router that has forgotten its current sequence number but > remembers its Security Association MUST send its first packet with a > sequence number of zero. This leaves a small opening for a replay > attack. Actually, it's not at all small. If I recorded RIP packets from the router's previous incarnation, I can play them back all day long and it doesn't matter if the rebooted router managed to send its update first. > 3.2. Key Management Requirements > ... > An operator MAY configure the Security Association lifetime > to infinite, which means that the session is never rekeyed. Normally, we use 2119 language to specify implementation requirements. This one is a prose statement about what an operator can do. "may" instead? > 4. Conformance Requirements ... > The user documentation provided with the implementation MUST contain > clear instructions on how to configure the implementation such that > smooth key rollover occurs successfully. Checking vendor's documentation is not part of IETF's process. Please remove. > Implementations SHOULD support a standard key management protocol > for secure distribution of RIPv2 Authentication Keys once such a > key management protocol is standardized by the IETF. This makes conformance to this document dependant on future IETF developments, without making it clear which protocol(s) will be required for interoperability. Please remove. > 5. Security Considerations > This entire memo describes and specifies an authentication mechanism > for the RIPv2 routing protocol that is believed to be secure against > passive attacks. Passive attacks are clearly widespread in the > Internet at present.[HA94] It has never been clear to me what the author means by "passive attacks" in routing. In this particular document, if he means this mechanism prevents passive eavesdropping, then this is not true, as no confidentiality if provided. If he means passively recorded packets cannot be used later to mount an active attack, this isn't true either, as the sequence space isn't guaranteed to be preserved across reboots. In any case, saying "is believed to be secure against passive attacks" seems inappropriate. > 5.2 Security Considerations for Network Management ... > 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. > > 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). I'm skeptical about this part. An individual submission, telling what the IETF should do in future...
(Russ Housley) Yes
Comment (2005-11-30 for -)
Comments from Jari Arkko: 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 Arkko) No Objection
(Ross Callon) No Objection
(Brian Carpenter) No Objection
When posting the -06 version, the Secretariat noticed that the boilerplate is unconventional. Since it seems to contain the right words in unusual places, I told them to post it anyway, but in general I believe we should ask authors to follow the guidelines carefully.
(Margaret Cullen) No Objection
(Lisa Dusseault) (was Discuss) No Objection
(Lars Eggert) (was Discuss) No Objection
Moving the remaining items from my DISCUSS into a COMMENT, as the DISCUSS-worthy things have been addressed or have Magnus holding a DISCUSS on them. Section 2.1: Do different keys have unique IDs? Can a key have multiple IDs? Section 2.2: "This information doesn't need to be sent in each packet, so it is never sent in the clear-text over the wire." I don't follow this logic: "not every packet" implies "never cleartext"? Section 2.2 and Section 2.3.2 step 6:Only when the sequence number decreases are packets not processed. Are RIPv2 messages idempotent? Otherwise I don't see how this protects against immediate replays. Section 2.3.1: "UDP checksum SHOULD be calculated but MAY be set to zero." If all the crypto hashes are stronger, shouldn't the SHOULD and the MAY be reversed? Nit: There is some confusion throughout the draft with regards to RFC2119 language.
(Bill Fenner) No Objection
(Ted Hardie) No Objection
(Sam Hartman) (was Discuss, Yes) No Objection
I think the advice in section 3 and the strong recommendation that keys be used for short periods of time is good advice. However I think it is hugely impractical to implement. I think we should not give advice that we believe cannot reasonably be implemented because doing so lessens the effect of advice we do give.
(Cullen Jennings) No Objection
Comment (2006-04-06 for -)
I hope the many comments others have provided get incorporated into next version of draft. One trivial NIT, in section 2.5, I suspect "repeat B times" was meant to be 8.
(David Kessens) No Objection
(Allison Mankin) No Objection
(Jon Peterson) No Objection
(Dan Romascanu) No Objection
(Mark Townsley) No Objection
Magnus Westerlund (was Discuss) No Objection
nd of Section 2.1: XXX (add packet diagram here) Missing figure. And I think the figure could really help. Section 3.1 is missing.