rfc2082.txt

RFC 的详细文档！

Network Working Group                                          F. Baker
Request for Comments: 2082                                  R. Atkinson
Category: Standards Track                                 Cisco Systems
                                                           January 1997


                        RIP-2 MD5 Authentication

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Table of Contents

   1 Use of Imperatives ...........................................    1
   2 Introduction .................................................    2
   3 Implementation Approach ......................................    3
   3.1 RIP-2 PDU Format ...........................................    3
   3.2 Processing Algorithm .......................................    5
   3.2.1 Message Generation .......................................    6
   3.2.2 Message Reception ........................................    7
   4 Management Procedures ........................................    7
   4.1 Key Management Requirements ................................    7
   4.2 Key Management Procedures ..................................    8
   4.3 Pathological Cases .........................................    9
   5 Conformance Requirements .....................................    9
   6 Acknowledgments ..............................................   10
   7 References ...................................................   10
   8 Security Considerations ......................................   11
   9 Chairman's Address ...........................................   11
   10 Authors' Addresses ..........................................   12

1.  Use of Imperatives

   Throughout this document, the words that are used to define the
   significance of particular requirements are capitalized.  These words
   are:

   MUST

      This word or the adjective "REQUIRED" means that the item is an
      absolute requirement of this specification.





Baker & Atkinson            Standards Track                     [Page 1]

RFC 2082                RIP-2 MD5 Authentication            January 1997


   MUST NOT

      This phrase means that the item is an absolute prohibition of this
      specification.

   SHOULD

      This word or the adjective "RECOMMENDED" means that there may
      exist valid reasons in particular circumstances to ignore this
      item, but the full implications should be understood and the case
      carefully weighed before choosing a different course.

   SHOULD NOT

      This phrase means that there may exist valid reasons in particular
      circumstances when the listed behavior is acceptable or even
      useful, but the full implications should be understood and the
      case carefully weighed before implementing any behavior described
      with this label.

   MAY
      This word or the adjective "OPTIONAL" means that this item is
      truly optional.  One vendor may choose to include the item because
      a particular marketplace requires it or because it enhances the
      product, for example; another vendor may omit the same item.

2.  Introduction

   Growth in the Internet has made us aware of the need for improved
   authentication of routing information.  RIP-2 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 [4].  Clear text passwords, currently specified for
   use with RIP-2, are no longer considered sufficient [5].

   If authentication is disabled, then only simple misconfigurations are
   detected.  Simple passwords transmitted in the clear will further
   protect against the honest neighbor, 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.

   We propose that RIP-2 use an authentication algorithm, as was
   originally proposed for SNMP Version 2, augmented by a sequence
   number.  Keyed MD5 is proposed as the standard authentication
   algorithm for RIP-2, but the mechanism is intended to be algorithm-
   independent.  While this mechanism is not unbreakable (no known



Baker & Atkinson            Standards Track                     [Page 2]

RFC 2082                RIP-2 MD5 Authentication            January 1997


   mechanism is), it provides a greatly enhanced probability that a
   system being attacked will detect and ignore hostile messages.  This
   is because we transmit the output of an authentication algorithm
   (e.g., Keyed MD5) rather than the secret RIP-2 Authentication Key.
   This output is a one-way function of a message and a secret RIP-2
   Authentication Key.  This RIP-2 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.

   Other relevant rationales for the approach are that Keyed MD5 is
   being used for OSPF cryptographic authentication, and is therefore
   present in routers already, as is some form of password management.
   A similar approach has been standardized for use in IP-layer
   authentication. [7]

3.  Implementation Approach

   Implementation requires three issues to be addressed:

   (1)  A changed packet format,

   (2)  Authentication procedures, and

   (3)  Management controls.

