idnits 2.17.00 (12 Aug 2021) /tmp/idnits12678/draft-turner-rsvp-auth-update-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC2747, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 18, 2013) is 3313 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) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Turner, Ed. 3 Internet-Draft IECA 4 Intended status: Standards Track L. Berger 5 Obsoletes: 2747 (if approved) LabN Consulting 6 Expires: October 20, 2013 M. Jethanandani 7 Ciena 8 K. Patel 9 Cisco Systems 10 D. Zhang 11 Huawei 12 April 18, 2013 14 Cryptographic Agility for the RSVP INTEGRITY Object 15 draft-turner-rsvp-auth-update-01 17 Abstract 19 This document modifies the RSVP INTEGRITY object to support algorithm 20 agility by explicitly indicating the algorithm used. It also 21 provides rationale for the design choices. Finally, it updates the 22 mandatory to implement algorithm. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 1. Introduction 68 RSVP Cryptographic Authentication, defined in [RFC2747] and updated 69 [RFC3097], defines the INTEGRITY object format to enable RSVP message 70 integrity on a hop-by-hop basis. It also specifies the MTI 71 (mandatory to implement) algorithm, HMAC-MD5 [RFC2104]. 73 The integrity algorithm used is not indicated in the INTEGRITY object 74 and is therefore either negotiated via another mechanism or manually 75 configured. Lacking a negotiation mechanism essentially means the 76 algorithm is hard coded. Hard coding algorithms once fashionable is 77 no longer de riqueur. Instead, protocols needs to support algorithm 78 agility because cryptographic protocols weaken over time as 79 cryptanalysis against them improves. This document provides a 80 cryptographically agile INTEGRITY object and it also provides 81 rationale for the choices. 83 Spoiler Alert: The change is to use the unused fields between the 84 Flags and Key Identifier fields to indicate the integrity algorithm. 86 This document does not change the authentication mechanism (i.e., 87 it's still HMAC-based authentication), but it does change the 88 mandatory to implement algorithm. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in RFC 95 2119 [RFC2119]. 97 Familiarity with [RFC2747] is assumed. 99 3. Design Methodology 101 This section is informative. It may or may not be removed in the 102 final version. 104 HMAC-MD5 may not yet be inappropriate to use [RFC6151], but RSVP 105 needs to support algorithm agility in case HMAC-MD5 ever does become 106 insecure. 108 The solution proposed in s3.2 proposed to reuse the Class Number 4 109 instead of defining another Class Number for an INTEGRITYv2 object. 110 In order to do this, the algorithm choice needs to be carried in the 111 object itself. Options exist: 113 o Use one or more of the unused Flags fields. A 7-bit fields would 114 allow 127 additional algorithms to be specified, with 0 115 indicating the existing algorithm. 117 o Use the unused byte between the Flags and the Key Identifier. 118 This would allow an additional 255 algorithms to be specified. 120 o Use a special value in one Key Identifier, Sequence Number of 121 Keyed Message Digest and add another field. This would allow an 122 almost infinite number of algorithms to be specified. 124 Luckily, there's no requirement to support an infinite number of 125 algorithms and besides disrupting the order of the fields seems like 126 too much of an implementation burden. 128 Co-opting some of the unused bits seems best. Flags seem more 129 generic and it would be better to not take them all up. Therefore, 130 using the byte between the Flags and Key Identifier was chosen. 132 4. Cryptographically Agile INTEGRITY Object 134 The same INTEGRITY object type is used for both IPv4 and IPv6. 136 The INTEGRITY object has the following format: 138 Keyed Message Digest INTEGRITY Object: Class = 4, C-Type = 1 140 +-------------+-------------+-------------+-------------+ 141 | Flags | Algorithm | | 142 +-------------+-------------+ + 143 | Key Identifier | 144 +-------------+-------------+-------------+-------------+ 145 | Sequence Number | 146 | | 147 +-------------+-------------+-------------+-------------+ 148 | | 149 + + 150 | | 151 + Keyed Message Digest | 152 | | 153 + + 154 | | 155 +-------------+-------------+-------------+-------------+ 157 The Flags, Key Identifier, Sequence Number, and Keyed Message Digest 158 fields are as defined in [RFC2747]. 160 Algorithm indicates the integrity algorithm used. 162 5. Mandatory to Implement Algorithm 164 [RFC2747] mandates support for HMAC-MD5. This document specifies the 165 mandatory to implement algorithm as HMAC-SHA256 [RFC2104][SHS]. 167 6. IANA Considerations 169 This document establishes a new sub-registry to the RSVP Class Types 170 4 C-Types 1 INTEGRITY registry for integrity algorithms. The 171 assignment policy is Specification Required [RFC5226]. The initial 172 table is as follows: 174 +----------+----------------+---------------------------+ 175 | Alg Flag | Algorithm Name | Keyed Digest Size (bytes) | 176 +----------+----------------+---------------------------+ 177 | 0 | HMAC-MD5 | 16 | 178 +----------+----------------+---------------------------+ 179 | 1 | HMAC-SHA1 | 20 | 180 +----------+----------------+---------------------------+ 181 | 2 | HMAC-SHA224 | 28 | 182 +----------+----------------+---------------------------+ 183 | 3 | HMAC-SHA256 | 32 | 184 +----------+----------------+---------------------------+ 185 | 4 | HMAC-SHA384 | 48 | 186 +----------+----------------+---------------------------+ 187 | 5 | HMAC-SHA512 | 64 | 188 +----------+----------------+---------------------------+ 190 7. Security Considerations 192 TBD 194 8. References 196 8.1. Normative References 198 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 199 Hashing for Message Authentication", RFC 2104, February 200 1997. 202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 203 Requirement Levels", BCP 14, RFC 2119, March 1997. 205 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 206 Authentication", RFC 2747, January 2000. 208 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 209 Authentication -- Updated Message Type Value", RFC 3097, 210 April 2001. 212 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 213 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 214 May 2008. 216 [SHS] National Institute of Standards and Technology (NIST), 217 FIPS Publication 186-3: Digital Signature Standard, 218 October 2008. 220 8.2. Informative References 222 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 223 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 224 RFC 6151, March 2011. 226 Authors' Addresses 228 Lou Berger 229 LabN Consulting L.L.C. 231 Phone: +1-301-468-9228 232 EMail: lberger@labn.net 234 Mahesh Jethanandani 235 Ciena Corporation 236 1741 Technology Drive 237 San Jose, CA 95110 238 USA 240 Phone: +1 (408) 436-3313 241 Email: mjethanandani@gmail.com 243 Keyur Patel 244 Cisco Systems Inc. 245 170 West Tasman Dr 246 San Jose, CA 95134 247 US 249 Email: keyupate@cisco.com 251 Sean Turner (editor) 252 IECA, Inc. 253 3057 Nutley Street, Suite 106 254 Fairfax, Virginia 22031 255 US 257 Phone: +1 (703) 628-3180 258 Email: turners@ieca.com 260 Dacheng Zhang 261 Huawei Technologies Co., LTD. 262 Beijing, 263 China 265 Email: zhangdacheng@huawei.com