Internet Draft OSPF HMAC-SHA Cryptographic Authentication  October 2008


   Network Working Group                                   Manav Bhatia
   Internet Draft                                        Alcatel-Lucent
   Expires: March 2009                                   Vishwas Manral
                                                            IP Infusion
                                                             Russ White
                                                         Michael Barnes
                                                          Cisco Systems

                OSPF HMAC-SHA Cryptographic Authentication

                      draft-ietf-ospf-hmac-sha-03.txt

Status of this Memo

   Distribution of this memo is unlimited.

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 as "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.

Abstract

   This document describes a mechanism for authenticating OSPF packets
   by making use of the HMAC algorithm in conjunction with the SHA
   family of cryptographic hash functions. Because of the way the hash
   functions are used in HMAC construction, the collision attacks
   currently known against SHA-1 do not apply.

   This will be done in addition to the already documented
   authentication schemes described in the base specification.

Conventions used in this document



Bhatia, Manral, et. al.                                        [Page 1]


Internet Draft OSPF HMAC-SHA Cryptographic Authentication  October 2008


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119. [RFC2119]

Table of Contents

   1. Introduction...................................................2
   2. Standard OSPF Authentication...................................3
   3. OSPF Security Association......................................5
   4. Using New Algorithms for OSPF Authentication...................5
   5. Authentication Procedures......................................6
      5.1 Message Generation at the Sending Side.....................6
      5.2 Message Verification at the Receiving Side.................6
   6. Algorithm Dependent Processing.................................7
   7. Security Considerations........................................8
   8. Backwards Compatibility Considerations.........................8
   9. IANA Considerations............................................8
   10. Acknowledgements..............................................8
   11. References....................................................8
      11.1 Normative References......................................8
      11.2 Informative References....................................9
   12. Author's Addresses............................................9

1. Introduction

   OSPF as defined in [RFC2328] includes three different types of
   authentication schemes: Null authentication, simple password and
   cryptographic authentication. NULL authentication is akin to having
   no authentication at all. In the simple password scheme of
   authentication, the passwords are exchanged in the clear text on the
   network and anyone with physical access to the network can learn the
   password and compromise the security of the OSPF domain.

   In the cryptographic authentication scheme, the OSPF routers on a
   common network/subnet share a secret key which is used to generate a
   keyed MD5 digest for each packet and a monotonically increasing
   sequence number scheme is used to prevent replay attacks.

   This isnt good enough as there have been recent reports about attacks
   on MD5 which raises concerns about the remaining useful lifetime of
   this scheme. Specifically, the researchers have been able to develop
   algorithms that can compute hash collisions for some applications of
   MD5 [MD5-attack].

   It was discovered that collisions can be found in MD5 algorithm in
   less than 24 hours, making MD5 insecure. Further research has
   verified this result and shown other ways to find collisions in MD5
   hashes.



Bhatia, Manral, et. al.                                        [Page 2]


Internet Draft OSPF HMAC-SHA Cryptographic Authentication  October 2008


   It should however be noted that these attacks may not necessarily
   result in direct vulnerabilities in Keyed-MD5 as used in OSPF
   authentication purposes, because the colliding message may not
   necessarily be a syntactically correct protocol packet. However,
   there is a need felt to move away from MD5 towards more complex and
   difficult to break hash algorithms.

   This document therefore adds support for HMAC [RFC2104] construction
   to be used for authenticating OSPF packets. HMAC can be used, without
   modifying any hash function, for calculating and verifying the
   message authentication values. It verifies both the data integrity
   and the authenticity of a message. Because of the way the hash
   functions are used in HMAC construction, the collision attacks
   currently known against MD5 and SHA-1 do not apply.

   By definition, HMAC requires a cryptographic hash function. We
   propose to use any one of SHA-1, SHA-256, SHA-384 and    SHA-512
   [NIST] for this purpose to authenticate the OSPF packets.

   This document explains how HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 and
   HMAC-SHA-512 shall work with OSPF.

