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]