3.1.  RIP-2 PDU Format

   The basic RIP-2 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 "Keyed Message
   Digest" trailer.  This consists in five fields:

   (1)  The "Authentication Type" is Keyed Message Digest Algorithm,
        indicated by the value 3 (1 and 2 indicate "IP Route" and
        "Password", respectively).

   (2)  A 16 bit offset from the RIP-2 header to the MD5 digest (if no
        other trailer fields are ever defined, this value equals the
        RIP-2 Data Length).



Baker & Atkinson            Standards Track                     [Page 3]

RFC 2082                RIP-2 MD5 Authentication            January 1997


   (3)  An unsigned 8-bit field that contains the Key Identifier
        or Key-ID. This identifies the key used to create the
        Authentication Data for this RIP-2 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 associated with
        an interface.

   (4)  An unsigned 8-bit field that contains the length in octets of the
        trailing Authentication Data field.  The presence of this field
        permits other algorithms (e.g., Keyed SHA) to be substituted for
        Keyed MD5 if desired.

   (5)  An unsigned 32 bit sequence number.  The sequence number MUST be
        non-decreasing for all messages sent with the same Key ID.

   The trailer consists of the Authentication Data, which is the output
   of the Keyed Message Digest Algorithm.  When the Authentication
   Algorithm is Keyed MD5, the output data is 16 bytes; during digest
   calculation, this is effectively followed by a pad field and a length
   field as defined by RFC 1321.






























Baker & Atkinson            Standards Track                     [Page 4]

RFC 2082                RIP-2 MD5 Authentication            January 1997


3.2.  Processing Algorithm

   When the authentication type is "Keyed Message Digest", 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   |
   +-------------------------------+-------------------------------+
   |    RIP-2 Packet Length        |    Key ID    | Auth Data Len  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Sequence Number (non-decreasing)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               reserved must be zero                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               reserved must be zero                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /    (RIP-2 Packet Length - 24) bytes of Data                   /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             0xFFFF            |       0x01                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /  Authentication Data (var. length; 16 bytes with Keyed MD5)   /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In memory, the following trailer is appended by the MD5 algorithm and
   treated as though it were part of the message.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              sixteen octets of MD5 "secret"                   |
   /                                                               /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | zero or more pad bytes (defined by RFC 1321 when MD5 is used) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        64 bit message length MSW              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        64 bit message length LSW              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+








Baker & Atkinson            Standards Track                     [Page 5]

RFC 2082                RIP-2 MD5 Authentication            January 1997


3.2.1.  Message Generation

   The RIP-2 Packet is created as usual, with these exceptions:

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

   (2) The authentication type field indicates the Keyed Message Digest
       Algorithm (3).

   (3) The authentication "password" field is reused to store a packet
       offset to the Authentication Data, a Key Identifier, the
       Authentication Data Length, and a non-decreasing sequence number.

   The value used in the sequence number is arbitrary, but two
   suggestions are the time of the message's creation or a simple
   message counter.

   The RIP-2 Authentication Key is selected by the sender based on the
   outgoing interface. Each key has a lifetime associated with it.  No
   key is ever used outside its lifetime.  Since the key's algorithm is
   related to the key itself, stored in the sender and receiver along
   with it, the Key ID effectively indicates which authentication
   algorithm is in use if the implementation supports more than one
   authentication algorithm.

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

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

   (3)  The RIP-2 Authentication Key, which is 16 bytes long when the
        Keyed MD5 algorithm is used, is now appended to the data.  For
        all algorithms, the RIP-2 Authentication Key is never longer than
        the output of the algorithm in use.

   (4)  Trailing pad and length fields are added and the digest
        calculated using the indicated algorithm. When Keyed MD5 is the
        algorithm in use, these are calculated per RFC 1321.

   (5)  The digest is written over the RIP-2 Authentication Key.  When
        MD5 is used, this digest will be 16 bytes long.

   The trailing pad is not actually transmitted, as it is entirely
   predictable from the message length and algorithm in use.





Baker & Atkinson            Standards Track                     [Page 6]