2. Standard OSPF Authentication

   Figure 1 shows the standard 24 byte OSPF header as specified in
   [RFC2328]. The header includes an authentication type field (AuType)
   that identifies the authentication procedure to be used for the
   packet. Authentication is a 64 bit field of data to be used by the
   appropriate authentication scheme (determined by the type field).

   Authentication types 0, 1 and 2 are defined by [RFC2328] to be used
   for Null Authentication, Simple Password and Cryptographic
   authentication.


















Bhatia, Manral, et. al.                                        [Page 3]


Internet Draft OSPF HMAC-SHA Cryptographic Authentication  October 2008


    0                   1                   2                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version #   |     Type      |         Packet length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Router ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Area ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |             AuType            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Authentication                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Authentication                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                              Figure 1


    0                   1                   2                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              0                |    Key ID     | Auth Data Len |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Cryptographic sequence number                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             Figure 2

   Figure 2 shows the way the authentication data MUST be filled in the
   OSPF header if the AuType is set to 2. The first 16 bits are set
   reserved to zero.

   Cryptographic authentication as specified in [RFC2328] allows for
   algorithms other than MD5 to be used without altering the protocol
   packets. Note the original definition of the Key ID field:

     This field identifies the algorithm and secret key used to create
     the message digest appended to the OSPF packet. Key Identifiers are
     unique per-interface (or equivalently, per-subnet).

   Also note step (6) in section D.4.3 "The authentication algorithm to
   be used in calculating the digest is indicated by the key itself."

   It is clear that the fields defined in section D.3 of [RFC2328] are
   adequate for the use of cryptographic algorithms other than MD5. The
   only actual difference in the OSPF protocol packets is that the HMAC
   is appended to the original OSPF packet instead of the MD5 digest.



Bhatia, Manral, et. al.                                        [Page 4]


Internet Draft OSPF HMAC-SHA Cryptographic Authentication  October 2008


3. OSPF Security Association

   This document defines an OSPF Security Association (SA) as a set of
   shared parameters between any two legitimate OSPF speakers.

   Parameters associated with an OSPF SA:

   Key ID o  This is an 8 bit unsigned value which is used to uniquely
   identify an OSPF SA and would be configured by the administrator. The
   receiver determines the active SA by looking at this field in the
   incoming packet. The sender puts this Key ID based on the active
   configuration.

   Using Key IDs makes the key rollover convenient and an implementation
   can choose to associate an age with each Key ID and can automatically
   use the next key when the former expires. Discussion of how this
   should be done is beyond the scope of this document.

   When doing a key rollover the sender will use a different Key ID
   (which is shared with the receiver). As the receiver will have the
   key with the same Key ID it can use that key for calculating the
   hash. The receiver does not need to compute the hash with multiple
   keys which are valid at that instant. Thus using the Key ID can
   safeguard against potential DoS attacks during the key rollover.

   Authentication Algorithm o This information is never sent over the
   wire and it signifies the authentication algorithm to be used with
   the OSPF SA. Valid values are MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-
   SHA-384 and HMAC-SHA-512

   Authentication Key o This value is never sent on the wire and denotes
   the key associated with the OSPF SA. The length of this key is
   variable and depends upon the authentication algorithm specified by
   the OSPF SA.

4. Using New Algorithms for OSPF Authentication

   The use of the cryptographic authentication fields as specified in
   [RFC2328] is essentially unchanged, but the definitions are updated
   in this document.

   The Key ID uniquely identifies an OSPF SA which gives the algorithm
   and the secret key used to create the HMAC appended to the OSPF
   packet.

   Auth Data Len is the length in octets of the HMAC appended to the
   OSPF packet. It is set to 20 for HMAC-SHA-1, 32 for HMAC-SHA-256, 48
   for HMAC-SHA-384 and 64 for HMAC-SHA-512.



