home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-ripv2-md5-auth-00.txt < prev    next >
Text File  |  1997-09-04  |  25KB  |  813 lines
  1.  
  2.  
  3.  
  4.  
  5. DRAFT                  RIP-II MD5 Authentication            January 1997
  6.  
  7.  
  8.                        RIP-II MD5 Authentication
  9.                       draft-ietf-ripv2-md5-auth-00.txt
  10.  
  11.                       Wed Jan  8 23:54:15 PST 1997
  12.  
  13.  
  14.                                Fred Baker
  15.                              Cisco Systems
  16.                              fred@cisco.com
  17.  
  18.  
  19.                           Status of this Memo
  20.  
  21. This document is an Internet Draft.  Internet Drafts are working
  22. documents of the Internet Engineering Task Force (IETF), its Areas, and
  23. its Working Groups.  Note that other groups may also distribute working
  24. documents as Internet Drafts.
  25.  
  26. Internet Drafts are valid for a maximum of six months and may be
  27. updated, replaced, or obsoleted by other documents at any time.  It is
  28. inappropriate to use Internet Drafts as reference material or to cite
  29. them other than as a "work in progress".
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Expires July 1997                                               [Page 1]
  59.  
  60.  
  61.  
  62.  
  63. DRAFT                  RIP-II MD5 Authentication            January 1997
  64.  
  65.  
  66. 1.  Use of Imperatives
  67.  
  68. Throughout this document, the words that are used to define the
  69. significance of particular requirements are capitalized.  These words
  70. are:
  71.  
  72.  
  73. MUST
  74.  
  75.      This word or the adjective "REQUIRED" means that the item is an
  76.      absolute requirement of this specification.
  77.  
  78. MUST NOT
  79.  
  80.      This phrase means that the item is an absolute prohibition of this
  81.      specification.
  82.  
  83. SHOULD
  84.  
  85.      This word or the adjective "RECOMMENDED" means that there may exist
  86.      valid reasons in particular circumstances to ignore this item, but
  87.      the full implications should be understood and the case carefully
  88.      weighed before choosing a different course.
  89.  
  90. SHOULD NOT
  91.  
  92.      This phrase means that there may exist valid reasons in particular
  93.      circumstances when the listed behavior is acceptable or even
  94.      useful, but the full implications should be understood and the case
  95.      carefully weighed before implementing any behavior described with
  96.      this label.
  97.  
  98. MAY   This word or the adjective "OPTIONAL" means that this item is
  99.      truly optional.  One vendor may choose to include the item because
  100.      a particular marketplace requires it or because it enhances the
  101.      product, for example; another vendor may omit the same item.
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116. Expires July 1997                                               [Page 2]
  117.  
  118.  
  119.  
  120.  
  121. DRAFT                  RIP-II MD5 Authentication            January 1997
  122.  
  123.  
  124. 2.  Introduction
  125.  
  126. Growth in the Internet has made us aware of the need for improved
  127. authentication of routing information.  RIP-II provides for
  128. unauthenticated service (as in classical RIP), or password
  129. authentication.  Both are vulnerable to passive attacks currently
  130. widespread in the Internet.  Well-understood security issues exist in
  131. routing protocols [4].  Clear text passwords, currently specified for
  132. use with RIP-II, are no longer considered sufficient [5].
  133.  
  134. If authentication is disabled, then only simple misconfigurations are
  135. detected.  Simple passwords transmitted in the clear will further
  136. protect against the honest neighbor, but are useless in the general
  137. case.  By simply capturing information on the wire - straightforward
  138. even in a remote environment - a hostile process can learn the password
  139. and overcome the network.
  140.  
  141. We propose that RIP-II use an authentication algorithm, as was
  142. originally proposed for SNMP Version 2, augmented by a sequence number.
  143. Keyed MD5 is proposed as the standard authentication algorithm for RIP-
  144. II, but the mechanism is intended to be algorithm-independent.  While
  145. this mechanism is not unbreakable (no known mechanism is), it provides a
  146. greatly enhanced probability that a system being attacked will detect
  147. and ignore hostile messages.  This is because we transmit the output of
  148. an authentication algorithm (e.g., Keyed MD5) rather than the secret
  149. RIP-II Authentication Key.  This output is a one-way function of a
  150. message and a secret RIP-II Authentication Key.  This RIP-II
  151. Authentication Key is never sent over the network in the clear, thus
  152. providing protection against the passive attacks now commonplace in the
  153. Internet.
  154.  
  155. In this way, protection is afforded against forgery or message
  156. modification.  It is possible to replay a message until the sequence
  157. number changes, but the sequence number makes replay in the long term
  158. less of an issue.  The mechanism does not afford confidentiality, since
  159. messages stay in the clear; however, the mechanism is also exportable
  160. from most countries, which test a privacy algorithm would fail.
  161.  
  162. Other relevant rationales for the approach are that Keyed MD5 is being
  163. used for OSPF cryptographic authentication, and is therefore present in
  164. routers already, as is some form of password management.  A similar
  165. approach has been standardized for use in IP-layer authentication. [7]
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174. Expires July 1997                                               [Page 3]
  175.  
  176.  
  177.  
  178.  
  179. DRAFT                  RIP-II MD5 Authentication            January 1997
  180.  
  181.  
  182. 3.  Implementation Approach
  183.  
  184. Implementation requires three issues to be addressed:
  185.  
  186. (1)  A changed packet format,
  187.  
  188. (2)  Authentication procedures, and
  189.  
  190. (3)  Management controls.
  191.  
  192. 3.1.  RIP-II PDU Format
  193.  
  194. The basic RIP-II message format provides for an 8 byte header with an
  195. array of 20 byte records as its data content.  When Keyed MD5 is used,
  196. the same header and content are used, except that the 16 byte
  197. "authentication key" field is reused to describe a "Keyed Message
  198. Digest" trailer.  This consists in five fields:
  199.  
  200. (1)  The "Authentication Type" is Keyed Message Digest Algorithm,
  201.      indicated by the value 3 (1 and 2 indicate "IP Route" and
  202.      "Password", respectively).
  203.  
  204. (2)  A 16 bit offset from the RIP-II header to the MD5 digest (if no
  205.      other trailer fields are ever defined, this value equals the RIP-II
  206.      Data Length).
  207.  
  208. (3)  An unsigned 8-bit field that contains the Key Identifier or Key-ID.
  209.      This identifies the key used to create the Authentication Data for
  210.      this RIP-II message.  In implementations supporting more than one
  211.      authentication algorithm, the Key-ID also indicates the
  212.      authentication algorithm in use for this message. A key is
  213.      associated with an interface.
  214.  
  215. (4)  An unsigned 8-bit field that contains the length in octets of the
  216.      trailing Authentication Data field.  The presence of this field
  217.      permits other algorithms (e.g., Keyed SHA) to be substituted for
  218.      Keyed MD5 if desired.
  219.  
  220. (5)  An unsigned 32 bit sequence number.  The sequence number MUST be
  221.      non-decreasing for all messages sent with the same Key ID.
  222.  
  223. The trailer consists of the Authentication Data, which is the output of
  224. the Keyed Message Digest Algorithm.  When the Authentication Algorithm
  225. is Keyed MD5, the output data is 16 bytes; during digest calculation,
  226. this is effectively followed by a pad field and a length field as
  227.  
  228.  
  229.  
  230.  
  231.  
  232. Expires July 1997                                               [Page 4]
  233.  
  234.  
  235.  
  236.  
  237. DRAFT                  RIP-II MD5 Authentication            January 1997
  238.  
  239.  
  240. defined by RFC 1321.
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290. Expires July 1997                                               [Page 5]
  291.  
  292.  
  293.  
  294.  
  295. DRAFT                  RIP-II MD5 Authentication            January 1997
  296.  
  297.  
  298. 3.2.  Processing Algorithm
  299.  
  300. When the authentication type is "Keyed Message Digest", message
  301. processing is changed in message creation and reception.
  302.     0                   1                   2                   3 3
  303.     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
  304. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  305. | Command (1)   | Version (1)   |       Routing Domain (2)      |
  306. +---------------+---------------+-------------------------------+
  307. |             0xFFFF            | AuType=Keyed Message Digest   |
  308. +-------------------------------+-------------------------------+
  309. |    RIP-II Packet Length       |    Key ID    | Auth Data Len  |
  310. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  311. |               Sequence Number (non-decreasing)                |
  312. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  313. |               reserved must be zero                           |
  314. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  315. |               reserved must be zero                           |
  316. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  317. |                                                               |
  318. /    (RIP-II Packet Length - 24) bytes of Data                  /
  319. |                                                               |
  320. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  321. |             0xFFFF            |       0x01                    |
  322. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  323. /  Authentication Data (var. length; 16 bytes with Keyed MD5)   /
  324. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  325.  
  326.  
  327. In memory, the following trailer is appended by the MD5 algorithm and
  328. treated as though it were part of the message.
  329.  
  330. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  331. |              sixteen octets of MD5 "secret"                   |
  332. /                                                               /
  333. |                                                               |
  334. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  335. | zero or more pad bytes (defined by RFC 1321 when MD5 is used) |
  336. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  337. |                        64 bit message length MSW              |
  338. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  339. |                        64 bit message length LSW              |
  340. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348. Expires July 1997                                               [Page 6]
  349.  
  350.  
  351.  
  352.  
  353. DRAFT                  RIP-II MD5 Authentication            January 1997
  354.  
  355.  
  356. 3.2.1.  Message Generation
  357.  
  358. The RIP-II Packet is created as usual, with these exceptions:
  359.  
  360. (1)  The UDP checksum need not be calculated, but MAY be set to zero.
  361.  
  362. (2)  The authentication type field indicates the Keyed Message Digest
  363.      Algorithm (3).
  364.  
  365. (3)  The authentication "password" field is reused to store a packet
  366.      offset to the Authentication Data, a Key Identifier, the
  367.      Authentication Data Length, and a non-decreasing sequence number.
  368.  
  369. The value used in the sequence number is arbitrary, but two suggestions
  370. are the time of the message's creation or a simple message counter.
  371.  
  372. The RIP-II Authentication Key is selected by the sender based on the
  373. outgoing interface. Each key has a lifetime associated with it.  No key
  374. is ever used outside its lifetime.  Since the key's algorithm is related
  375. to the key itself, stored in the sender and receiver along with it, the
  376. Key ID effectively indicates which authentication algorithm is in use if
  377. the implementation supports more than one authentication algorithm.
  378.  
  379. (1)  The RIP-II header's packet length field indicates the standard
  380.      RIP-II portion of the packet.
  381.  
  382. (2)  The Authentication Data Offset, Key Identifier, and Authentication
  383.      Data size fields are filled in appropriately.
  384.  
  385. (3)  The RIP-II Authentication Key, which is 16 bytes long when the
  386.      Keyed MD5 algorithm is used, is now appended to the data.  For all
  387.      algorithms, the RIP-II Authentication Key is never longer than the
  388.      output of the algorithm in use.
  389.  
  390. (4)  Trailing pad and length fields are added and the digest calculated
  391.      using the indicated algorithm. When Keyed MD5 is the algorithm in
  392.      use, these are calculated per RFC 1321.
  393.  
  394. (5)  The digest is written over the RIP-II Authentication Key.  When MD5
  395.      is used, this digest will be 16 bytes long.
  396.  
  397. The trailing pad is not actually transmitted, as it is entirely
  398. predictable from the message length and algorithm in use.
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406. Expires July 1997                                               [Page 7]
  407.  
  408.  
  409.  
  410.  
  411. DRAFT                  RIP-II MD5 Authentication            January 1997
  412.  
  413.  
  414. 3.2.2.  Message Reception
  415.  
  416. When the message is received, the process is reversed:
  417.  
  418. (1)  The digest is set aside,
  419.  
  420. (2)  The appropriate algorithm and key are determined from the value of
  421.      the Key Identifier field,
  422.  
  423. (3)  The RIP-II Authentication Key is written into the appropriate
  424.      number (16 when Keyed MD5 is used) of bytes starting at the offset
  425.      indicated,
  426.  
  427. (4)  Appropriate padding is added as needed, and
  428.  
  429. (5)  A new digest calculated using the indicated algorithm.
  430.  
  431. If the calculated digest does not match the received digest, the message
  432. is discarded unprocessed.  If the neighbor has been heard from recently
  433. enough to have viable routes in the route table and the received
  434. sequence number is less than the last one received, the message likewise
  435. is discarded unprocessed.  When connectivity to the neighbor has been
  436. lost, the receiver SHOULD be ready to accept either:
  437. - a message with a new key, or
  438. - a message with the same or higher sequence number than the last
  439.   received sequence number.
  440.  
  441. A router that has forgotten its current sequence number but is forced to
  442. use the same key and Key-ID MUST represents a troubling end case.  If
  443. the router has no stable storage through which it can preserve the
  444. sequence number across a failure, re-use of the key represents a
  445. potential security flaw.  Router vendors are encouraged to provide
  446. stable storage for keys, key lifetimes, Key-IDs, and the related
  447. sequence numbers.
  448.  
  449. Acceptable messages are now truncated to RIP-II message itself and
  450. treated normally.
  451.  
  452. 4.  Management Procedures
  453.  
  454. 4.1.  Key Management Requirements
  455.  
  456. It is strongly desirable that a hypothetical security breach in one
  457. Internet protocol not automatically compromise other Internet protocols.
  458. The Authentication Key of this specification SHOULD NOT be stored using
  459.  
  460.  
  461.  
  462.  
  463.  
  464. Expires July 1997                                               [Page 8]
  465.  
  466.  
  467.  
  468.  
  469. DRAFT                  RIP-II MD5 Authentication            January 1997
  470.  
  471.  
  472. protocols or algorithms that have known flaws.
  473.  
  474. Implementations MUST support the storage of more than one key at the
  475. same time, although it is recognized that only one key will normally be
  476. active on an interface. They MUST associate a specific lifetime (i.e.,
  477. date/time first valid and date/time no longer valid) and a key
  478. identifier with each key, and MUST support manual key distribution
  479. (e.g., the privileged user manually typing in the key, key lifetime, and
  480. key identifier on the router console).  The lifetime may be infinite.
  481. If more than one algorithm is supported, then the implementation MUST
  482. require that the algorithm be specified for each key at the time the
  483. other key information is entered. Keys that are out of date MAY be
  484. deleted at will by the implementation without requiring human
  485. intervention.  Manual deletion of active keys SHOULD also be supported.
  486.  
  487. It is likely that the IETF will define a standard key management
  488. protocol.  It is strongly desirable to use that key management protocol
  489. to distribute RIP-II Authentication Keys among communicating RIP-II
  490. implementations.  Such a protocol would provide scalability and
  491. significantly reduce the human administrative burden. The Key ID can be
  492. used as a hook between RIP-II and such a future protocol.  Key
  493. management protocols have a long history of subtle flaws that are often
  494. discovered long after the protocol was first described in public.  To
  495. avoid having to change all RIP-II implementations should such a flaw be
  496. discovered, integrated key management protocol techniques were
  497. deliberately omitted from this specification.
  498.  
  499. 4.2.  Key Management Procedures
  500.  
  501. As with all security methods using keys, it is necessary to change the
  502. RIP-II Authentication Key on a regular basis.  To maintain routing
  503. stability during such changes, implementations MUST be able to store and
  504. use more than one RIP-II Authentication Key on a given interface at the
  505. same time.
  506.  
  507. Each key will have its own Key Identifier, which is stored locally.  The
  508. combination of the Key Identifier and the interface associated with the
  509. message uniquely identifies the Authentication Algorithm and RIP-II
  510. Authentication Key in use.
  511.  
  512. As noted above in Section 2.2.1, the party creating the RIP-II message
  513. will select a valid key from the set of valid keys for that interface.
  514. The receiver will use the Key Identifier and interface to determine
  515. which key to use for authentication of the received message.  More than
  516. one key may be associated with an interface at the same time.
  517.  
  518.  
  519.  
  520.  
  521.  
  522. Expires July 1997                                               [Page 9]
  523.  
  524.  
  525.  
  526.  
  527. DRAFT                  RIP-II MD5 Authentication            January 1997
  528.  
  529.  
  530. Hence it is possible to have fairly smooth RIP-II Authentication Key
  531. rollovers without losing legitimate RIP-II messages because the stored
  532. key is incorrect and without requiring people to change all the keys at
  533. once.  To ensure a smooth rollover, each communicating RIP-II system
  534. must be updated with the new key several minutes before the current key
  535. will expire and several minutes before the new key lifetime begins. The
  536. new key should have a lifetime that starts several minutes before the
  537. old key expires. This gives time for each system to learn of the new
  538. RIP-II Authentication Key before that key will be used.  It also ensures
  539. that the new key will begin being used and the current key will go out
  540. of use before the current key's lifetime expires.  For the duration of
  541. the overlap in key lifetimes, a system may receive messages using either
  542. key and authenticate the message. The Key-ID in the received message is
  543. used to select the appropriate key for authentication.
  544.  
  545. 4.3.  Pathological Cases
  546.  
  547. Two pathological cases exist which must be handled, which are failures
  548. of the network manager.  Both of these should be exceedingly rare.
  549.  
  550. During key switchover, devices may exist which have not yet been
  551. successfully configured with the new key. Therefore, routers SHOULD
  552. implement (and would be well advised to implement) an algorithm that
  553. detects the set of keys being used by its neighbors, and transmits its
  554. messages using both the new and old keys until all of the neighbors are
  555. using the new key or the lifetime of the old key expires.  Under normal
  556. circumstances, this elevated transmission rate will exist for a single
  557. update interval.
  558.  
  559. In the event that the last key associated with an interface expires, it
  560. is unacceptable to revert to an unauthenticated condition, and not
  561. advisable to disrupt routing.  Therefore, the router should send a "last
  562. authentication key expiration" notification to the network manager and
  563. treat the key as having an infinite lifetime until the lifetime is
  564. extended, the key is deleted by network management, or a new key is
  565. configured.
  566.  
  567. 5.  Conformance Requirements
  568.  
  569. To conform to this specification, an implementation MUST support all of
  570. its aspects.  The Keyed MD5 authentication algorithm MUST be implemented
  571. by all conforming implementations. MD5 is defined in RFC-1321.  A
  572. conforming implementation MAY also support other authentication
  573. algorithms such as Keyed Secure Hash Algorithm (SHA).  Manual key
  574. distribution as described above MUST be supported by all conforming
  575.  
  576.  
  577.  
  578.  
  579.  
  580. Expires July 1997                                              [Page 10]
  581.  
  582.  
  583.  
  584.  
  585. DRAFT                  RIP-II MD5 Authentication            January 1997
  586.  
  587.  
  588. implementations. All implementations MUST support the smooth key
  589. rollover described under "Key Change Procedures."
  590.  
  591. The user documentation provided with the implementation MUST contain
  592. clear instructions on how to ensure that smooth key rollover occurs.
  593.  
  594. Implementations SHOULD support a standard key management protocol for
  595. secure distribution of RIP-II Authentication Keys once such a key
  596. management protocol is standardized by the IETF.
  597.  
  598.  
  599. 6.  Acknowledgments
  600.  
  601. This work was done by the RIP-II Working Group, of which Gary Malkin is
  602. the Chair.  This suggestion was originally made by Christian Huitema on
  603. behalf of the IAB.  Jeff Honig (Cornell) and Dennis Ferguson (ANS) built
  604. the first operational prototype, proving out the algorithms.  The
  605. authors gladly acknowledge significant inputs from each of these
  606. sources.
  607.  
  608.  
  609. 7.  References
  610.  
  611. [1]  Malkin, Gary, "RIP Version 2 Carrying Additional Information", RFC
  612.      1388, January 1993.
  613.  
  614. [2]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
  615.      1992.
  616.  
  617. [3]  Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC 1389,
  618.      Xylogics, Inc., Advanced Computer Communications, January 1993.
  619.  
  620. [4]  S.  Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM
  621.      Computer Communications Review, Volume 19, Number 2, pp.32-48,
  622.      April 1989.
  623.  
  624. [5]  N.  Haller, R.  Atkinson, "Internet Authentication Guidelines",
  625.      RFC-1704, October 1994.
  626.  
  627. [6]  R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of IAB
  628.      Workshop on Security in the Internet Architecture", RFC-1636, June
  629.      1994.
  630.  
  631. [7]  R. Atkinson, "IP Authentication Header", RFC-1826, August 1995.
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638. Expires July 1997                                              [Page 11]
  639.  
  640.  
  641.  
  642.  
  643. DRAFT                  RIP-II MD5 Authentication            January 1997
  644.  
  645.  
  646. [8]  R. Atkinson, "IP Encapsulating Security Payload", RFC-1827, August
  647.      1995.
  648.  
  649.  
  650. 8.  Security Considerations
  651.  
  652. This entire memo describes and specifies an authentication mechanism for
  653. the RIP-II routing protocol that is believed to be secure against active
  654. and passive attacks. Passive attacks are clearly widespread in the
  655. Internet at present.  Protection against active attacks is also needed
  656. because active attacks are becoming more common.
  657.  
  658. Users need to understand that the quality of the security provided by
  659. this mechanism depends completely on the strength of the implemented
  660. authentication algorithms, the strength of the key being used, and the
  661. correct implementation of the security mechanism in all communicating
  662. RIP-II implementations. This mechanism also depends on the RIP-II
  663. Authentication Key being kept confidential by all parties. If any of
  664. these incorrect or insufficiently secure, then no real security will be
  665. provided to the users of this mechanism.
  666.  
  667. Specifically with respect to the use of SNMP, compromise of SNMP
  668. security has the necessary result that the various RIP-II configuration
  669. parameters (e.g. routing table, RIP-II Authentication Key) manageable
  670. via SNMP could be compromised as well.  Changing Authentication Keys
  671. using non-encrypted SNMP is no more secure than sending passwords in the
  672. clear.
  673.  
  674. Confidentiality is not provided by this mechanism.  Recent work in the
  675. IETF provides a standard mechanism for IP-layer encryption. [8]  That
  676. mechanism might be used to provide confidentiality for RIP-II in the
  677. future.  Protection against traffic analysis is also not provided.
  678. Mechanisms such as bulk link encryption might be used when protection
  679. against traffic analysis is required.
  680.  
  681. The memo is written to address a security consideration in RIP-II
  682. Version 2 that was raised during the IAB's recent security review [6].
  683.  
  684. 9.  Chairman's Address
  685.  
  686.      Gary Scott Malkin
  687.      Xylogics, Inc.
  688.      53 Third Avenue
  689.      Burlington, MA 01803
  690. Phone:  (617) 272-8140
  691.  
  692.  
  693.  
  694.  
  695.  
  696. Expires July 1997                                              [Page 12]
  697.  
  698.  
  699.  
  700.  
  701. DRAFT                  RIP-II MD5 Authentication            January 1997
  702.  
  703.  
  704. EMail:  gmalkin@Xylogics.COM
  705.  
  706. 10.  Authors' Addresses
  707.  
  708.      Fred Baker
  709.      Cisco Systems
  710.      519 Lado Drive
  711.      Santa Barbara, California 93111
  712. Phone: (805) 681 0115
  713. Email: fred@cisco.com
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742.  
  743.  
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754. Expires July 1997                                              [Page 13]
  755.  
  756.  
  757.  
  758.  
  759. DRAFT                  RIP-II MD5 Authentication            January 1997
  760.  
  761.  
  762. Table of Contents
  763.  
  764.  
  765. 1 Use of Imperatives ..............................................    2
  766. 2 Introduction ....................................................    3
  767. 3 Implementation Approach .........................................    4
  768. 3.1 RIP-II PDU Format .............................................    4
  769. 3.2 Processing Algorithm ..........................................    6
  770. 3.2.1 Message Generation ..........................................    7
  771. 3.2.2 Message Reception ...........................................    8
  772. 4 Management Procedures ...........................................    8
  773. 4.1 Key Management Requirements ...................................    8
  774. 4.2 Key Management Procedures .....................................    9
  775. 4.3 Pathological Cases ............................................   10
  776. 5 Conformance Requirements ........................................   10
  777. 6 Acknowledgments .................................................   11
  778. 7 References ......................................................   11
  779. 8 Security Considerations .........................................   12
  780. 9 Chairman's Address ..............................................   12
  781. 10 Authors' Addresses .............................................   13
  782.  
  783.  
  784.  
  785.  
  786.  
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797.  
  798.  
  799.  
  800.  
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811.  
  812. Expires July 1997                                              [Page 14]
  813.