idnits 2.17.1 draft-bhatia-manral-crypto-req-ospf-01.txt: -(151): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 259. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 277. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 283. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2007) is 6278 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2328' is mentioned on line 60, but not defined == Missing Reference: 'RFC2119' is mentioned on line 109, but not defined == Unused Reference: 'RFC2328' is defined on line 217, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'OSPF-HMAC' Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft February 2007 3 Network Working Group Manav Bhatia 4 Internet Draft Alcatel-Lucent 5 Expires: August 2007 Vishwas Manral 6 IP Infusion 8 Cryptographic Algorithm Implementation Requirements for OSPF 10 draft-bhatia-manral-crypto-req-ospf-01.txt 12 Status of this Memo 14 Distribution of this memo is unlimited. 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 OSPF defines three different kinds of authentication schemes: Null 39 authentication, simple password and cryptographic authentication. The 40 cryptographic authentication scheme can make use of various 41 cryptographic algorithms in order to authenticate the OSPF packets. 42 To ensure interoperability between disparate implementations, it is 43 necessary to specify a set of mandatory-to-implement algorithms to 44 ensure that there is at least one algorithm that all implementations 45 will have available. 47 This document defines the current set of mandatory-to-implement 48 algorithms to be used for the cryptographic authentication for OSPF 49 as well as specifying the algorithms that should be implemented 50 because they may be promoted to mandatory at some future time. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [KEYWORDS] 58 1. Introduction 60 OSPF as defined in [RFC 2328] includes three different types of 61 authentication schemes: Null authentication, simple password and 62 cryptographic authentication. NULL authentication is akin to having 63 no authentication at all. In the simple password scheme of 64 authentication, the passwords are exchanged in the cleartext on the 65 network and anyone with physical access to the network can learn the 66 password and compromise the security of the OSPF domain. 68 In the cryptographic authentication scheme, the OSPF routers on a 69 common network/subnet share a secret key which is used to generate a 70 keyed MD5 digest for each packet and a monotonically increasing 71 sequence number scheme is used to prevent replay attacks. 73 This isn't good enough as there have recently been reports about 74 attacks on the collision resistance properties of MD5 [MD5-attack] 75 and SHA-1 [SHA-1-attack] hash functions. MD5CRK, was a distributed 76 computing project to break the MD5 hash algorithm in a short period 77 of time. The project closed down with the publication of the paper 78 [MD5-attack]. 80 It was discovered that collisions can be found in MD5 algorithm in 81 less than 24 hours, making MD5 very insecure. Further research has 82 verified this result and shown other ways to find collisions in MD5 83 hashes. We thus need to move away from MD5 towards more complex and 84 difficult to break hash algorithms. 86 The [OSPF-HMAC] document recently submitted in the IETF addresses 87 this. It is imperative that we move away from using Keyed MD5 to 88 something that�s cryptographically more stronger (like HMAC-SHA-1). 90 However, the nature of cryptography is that new algorithms surface 91 continuously and existing algorithms are continuously attacked. An 92 algorithm believed to be strong today may be demonstrated to be weak 93 tomorrow. Given this, the choice of mandatory-to-implement algorithm 94 should be conservative so as to minimize the likelihood of it being 95 compromised quickly. 97 Also, we need to recognize that the mandatory-to-implement 98 algorithm(s) may need to change over time to adapt to the changing 99 world. For this reason, the selection of mandatory-to-implement 100 algorithms should not be included in the base OSPF specification. 101 This way it is only this document that needs to get updated, whenever 102 there is a need to update the status of mandatory-to-implement 103 authentication algorithms. 105 2. Requirements Terminology 107 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 108 "MAY" that appear in this document are to be interpreted as described 109 in [RFC2119]. 111 We define some additional terms here: 113 SHOULD+ This term means the same as SHOULD. However, it is 114 likely that an algorithm marked as SHOULD+ will be 115 promoted at some future time to be a MUST. 116 SHOULD- This term means the same as SHOULD. However, it is 117 likely that an algorithm marked as SHOULD- will be 118 deprecated to a MAY or worse in a future version of 119 this document. 120 MUST- This term means the same as MUST. However, we expect 121 that at some point in the future this algorithm will no 122 longer be a MUST. 124 3. Authentication Scheme Selection 126 For OSPF implementations to interoperate, they must support one or 127 more authentication schemes in common. This section specifies the 128 requirements for standards conformant OSPF implementations, which 129 desire to utilize the security feature. 131 Old Old New 132 Req. RFC Requirement Authentication Scheme 133 --- ------ ----------- ------------------------ 134 MUST 2328 SHOULD NOT Null Authentication (1) 135 MUST 2328 SHOULD NOT Simple Password (2) 136 MUST 2328 MUST Cryptographic Authentication 138 The above is only true in case security is required, if there is no 139 requirement of security from an implementation, the above 140 requirements need not be followed 142 Notes: 144 (1)This is used when no authentication is required as there are 145 scenarios when the operator does not really require any sort of 146 authentication. However, this document lists down the requirements 147 that an implementation must support in order to authenticate the 148 OSPF packets. Clearly, NULL should not be used for that if the 149 operator has network security in mind. 151 (2)This is used when all the routers can �trust� one another but the 152 operator does not want an accidental introduction of a router in 153 the domain. Again the same logic applies. This scheme of 154 authentication is useful, but not when the operator wants to 155 �cryptographically� authenticate the OSPF packets. 157 4. Authentication Algorithm Selection 159 For OSPF implementations to interoperate, they must support one or 160 more authentication algorithms in common that can be used in the 161 cryptographic scheme of authentication. 163 This section details the authentication algorithm requirements for 164 standards conformant OSPF implementations. 166 Old Old New 167 Req. RFC Requirement Authentication Algorithm 168 --- ------ ----------- ------------------------ 169 MUST 2328 MUST- Keyed MD5 170 - - SHOULD+ HMAC-SHA-1 [OSPF-HMAC] 171 - - MAY+ HMAC-SHA-256/HMAC-SHA-384/HMAC-SHA-512 173 5. Security Considerations 175 The cryptographic mechanisms defined in this document define only 176 authentication algorithms, and do not provide any confidentiality. 177 However encrypting the content of the packet (providing 178 confidentiality) is not of as great a value to routing protocols as 179 authenticating the source of the packet. 181 It should be noted that the cryptographic strength of the HMAC 182 depends upon the cryptographic strength of the underlying hash 183 function and on the size and quality of the key. 185 To ensure greater security, the keys used must be changed 186 periodically and implementations MUST be able to store and use more 187 than one key at the same time. 189 This document concerns itself with the selection of cryptographic 190 algorithms for the use of OSPF, specifically with the selection of 191 "mandatory-to-implement" algorithms. The algorithms identified in 192 this document as "MUST implement" or "SHOULD implement" are not known 193 to be broken at the current time, and cryptographic research so far 194 leads us to believe that they will likely remain secure into the 195 foreseeable future. However, this isn't necessarily forever. We 196 would therefore expect that new revisions of this document will be 197 issued from time to time that reflect the current best practice in 198 this area. 200 6. Acknowledgements 202 Much of the wording herein was adapted from RFC 4307, "Cryptographic 203 Algorithms for Use in the Internet Key Exchange Version 2", by 204 Jeffrey I. Schiller. 206 7. IANA Considerations 208 This document places no requests to IANA. 210 8. References 212 8.1 Normative References 214 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 215 Requirement Levels", BCP 14, RFC 2119 217 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998 219 [OSPF-HMAC] Bhatia, M., Manral, V. and White, R.," OSPF HMAC 220 Cryptographic Authentication�, Work in Progress 222 8.2 Informative References 224 [MD5-attack] Wang, X. et al., "Collisions for Hash Functions MD4, 225 MD5, HAVAL-128 and RIPEMD", August 2004, 226 http://eprint.iacr.org/2004/199 228 [SHA-1-attack] Wang, X. et al., "Collision Search Attacks on SHA1", 229 February 2005, 230 http://theory.csail.mit.edu/~yiqun/shanote.pdf 232 9. Author's Addresses 234 Manav Bhatia 235 Alcatel-Lucent 236 Bangalore, India 237 Email: manav@alcatel-lucent.com 239 Vishwas Manral 240 IP Infusion 241 Almora, Uttarakhand 242 India 243 Email: vishwas@ipinfusion.com 245 Full Copyright Statement 247 Copyright (C) The IETF Trust (2007). 249 This document is subject to the rights, licenses and restrictions 250 contained in BCP 78, and except as set forth therein, the authors 251 retain all their rights. 253 This document and the information contained herein are provided on an 254 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 255 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 256 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 257 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 258 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 259 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 261 Intellectual Property 263 The IETF takes no position regarding the validity or scope of any 264 Intellectual Property Rights or other rights that might be claimed 265 to pertain to the implementation or use of the technology described 266 in this document or the extent to which any license under such rights 267 might or might not be available; nor does it represent that it has 268 made any independent effort to identify any such rights. Information 269 on the procedures with respect to rights in RFC documents can be 270 found in BCP 78 and BCP 79. 272 Copies of IPR disclosures made to the IETF Secretariat and any 273 assurances of licenses to be made available, or the result of an 274 attempt made to obtain a general license or permission for the use 275 of such proprietary rights by implementers or users of this 276 specification can be obtained from the IETF on-line IPR repository 277 at http://www.ietf.org/ipr. 279 The IETF invites any interested party to bring to its attention any 280 copyrights, patents or patent applications, or other proprietary 281 rights that may cover technology that may be required to implement 282 this standard. Please address the information to the IETF at ietf- 283 ipr@ietf.org.