Bhatia, Manral, et. al.                                        [Page 5]


Internet Draft OSPF HMAC-SHA Cryptographic Authentication  October 2008


   The HMAC is not considered a part of the OSPF message, and is not
   accounted for in the Packet Length field of the OSPF header. But as a
   part of the overall IP packet payload, it is accounted for in the
   Total Length field of the IP packet header

   Cryptographic sequence number is an unsigned 32 bit non-decreasing
   sequence number, which is used to protect against replay attacks.

5. Authentication Procedures

   This section details the procedures to be followed by the OSPF
   sending and the receiving sides.

5.1 Message Generation at the Sending Side

   When using HMAC cryptographic authentication the sender chooses the
   secret key by looking at the active SA and modifies the OSPF packet
   as follows:

   (1) The AuType field in the OSPF header is set to 2.

   (2) The checksum field in the standard OSPF header is set to 0.

   (3) The Key ID is set to the current active key.

   (4) The Auth Data Len is set to the length in bytes of the HMAC that
       will be appended to the OSPF packet. This value depends upon the
       authentication algorithm that is being used. Refer to Section 3
       for these values.

   (5) The non decreasing Cryptographic sequence number is filled.

   (6) The HMAC is then calculated and appended to the OSPF packet. The
       authentication algorithm is given by the active SA. Input to the
       authentication algorithm consists of the OSPF packet and the
       secret key. Refer to section 5 for algorithm dependent
       processing.

5.2 Message Verification at the Receiving Side

   All OSPF packets received on an interface must be authenticated. The
   following steps are followed:

   (1) The receiver determines the active SA by looking at the Key ID
       field from the standard OSPF packet header.

       Authentication algorithm dependent processing needs to be
       performed, using the algorithm specified by the appropriate OSPF
       SA for the received packet.


Bhatia, Manral, et. al.                                        [Page 6]


Internet Draft OSPF HMAC-SHA Cryptographic Authentication  October 2008



   (2) The packet is rejected if the cryptographic sequence number is
       less than the cryptographic sequence number stored in the sending
       neighbor's data structure.

   (3) Before performing any processing an implementation MUST save the
       value of the received HMAC.

   (4) The HMAC is calculated based on the authentication algorithm and
       the secret key that was derived from the active SA (derived from
       the incoming key). Refer to section 5 for algorithm dependent
       processing.

   (5) The calculated and the received HMACs are compared. The packet is
       only accepted if the two match. If there is a mismatch then the
       packet is discarded and a security even SHOULD be logged.

   An implementation MAY have a transition mode where it includes HMAC-
   SHA authentication information in the OSPF packets but does not
   verify the HMAC-SHA information. This is provided as a transition aid
   for networks in the process of migrating to HMAC-SHA1, HMAC-256,
   HMAC-SHA-384 and HMAC-SHA-512 based authentication schemes.

   Similarly, implementations not supporting these authentication
   schemes MAY accept packets that contain HMAC-SHA authentication data.

6. Algorithm Dependent Processing

   HMAC is a mechanism for message authentication using cryptographic
   hash functions and has been explained in depth in [RFC2104]. The
   reader is suggested to go through it to clearly understand how it
   works.

   The HMAC algorithm takes key K and text T as the input. The block
   size B is 64 octets for SHA-1 and SHA-256 and is 128 octets for SHA-
   384 and SHA-512

   The Key K is the secret key that has been chosen and text T is the
   OSPF packet that needs to be authenticated.

   [HMAC-SHA] provides open source code to perform these hash functions
   for the internet community. The sample code supports input strings of
   arbitrary bit length, as opposed to [RFC2104] which assumes the text
   T to be a multiple of 8 octets. Similarly, the SHA-1 sample code from
   [RFC3174] has been updated to handle input strings of arbitrary bit
   lengths.





Bhatia, Manral, et. al.                                        [Page 7]


