idnits 2.17.00 (12 Aug 2021) /tmp/idnits7650/draft-ietf-isis-hmac-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 159 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 82: '...tion Information MUST discard the PDU ...' RFC 2119 keyword, line 85: '...n implementation MAY include HMAC-MD5 ...' RFC 2119 keyword, line 92: '...n implementation MAY check a set of pa...' RFC 2119 keyword, line 96: '... implement HMAC-MD5 authentication MAY...' RFC 2119 keyword, line 100: '... LSP purges MUST remove the body of ...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (January 1999) is 8526 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 (ref. '1') ** Obsolete normative reference: RFC 1142 (ref. '2') (Obsoleted by RFC 7142) Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Tony Li 3 INTERNET DRAFT Juniper Networks 4 January 1999 6 IS-IS HMAC-MD5 Authentication 8 10 Status 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 25 Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim), 26 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 1.0 Abstract 30 This document describes the authentication of IS-IS PDUs using the 31 HMAC-MD5 algorithm [1]. IS-IS is specified in [2], with extensions 32 to support IPv4 described in [3]. The base specification includes an 33 authentication mechanism that allows for multiple authentication 34 algorithms. The base specification only specifies the algorithm for 35 cleartext passwords. 37 This document proposes an extension to that specification that allows 38 the use of the HMAC-MD5 authentication algorithm to be used in 39 conjunction with the existing authentication mechanisms. 41 2.0 Introduction 43 The IS-IS protocol, as specified in ISO 10589, provides for the 44 authentication of Link State PDUs (LSPs) through the inclusion of 45 authentication information as part of the LSP. This authentication 46 information is encoded as a Type-Length-Value (TLV) tuple. The type 47 of the TLV is specified as 10. The length of the TLV is variable. 48 The value of the TLV depends on the authentication algorithm and 49 related secrets being used. The first octet of the value is used to 50 specify the authentication type. Type 0 is reserved, type 1 51 indicates a cleartext password, and type 255 is used for routing 52 domain private authentication methods. The remainder of the TLV 53 value is known as the Authentication Value. 55 This document extends the above situation by allocating a new 56 authentication type for HMAC-MD5 and specifying the algorithms for 57 the computation of the Authentication Value. This document also 58 describes modifications to the base protocol to insure that the 59 authentication mechanisms described in this document are effective. 61 This document is a publication of the IS-IS Working Group within the 62 IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual 63 inclusion with ISO 10589. 65 3.0 Authentication Procedures 67 The authentication type used for HMAC-MD5 is 54 (0x36). The length 68 of the Authentication Value for HMAC-MD5 is 16, and the length field 69 in the TLV is 17. 71 The HMAC-MD5 algorithm requires a key K and text T as input. The key 72 K is the password for the PDU type, as specified in ISO 10589. The 73 text T is the PDU to be authenticated with the Authentication Value 74 field inside of the Authentication Information TLV set to zero. Note 75 that the Authentication Type is set to 54 and the length of the TLV 76 is set to 17 before authentication is computed. When LSPs are 77 authenticated, the Checksum and Remaining Lifetime fields are set to 78 zero (0) before authentication is computed. The result of the 79 algorithm is placed in the Authentication Value field. 81 An implementations that implements HMAC-MD5 authentication and 82 receives HMAC-MD5 Authentication Information MUST discard the PDU if 83 the Authentication Value is incorrect. 85 An implementation MAY include HMAC-MD5 Authentication Information in 86 PDUs even if it does not fully implement HMAC-MD5 authentication. 87 This allows an implementation to generate authentication information 88 without verifying the authentication information. This is a 89 transition aid for networks in the process of deploying 90 authentication. 92 An implementation MAY check a set of passwords when verifying the 93 Authentication Value. This provides a mechanism for incrementally 94 changing passwords in a network. 96 An implementation that does not implement HMAC-MD5 authentication MAY 97 accept a PDU that contains the HMAC-MD5 Authentication Type. 99 ISes (routers) that implement HMAC-MD5 authentication and initiating 100 LSP purges MUST remove the body of the LSP and add the authentication 101 TLV. ISes MUST NOT accept unauthenticated purges. ISes MUST NOT 102 accept purges that contain TLVs other than the authentication TLV. 103 These restrictions are necessary to prevent a hostile system from 104 receiving an LSP, setting the Remaining Lifetime field to zero, and 105 flooding it, thereby initiating a purge without knowing the 106 authentication password. 108 4.0 Security Considerations 110 This document enhances the security of the IS-IS routing protocol. 111 Because a routing protocol contains information that is not of 112 significant value, privacy is not a requirement. However, 113 authentication of the messages within the protocol is of interest. 115 The technology in this document provides an authentication mechanism 116 for IS-IS. This mechanism does not prevent replay attacks, however 117 such attacks would trigger mechanisms in the protocol that would 118 effectively reject old information. This document does not address 119 denial-of-service attacks. 121 5.0 Acknowledgments 123 The author would like to thank Henk Smit, Dave Katz and Tony 124 Przygienda for their comments on this work. 126 6.0 References 128 [1] RFC 2104, "HMAC: Keyed-Hashing for Message Authentication", H. 129 Krawczyk, M. Bellare, R. Canetti, February 1997 131 [2] ISO 10589, "Intermediate System to Intermediate System Intra- 132 Domain Routeing Exchange Protocol for use in Conjunction with the 133 Protocol for Providing the Connectionless-mode Network Service (ISO 134 8473)" [Also republished as RFC 1142] 136 [3] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual 137 environments", R.W. Callon, Dec. 1990 139 10.0 Author's Address 141 Tony Li 142 Juniper Networks, Inc. 143 385 Ravendale Dr. 144 Mountain View, CA 94043 145 Email: tli@juniper.net 146 Fax: +1 650 526 8001 147 Voice: +1 650 526 8006