3

When we configure OSPF routers with MD5 authentication, a message digest is created, which is the combination of a pre-defined message-digest-key which has been run through the MD5 algorithm; that must be the same between routers of an area, for example:

  • message-digest-key = cisco
  • md5("cisco") = "dfeaf10390e560aea745ccba53e044ed"

My Question

  • What part of the packet is checksummed by this MD5 hash?
  • Does OSPF check the whole packet? or what exactly?

Please include your references.

5

From the RFC:

            (c) The MD5 authentication algorithm is run over the
                concatenation of the OSPF packet, secret key, pad
                and length fields, producing a 16 byte message
                digest (see [Ref17]).
  • my dear friend I've seen that part,but could not understand it,could you please explain that in plain English? – Mjaryan May 19 '14 at 16:49
  • What part do you not understand? The OSPF packet, the secret key, pad, and length fields are concatenated, then the MD5 auth algorithm is ran over the concatenated result (see ref17 link in the rfc for details). – mulaz May 19 '14 at 16:56
  • Before posting my question I've just checked RFC and read that part MD5 is run over a concatenation of the OSPF packet and shared secret key, MD5 hash then appended to OSPF packet; encapsulated in IP datagram.what are the concatenation of the OSPF packet?? is this part of RFC saying that OSPF runs MD5 on which fields of OSPF header? I can't see mentioned fields in OSPF header,just length field is there??!! Im confused could u please explain that in plain English? – Mjaryan May 19 '14 at 17:03
  • here link section A.3.1 The OSPF packet header is describing OSPF standard header,just packet length from mentioned fields is there. – Mjaryan May 19 '14 at 17:12
  • 1
    OSPF packet (just the OSPF part) is concatenated with the key, pad and length (of the ospf part). Then the MD5 hash is calculated, and appended to the OSPF packet. OSPF length stays the same, but IP packet length is larger because of the hash. – mulaz May 19 '14 at 18:25
2

With many thanks to my Dear friend Kev Santillan form Cisco learning network

here's OSPF standard header

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version #   |     Type      |         Packet length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Router ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Area ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |             AuType            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Authentication                          |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Authentication                          |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

as described in RFC RFC2328 Section A.3.1

And Here is the modified packet using MD5 from RFC2328 Section 2.2

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Version #   |     type      |        Packet Length          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Router ID                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           Area ID                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Reserved - Must be Zero     | AuType=Keyed Message Digest Fn|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 |   Reserved - Must be Zero     |    Key ID    | Auth Data Len  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |               Sequence Number (non-decreasing)                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 /           (OSPF Data Length-24) bytes Data                    /
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 / Authentication Data  (var. length; 16 bytes when MD5 is used) /
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

As shown, the Checksum is set to zero and the Authentication Type field is set to keyed message digest (Type 2). The 64-bit Authentication field was redefined into three parts namely: Key ID, Auth Data Len and the cryptographic Seq Number fields.The appended trailer which consists of the Authentication Data is the output of the message digest algorithm.

0

The part which is checksumed is the OSPF part of the packet and the key padded with zeros to make it 16 byte long. In wireshark the ospf part is the data which is part of OSPF Header and ospf Hello packet, except the Auth crypt data which is the actual md5 hash.

MD5[ospf packet + (key+padding)] = checksum. This checksum should match one in the Auth crypt data of ospf packet for sucessfull authentication.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.