Internet Draft OSPF HMAC-SHA Cryptographic Authentication  October 2008


7. Security Considerations

   The document proposes extensions to OSPF which would make it more
   secure than what it is today. It does not provide confidentiality as
   a routing protocol contains information that does not need to be kept
   secret. It does, however, provide means to authenticate the sender of
   the packets which is of interest to us.

   The cryptographic sequence numbers used to prevent replay attacks can
   be exploited. These are initialized to zero when forming an adjacency
   with a newly discovered neighbor, or when a router comes up. A
   malicious router can store the OSPF packets from the previous session
   and can replay them. This can lead to loops and blackholes [CRYPTO].
   It should be noted that the cryptographic strength of the HMAC
   depends upon the cryptographic strength of the underlying hash
   function and on the size and quality of the key.

   To ensure greater security, the keys used must be changed
   periodically and implementations MUST be able to store and use more
   than one key at the same time.

   There are certain hash functions that require all the fields of the
   message text T to be filled with non-zero values for greater
   security. Any extension using such hash functions to calculate the
   HMAC MUST fill the checksum field with some predefined non-zero
   number. In the SHA context a zero number is as good as any non-zero
   constant, and hence this document does not suggest filling the
   checksum with a non-zero constant.

8. Backwards Compatibility Considerations

   No changes are made to the operation of the OSPF protocol to
   implement cryptographic authentication algorithms as described in
   this document. Additionally, cryptographic authentication using MD5
   is unchanged. So no backward compatibility issues are introduced by
   this document.

9. IANA Considerations

   This document includes no request to IANA.

10. Acknowledgements

   We would like to thank Acee Lindem for his comments on the draft.

11. References

11.1 Normative References




Bhatia, Manral, et. al.                                        [Page 8]


Internet Draft OSPF HMAC-SHA Cryptographic Authentication  October 2008


   [RFC2328]  Moy, J., "OSPF Version 2", RFC 2328, April 1998

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119

   [RFC2104]  Krawczyk, H. et al., "HMAC: Keyed-Hashing for Message
              Authentication", RFC 2104, February 1997

   [NIST]     National Institute of Standards and Technology, "Secure
              Hash Standard", FIPS PUB 180-2, August 2002

   [HMAC-SHA] Eastlake 3rd, D., Hansen, T., "US Secure Hash Algorithms
             (SHA and HMAC-SHA)", Work in Progress

11.2 Informative References

   [MD5-attack]   Wang, X. et al., "Collisions for Hash Functions MD4,
                  MD5, HAVAL-128 and RIPEMD", August 2004,
                  http://eprint.iacr.org/2004/199

   [RFC3174]      Eastlake 3rd, D.,Jones, P., "US Secure Hash Algorithm
                  1 (SHA1)", RFC 3174, September 2001.

   [CRYPTO]       Manral, V. et al., "Issues with existing Cryptographic
                  Protection Methods for Routing Protocols", Work in
                  Progress, February 2006

12. Author's Addresses

   Manav Bhatia
   Alcatel-Lucent
   Bangalore, India
   Email: manav@alcatel-lucent.com

   Vishwas Manral
   IP Infusion
   Almora, Uttarakhand
   India
   Email: vishwas@ipinfusion.com

   Russ White
   Cisco Systems
   RTP North Carolina
   USA
   Email: riw@cisco.com

   Michael Barnes
   Cisco Systems
   225 West Tasman Drive


Bhatia, Manral, et. al.                                        [Page 9]


Internet Draft OSPF HMAC-SHA Cryptographic Authentication  October 2008


   San Jose, CA  95134
   USA
   Email: mjbarnes@cisco.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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, THE IETF TRUST 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.








Bhatia, Manral, et. al.                                        [Page 10]


Internet Draft OSPF HMAC-SHA Cryptographic Authentication  October 2008





















































Bhatia, Manral, et. al.                                        [Page 11]