[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 4822

Network Working Group                                        R. Atkinson
INTERNET-DRAFT                                          Extreme Networks
                                                          25 August 2004
                                             draft-rja-ripv2-auth-00.txt
                                                Expires 25 February 2005


                   RIPv2 Cryptographic Authentication



Status of this Memo


   By submitting this Internet-Draft, I certify that any applicable patent or
   other IPR claims of which I am aware have been disclosed, or will be
   disclosed, and any of which I become aware will be disclosed, in accordance
   with RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering Task
   Force (IETF), its areas, and its working groups.  Note that other groups
   may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months and
   may be updated, replaced, or obsoleted by other documents at any time.  It
   is inappropriate to use Internet-Drafts as reference material or to cite
   them other than a "work in progress.

   The list of current Internet-Drafts can be accessed at:
        http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at:
        http://www.ietf.org/shadow.html

   This memo is a contribution to the IETF and is intended for future
   standards-track publication to update RFC-2082 and RFC-2453.  This
   memo is not yet the product of any IETF working group.

   Distribution of this memo is unlimited.


ABSTRACT


   This note describes a rough draft of a proposed revision to the RIPv2
   Cryptographic Authentication mechanism originally specified in RFC-2082.
   This document includes specific details of how HMAC SHA-1 is used with
   RIPv2 Cryptographic Authentication, whereas the original document only



Atkinson                                                        [Page 1]

INTERNET-DRAFT                                               21 Aug 2004


   specified the use of Keyed-MD5.  Also, this document clarifies a potential
   issue with an active attack on this mechanism and also adds significant
   text to the Security Considerations section.

1. INTRODUCTION


   Growth in the Internet has made us aware of the need for improved
   authentication of routing information.  RIPv2 provides for unauthenticated
   service (as in classical RIP), or password authentication.  Both are
   vulnerable to passive attacks currently widespread in the Internet.
   Well-understood security issues exist in routing protocols [Bellovin89].
   Clear text passwords, originally specified for use with RIPv2, are widely
   understood to be vulnerable to easily deployed passive attacks [RFC-1704].

   The original RIPv2 cryptographic authentication specification [RFC-2082]
   used the Keyed-MD5 cryptographic mechanism.  While there are no openly
   published attacks on that mechanism, work subsequent to the original
   specification [Dobbertin] creates concern about the ultimate strength of
   the MD5 cryptographic hash function.  Further, some end users, particularly
   certain governments, insist on the use of the SHA-1 cryptographic hash
   function rather than any other such function.  Finally, the original
   specification predated the publication of the HMAC specification
   [RFC-2104].

   So this document replaces [RFC-2082] with an improved specification.  There
   are 2 significant changes in this document.  First, this specification is
   explicitly designed to support algorithm-independence, while retaining full
   backwards compatibility with the previous specification.  Second, this
   specification adds support for the HMAC-SHA1 cryptographic mechanism to
   supplement the Keyed-MD5 mechanism that was originally specified.

   The author does NOT believe that this specification is the penultimate
   answer to RIPv2 authentication and encourages the reader to consult the
   SECURITY CONSIDERATIONS section of this document for more details on that.

   If RIPv2 authentication is disabled, then only simple misconfigurations are
   detected.  Simple passwords transmitted in the clear would further protect
   against accidential misconfigurations if that were the only threat, but are
   useless in the general case.  By simply capturing information on the wire -
   straightforward even in a remote environment - a hostile process can learn
   the password and overcome the network.

   The goal of this mechanism is to reduce risk of passive attack for RIPv2
   deployments.  That is, deployment of this mechanism greatly reduces the
   vulnerability of the RIPv2-based routing system from a passive attack.
   This risk reduction arises because with cryptographic authentication
   enabled, we transmit the output of a keyed cryptographic hash function



Atkinson                                                        [Page 2]

INTERNET-DRAFT                                               21 Aug 2004


   whose value is bound to the contents of the RIPv2 packet, rather than
   transmitting a reusable clear-text password.  The cryptographic output is a
   one-way function of a message and a secret RIPv2 Authentication Key.  This
   RIPv2 Authentication Key is never sent over the network in the clear, thus
   providing protection against the passive attacks now commonplace in the
   Internet.

   In this way, protection is afforded against forgery or message
   modification.  It is possible to replay a message until the sequence
   number changes, but the sequence number makes replay in the long term
   less of an issue.  The mechanism does not afford confidentiality,
   since messages stay in the clear; however, the mechanism is also
   exportable from most countries, which test a privacy algorithm would
   fail.  Further, since the objective of a routing protocol is to
   advertise reachability, confidentiality is not normally required for
   routing protocols.

   Other relevant rationales for the approach are that MD5 and SHA-1
   are both being used for other purposes and are therefore generally
   already present in IP routers, as is some form of password management.
   A similar approach has been standardized for use in IP-layer
   authentication. [AH]

1.1 Terminology


   In this document, the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" are to be interpreted as described in [BCP14] [RFC-2119] and
   indicate requirement levels for compliant or conformant implementations.

2.  Implementation Approach


   Implementation requires use of a special packet format, special
   authentication procedures, and also management controls.  Implementers
   need to remember that the SECURITY CONSIDERATIONS section is an integral
   part of this specification and contains important parts of this
   specification.

2.1.  RIPv2 PDU Format


        The basic RIPv2 message format provides for an 8 byte header with
   an array of 20 byte records as its data content.  When Keyed MD5 is used,
   the same header and content are used, except that the 16 byte
   "authentication key" field is reused to describe a "Cryptographic
   Authentication" trailer.  This trailer contains five fields as



Atkinson                                                        [Page 3]

INTERNET-DRAFT                                               21 Aug 2004


   follows:

      AUTHENTICATION TYPE
            The "Authentication Type" is Cryptographic Hash Function,
      which is indicated by the value 3.

      RIPv2 PACKET LENGTH
           An unsigned 16 bit offset from the RIPv2 header to the output of
      the cryptographic hash function in use (if no other trailer fields are ever
      defined, this value equals the RIPv2 Data Length).

      KEY IDENTIFIER
           An unsigned 8-bit field that contains the Key Identifier or
      Key-ID. This identifies the RIPv2 Security Association in use for this
      packet.  The RIPv2 Security association includes the Authentication Key
      that was used to create the Authentication Data for this RIPv2 message.
      In implementations supporting more than one authentication algorithm,
      the Key-ID also indicates the authentication algorithm in use for this
      message. A key is always associated with an interface.

      AUTHENTICATION DATA LENGTH
           An unsigned 8-bit field that contains the length in octets of the
      trailing Authentication Data field.  The presence of this field provides
      cryptographic algorithm independence.

      SEQUENCE NUMBER
           An unsigned 32 bit sequence number.  The sequence number MUST be
      non-decreasing for all messages sent with a given Key ID value.


   The authentication trailer consists of the Authentication Data, which is
   the output of the keyed cryptographic hash function.  See later
   subsections of this section for details on computing this field.

2.2 RIPv2 Security Association


   Understanding the RIPv2 Security Association concept is central to
   understanding this specification.  A RIPv2 Security Association
   contains the set of shared authentication configuration parameters
   needed by the legitimate sender or any legitimate receiver.

   An implementation MUST be able to support at least 2 concurrent RIPv2
   Security Associations on each RIP interface.  This is a functional
   requirement for supporting key rollover.  Support for key rollover is
   mandatory.

   The RIPv2 Security Association is selected by the sender based on the



Atkinson                                                        [Page 4]

INTERNET-DRAFT                                               21 Aug 2004


   outgoing interface. Each Security Association has a lifetime and other
   configuration parameters (see below) associated with it.  In normal
   operation, no Security Association is used outside its lifetime.

   The minimum data items in a RIPv2 Security Association are as follows:

      KEY-IDENTIFIER
           This unsigned 8-bit 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 Security Association to use based on the
      outbound interface for this RIPv2 packet and then places the correct
      KEY-IDENTIFIER value into that packet.

      AUTHENTICATION ALGORITHM
           This information is never sent in clear-text over the wire,
      but is essential to correct operation.  Because this information is
      not sent on the wire, the implementer chooses an implementation-specific
      representation for this information.  At present, the following
      values are possible:  KEYED-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384,
      and HMAC-SHA-512.

      AUTHENTICATION KEY
           This is the value of the cryptographic authentication key used with
      the associated Authentication Algorithm.  It MUST NOT ever be sent over the
      network in clear-text via any protocol.  The length of this key will depend
      on the Authentication Algorithm in use.  Operators should take care to
      select unpredictable and crptographically strong keys, avoiding any keys
      known to be weak for the algorithm in use. [RFC-1750] contains helpful
      information on key generation techniques.

      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 value used in
      the sequence number is arbitrary, but two examples are the time of the
      message's creation or a simple message counter.

      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



Atkinson                                                        [Page 5]

INTERNET-DRAFT                                               21 Aug 2004


      operational practice because it reduces security as compared with
      periodic rekeying.

2.3  Processing Algorithm


   When the authentication type is "Cryptographic Authentication", message
   processing is changed in message creation and reception.

          0                   1                   2                   3 3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Command (1)   | Version (1)   |       Routing Domain (2)      |
      +---------------+---------------+-------------------------------+
      |             0xFFFF            | AuType=Keyed Message Digest   |
      +-------------------------------+-------------------------------+
      |    RIPv2 Packet Length        |    Key ID    | Auth Data Len  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Sequence Number (non-decreasing)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               reserved must be zero                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               reserved must be zero                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      /    (RIPv2 Packet Length - 24) bytes of Data                   /
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             0xFFFF            |       0x01                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                Authentication Data (variable length)          /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Algorithm-dependent processing is described in separate sub-sections
   later in this section.

2.3.1.  Message Generation


   The RIPv2 Packet is created as usual, with these exceptions:

      (1) The UDP checksum SHOULD be calculated, but MAY be set to zero.

      (2) The authentication type field indicates Cryptographic Authentication (3).

      (3) The authentication "password" field is reused to store a packet offset
          to the Authentication Data, a Key Identifier, the Authentication Data



Atkinson                                                        [Page 6]

INTERNET-DRAFT                                               21 Aug 2004


          Length, and a non-decreasing sequence number.

   See also Section 2.2 above on RIPv2 Security Association for important
   background.

      (1)  The RIPv2 header's packet length field indicates the standard
           RIPv2 portion of the packet.

      (2)  The Authentication Data Offset, Key Identifier, and
           Authentication Data size fields are filled in appropriately.

      (3)  The RIPv2 Authentication Key is now appended to the data.
           For all algorithms, the RIPv2 Authentication Key is never longer
           than the output of the algorithm in use.

      (4)  Trailing pad (if any) and length fields are added and the
           Authentication Data value is calculated according to the
           Authentication Algorithm that is in use.

      (5)  The resulting Authentication Data value is written over the RIPv2
           Authentication Key.  The trailing pad (if any) is not actually
           transmitted, as it is entirely predictable from the message length
           and Authentication Algorithm in use.

2.3.2.  Message Reception


   When the message is received, the process is reversed:

   (1)  The received Authentication Data is set aside,

   (2)  The appropriate RIPv2 Security Association is determined from the
        value of the Key Identifier field and the interface the packet
        was received on.

   (3)  The Authentication Key is written into the appropriate number of bytes
        starting at the offset indicated,

   (4)  Appropriate padding is added if needed, and

   (5)  A new authentication data result is calculated using the
        Authentication Algorithm for the appropriate RIPv2 Security Association.

   (6) The calculated Authentication Data result is compared with
       the received Authentication Data.

   (7) If the calculated authentication data result does not match the
       received Authentication Data, then the message is discarded unprocessed



Atkinson                                                        [Page 7]

INTERNET-DRAFT                                               21 Aug 2004


       and a security event SHOULD be logged by the RIPv2 subsystem of the
       receiving system.  That 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
       RIPv2 Authentication failed upon receipt.

   (8) If the neighbor has been heard from recently enough to have viable
       routes in the route table and the received sequence number is less
       than the last one received, the message likewise is discarded
       unprocessed.  If the received sequence number is less than the last
       one received, that security event should be logged.  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
       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.

   Acceptable messages are now truncated to RIPv2 message itself and
   treated normally.

   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.
   Router vendors are encouraged to provide stable storage for all
   components of a RIPv2 Security Association to reduce the risk of
   such attacks.

2.3.2.  Keyed-MD5 Algorithm-Dependent Processing


   This section describes algorithm-dependent processing steps for when the
   Keyed-MD5 Authentication Algorithm is in use.  The MD5 hash function is
   defined in [RFC-1321].

   The Authentication Key is 16 octets long when Keyed-MD5 is in use.  The key
   with value of all zero bits is believed to be weak and should not be used.

   For this algorithm, the output Authentication Data contained in the trailer
   is 16 bytes long.  During digest calculation, this is effectively followed
   by a pad field and a length field as defined by [RFC-1321].

   When Keyed-MD5 is in use, the following trailer is appended in memory



Atkinson                                                        [Page 8]

INTERNET-DRAFT                                               21 Aug 2004


   by the MD5 algorithm and treated as though it were part of the message.
   Pad Bytes will be present if and only if so required by RFC-1321's
   processing rules.

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Authentication Key                      |
    /                        (16 octets long)                       /
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        zero or more pad bytes (as defined by RFC 1321)        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     64 bit message length MSW                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     64 bit message length LSW                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.3.3  HMAC-SHA1 Algorithm-Dependent Processing


   This section describes algorithm-dependent processing steps for when the
   HMAC-SHA1 Authentication Algorithm is in use.  While HMAC was originally
   documented in [RFC-2104], for this specification the generalised HMAC
   process is performed as defined in [FIPS-198].  The US NIST Secure Hash
   Standard (SHA-1) is defined by [FIPS-180-2], which includes specifications
   for SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512.

   The output of the cryptographic computations (e.g. HMAC-SHA1) is NOT
   truncated for RIPv2 Cryptographic Authentication.

   When HMAC-SHA1 is in use, the Authentication Key is 160 bits long.  When
   HMAC-SHA-224 is in use, the Authentication Key is 224 bits long.  When
   HMAC-SHA-256 is in use, the Authentication Key is 256 bits long.  When
   HMAC-SHA-512 is in use, the Authentication Key is 512 bits long.  The
   Authentication Data length is equal to the Authentication Key length for
   the authentication algorithm in use.  Alternately phrased in the language
   of [FIPS-198], Section 5, "length of K == B" is always true with this
   specification.

   The key with value of all zero bits is believed to be weak and should not
   be used.

   During Authentication Data calculation, the Authentication Data field in
   memory contains the Authentication Key and is effectively followed by a pad
   field and a length field as shown below.  Padding, if any, is performed as
   specified by Section 5.1 of [FIPS-180-2] with reference to the actual
   SHA variant algorithm that is actually in use.





Atkinson                                                        [Page 9]

INTERNET-DRAFT                                               21 Aug 2004


    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Authentication Key                      |
    /                        (16 octets long)                       /
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        zero or more pad bytes (as defined by FIPS-180-2)      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     64 bit message length MSW                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     64 bit message length LSW                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


3.  Management Procedures


   Key management is an important component of this mechanism and
   proper implementation is central to providing the intended level
   of risk reduction.

3.2.  Key Management Requirements


   It is strongly desirable that a hypothetical security breach in one
   Internet protocol not automatically compromise other Internet
   protocols.  The Authentication Key of this specification SHOULD NOT
   be stored using protocols or algorithms that have known flaws.
   Implementations MUST support the storage of more than one key at the
   same time, although it is recognized that only one key will normally
   be active on an interface. They MUST associate a specific lifetime
   (i.e., date/time first valid and date/time no longer valid) and a key
   identifier with each key, and MUST support manual key distribution
   (e.g., the privileged user manually typing in the key, key lifetime,
   and key identifier on the router console).  The lifetime may be
   infinite.  If more than one algorithm is supported, then the
   implementation MUST require that the algorithm be specified for each
   key at the time the other key information is entered. Keys that are
   out of date MAY be deleted at will by the implementation without
   requiring human intervention.  Manual deletion of active keys SHOULD
   also be supported.

   It is likely that the IETF will define a standard key management protocol
   for use with routing protocols.  It is strongly desirable to use that key
   management protocol to distribute RIPv2 Authentication Keys among
   communicating RIPv2 implementations.  Such a protocol would provide
   scalability and significantly reduce the human administrative burden.
   The Key-ID field can be used as a hook between RIPv2 and such a future
   protocol.



Atkinson                                                       [Page 10]

INTERNET-DRAFT                                               21 Aug 2004


   Key management protocols have a long history of subtle flaws that are
   often discovered long after the protocol was first described in
   public.  To avoid having to change all RIPv2 implementations should
   such a flaw be discovered, integrated key management protocol
   techniques were deliberately omitted from this specification.

3.3.  Key Management Procedures


   As with all security methods using keys, it is necessary to change
   the RIPv2 Authentication Key on a regular basis.  To maintain routing
   stability during such changes, implementations MUST be able to store
   and use more than one RIPv2 Authentication Key on a given interface
   at the same time.

   Each key will have its own Key Identifier, which is stored locally.
   The combination of the Key Identifier and the interface associated
   with the message uniquely identifies the Authentication Algorithm and
   RIPv2 Authentication Key in use.

   As noted above in Section 2.2.1, the party creating the RIPv2 message will
   select a valid key from the set of valid keys for that interface.  The
   receiver MUST use the Key Identifier and interface to determine which key
   to use for authentication of the received message.  More than one key MAY
   be associated with an interface at the same time.  The receiver MUST NOT
   simply try all keys that might be configured for RIPv2 on the receiving
   interface, as that creates an easily exploited denial-of-service attack on
   the RIP subsystem of the receiver.

   Hence it is possible to have fairly smooth RIPv2 Authentication Key
   rollovers without losing legitimate RIPv2 messages because the stored
   key is incorrect and without requiring people to change all the keys
   at once.  To ensure a smooth rollover, each communicating RIPv2
   system must be updated with the new key several minutes before the
   current key will expire and several minutes before the new key
   lifetime begins. The new key should have a lifetime that starts
   several minutes before the old key expires. This gives time for each
   system to learn of the new RIPv2 Authentication Key before that key
   will be used.  It also ensures that the new key will begin being used
   and the current key will go out of use before the current key's
   lifetime expires.  For the duration of the overlap in key lifetimes,
   a system may receive messages using either key and authenticate the
   message. The Key-ID in the received message is used to select the
   appropriate key for authentication.







Atkinson                                                       [Page 11]

INTERNET-DRAFT                                               21 Aug 2004


4.  Conformance Requirements


   For this specification, the term "conformance" has identical meaning
   to the phrase "full compliance".

   The Keyed MD5 authentication algorithm and the HMAC-SHA1 algorithm MUST be
   implemented by all conforming implementations. In addition, the
   HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 algorithms SHOULD be
   implemented.  MD5 is defined in RFC-1321.  SHA-1, SHA-256, SHA-384, and
   SHA-512 have been defined by the US National Institute of Standards &
   Technology (NIST) in [FIPS-180-2].  A conforming implementation MAY also
   support additional authentication algorithms.  Manual key distribution as
   described above MUST be supported by all conforming implementations. All
   implementations MUST support the smooth key rollover described under "Key
   Change Procedures."

   The user documentation provided with the implementation MUST contain
   clear instructions on how to ensure that smooth key rollover occurs.

   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.

   The Security Considerations section of this document is an integral
   part of the specification, not just discussion of the protocol.

5.  Security Considerations


8.  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.  Protection against active attacks is
   incomplete in this current specification.  The main issue relative
   to active attacks lies in the need to support the case where another
   router has recently rebooted and lacks the non-volatile storage needed
   to remember the current RIPv2 sequence number across that reboot.

8.1 Known Pathological Cases


   Two known pathological cases exist which MUST be handled by implementations.
   Both of these are failures of the network manager.  Both of these should be
   exceedingly rare in normal operation.



Atkinson                                                       [Page 12]

INTERNET-DRAFT                                               21 Aug 2004


      (1) During key rollover, devices might exist which have not yet been
      successfully configured with the new key. Therefore, routers SHOULD
      implement (and would be well advised to implement) an algorithm that
      detects the set of keys being used by its neighbors, and transmits its
      messages using both the new and old keys until all of the neighbors are
      using the new key or the lifetime of the old key expires.  Under normal
      circumstances, this elevated transmission rate will exist for a single
      update interval.

      (2) In the event that the last key associated with an interface expires, it
      is unacceptable to revert to an unauthenticated condition, and not
      advisable to disrupt routing.  Therefore, the router should send a "last
      authentication key expiration" notification to the network manager and
      treat the key as having an infinite lifetime until the lifetime is
      extended, the key is deleted by network management, or a new key is
      configured.

      In some circumstances, this last practice can leave an opening to an active
      attack on the RIPv2 routing subsystem.  Therefore, any actual occurance of
      a key expiration SHOULD cause a security event to be logged by the
      implementation.  This log item SHOULD include at least the fact that the
      key expired, the RIP routing protocol instance(s) affected, the routing
      interfaces affected, the Key-ID that is affected, and the current
      date/time.  Operators are encouraged to check such logs as an operational
      security practice that can help detect active attacks on the RIPv2 routing
      subsystem.  Further, implementations SHOULD provide a configuration knob
      to let a network operator prefer to have the RIPv2 routing fail when
      the last key expires, rather than continue using RIPv2 in an insecure
      manner.

5.2 Other Security Considerations


   Separately, the receipt of a RIPv2 packet using cryptographic
   authentication but containing an invalid or unknown Key-ID value might
   indicate an active attack on the RIP routing subsystem and is a significant
   security event.  Therefore, any actual receipt of a RIPv2 packet using
   cryptographic authentication and containing an unknown, expired, or
   otherwise invalid KEY-ID value SHOULD cause a security event to be logged
   by the implementation.  This log item SHOULD include at least the fact that
   the invalid KEY-ID was received, the source IP address of the packet
   containing the invalid KEY-ID, the interface(s) the packet was received on,
   the KEY-ID received, and the current date/time.

   Also, the use of SNMP, even SNMP with cryptographic confidentiality
   enabled, to read or write RIPv2 Authentication Keys is NOT RECOMMENDED.
   This practice would create a potential for a cascading vulnerability,
   whereby a compromise in the SNMP security implementation would necessarily



Atkinson                                                       [Page 13]

INTERNET-DRAFT                                               21 Aug 2004


   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
   from the compromised router.  Also, the use of SNMP to configure which form
   of RIPv2 authentication is in use is also NOT RECOMMENDED.

   Further, for similar reasons it is RECOMMENDED that any future revisions to
   the RIPv2 Management Information Base deprecate or omit any MIB objects
   that would permit reading or writing any RIPv2 cryptographic authentication
   key.

   Also, it is RECOMMENDED that any future revisions to the RIPv2 Management
   Information Base (MIB) deprecate or omit any MIB objects that would permit
   SNMP to be used to modify whether the RIPv2 instance uses cryptographic
   authentication, cleartext password authentication, or no authentication.

   Also, it is RECOMMENDED that any future revisions to the RIPv2
   Management Information Base (MIB) consider adding MIB objects that could be
   used to read the set of security events that have been logged by the RIPv2
   subsystem.

   Users need to understand that the quality of the security provided by
   this mechanism depends completely on the strength of the implemented
   authentication algorithms, the strength of the key being used, and
   the correct implementation of the security mechanism in all
   communicating RIPv2 implementations. This mechanism also depends on
   the RIPv2 Authentication Key being kept confidential by all parties.
   If any of these incorrect or insufficiently secure, then no real
   security will be provided to the users of this mechanism.

   Use of high assurance development methods is RECOMMENDED for
   implementations of this specification, in order to reduce the risk of
   subtle implementation flaws that might adversely impact the operational
   risk reduction that this specification seeks to provide.

   A subtle user-interface consideration also should be noted.  If a
   user-interface only permits the entry of human-readable text (e.g. a
   password in US-ASCII format) for use as a cryptographic key, significant
   numbers of bits of the cryptographic key in use become predictable, thereby
   reducing the strength of the key in this context.  For this reason,
   implementations of this specification SHOULD support the entry of
   RIPv3 cryptographic authentication keys in hexadecimal format.

5.3 Confidentiality & Traffic Analysis Considerations


   Confidentiality is not provided by this mechanism.  Recent work in the IETF
   provides a standard mechanism for IP-layer encryption [8] and for IP-layer
   authentication [AH].  We do not require use of either of those mechanisms



Atkinson                                                       [Page 14]

INTERNET-DRAFT                                               21 Aug 2004


   in this specification in order to preserve backwards-compatibility with the
   installed base of RIPv2 systems that support cryptographic authentication.

   Protection against traffic analysis is also not provided.  Mechanisms such
   as bulk link encryption might be used when protection against traffic
   analysis is required.

5.4 Future Directions


   Specification and deployment of a standards-track key management protocol
   that supporting this RIPv2 cryptographic authentication mechanism would be
   a significant next step in operational risk reduction and might actually
   increase the ease of deployment and operation of this mechanism.  Such
   specification is beyond the scope of this document.

   Finally, we observe that this mechanism is not the penultimate security
   approach to RIPv2 authentication.  Rather, it is believed that this
   particular mechanism represents a significant risk reduction over previous
   methods (e.g. plain-text passwords), while remaining straight-forward to
   implement correctly and also straight-forward to deploy.  User communities
   that believe this mechanism is not adequate to their needs are encouraged
   to consider using digital signatures with RIPv2.  [RFC-2154] specifies the
   use of OSPF with Digital Signatures; that document might be a starting
   point for creating such a specification for the RIPv2 protocol.  Digital
   signatures are significantly more expensive computationally and are also
   significantly more difficult to deploy operationally, as compared with the
   mechanism specified here.  It appears likely that the much of the
   mechanism in this document could be reused with digital signatures.

6. IANA Considerations


   No new IANA protocol parameter registries are created by this specification.

   One existing registry entry is renamed.  The entry (3) for authentication
   type for Routing Information Protocol version 2 is renamed from "Message
   Digest Authentication" to "Cryptographic Authentication" to more clearly
   reflect the algorithm-independent nature of this mechanism.

Acknowledgments


   Fred Baker was co-author of the earlier RIPv2 MD5 Authentication document.
   This document is a direct derivative of that earlier document, though
   it has been significantly reworked.  Any errors are the responsibility of
   the current author.




Atkinson                                                       [Page 15]

INTERNET-DRAFT                                               21 Aug 2004


Informative References


   [RFC-1321]  Rivest, R., "The MD5 Message-Digest Algorithm",
               RFC-1321, April 1992.

   [RFC-1704]  N. Haller & R. Atkinson, "On Internet Authentication",
               RFC-1704, October 1994.

   [RFC-1724]  Malkin, G., and F. Baker, "RIP Version 2 MIB Extension",
               RFC-1724, November 1994.

   [RFC-1750]  Eastlake 3rd, D, S. Crocker, & J. Schiller, "Randomness
               Recommendations for Security", RFC-1750, December 1994.

   [RFC-2104]  H. Krawczyk, M. Bellare, & R. Canetti, "Keyed-Hashing for
               Message Authentication", RFC-2104, February 1997.

   [RFC-2154]  Murphy, S., M. Badger, and B. Wellington, "OSPF with
               Digital Signatures", RFC-2154, June 1997.

   [Bellovin89]  S. Bellovin, "Security Problems in the TCP/IP Protocol Suite",
                 ACM Computer Communications Review, Volume 19, Number 2,
                 pp.32-48, April 1989.

   [AH]  Atkinson, R., "IP Authentication Header", RFC-1826, August 1995.

   [ESP] Atkinson, R., "IP Encapsulating Security Payload", RFC-1827,
         August 1995.


Normative References


[RFC-2453]  Malkin, G., "RIP Version 2", RFC-2453, November 1988.

[FIPS-180-2] US National Institute of Standards & Technology (NIST),
        "Secure Hash Specification", US Federal Information Processing
        Standard 180-2, NIST, Gaithersburg, MD,
     USA, 1 August 2002.  http://csrc.nist.gov/cryptval

[FIPS-198] US National Institute of Standards & Technology (NIST),
        "The Keyed-Hash Message Authentication Code (HMAC)",
        US Federal Information Processing Standard 198, NIST,
        Gaithersburg, MD, USA, 6 March 2002.  http://csrc.nist.gov/cryptval






Atkinson                                                       [Page 16]

INTERNET-DRAFT                                               21 Aug 2004


COPYRIGHT NOTICE


   Copyright (C) The Internet Society 2004.  This document is subject to the
   rights, licenses and restrictions contained in BCP 78, and except as set
   forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an "AS
   IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS
   SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
   LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
   INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.


Author's Address

   R. Atkinson
   Extreme Networks
   3585 Monroe Street
   Santa Clara, CA

   Phone: (408) 579-2800
   EMail: rja@extremenetworks.com


Filename:  draft-rja-ripv2-auth-00.txt
Expires:   25 February 2005






















Atkinson                                                       [Page 17]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/