| < draft-ietf-isis-hmac-03.txt | draft-ietf-isis-hmac-04.txt > | |||
|---|---|---|---|---|
| Network Working Group Tony Li | ||||
| INTERNET DRAFT Procket Networks | Network Working Group | |||
| draft-ietf-isis-hmac-03.txt RJ Atkinson | Tony Li | |||
| Extreme Networks | INTERNET DRAFT Procket Networks | |||
| 4 July 2001 | Atkinson RJ | |||
| Extreme Networks | ||||
| draft-ietf-isis-hmac-04.txt 22 April 2003 | ||||
| IS-IS Cryptographic Authentication | IS-IS Cryptographic Authentication | |||
| STATUS OF THIS MEMO | STATUS OF THIS MEMO | |||
| This document is an Internet-Draft and is in full conformance with all | This document is an Internet-Draft and is subject to all provisions | |||
| provisions of Section 10 of RFC2026 except that the right to produce | of Section 10 of RFC2026. | |||
| derivative works is not granted. | ||||
| Internet-Drafts are working documents of the Internet Engineering Task | Internet-Drafts are working documents of the Internet Engineering | |||
| Force (IETF), its areas, and its working groups. Note that other groups | Task Force (IETF), its areas, and its working groups. Note that other | |||
| may also distribute working documents as Internet-Drafts. | groups may also distribute working documents as Internet-Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six months and | Internet-Drafts are draft documents valid for a maximum of six months | |||
| may be updated, replaced, or obsoleted by other documents at any time. It | and may be updated, replaced, or obsoleted by other documents at any | |||
| is inappropriate to use Internet-Drafts as reference material or to cite | time. It is inappropriate to use Internet-Drafts as reference material or to | |||
| them other than as "work in progress." | cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| ABSTRACT | ABSTRACT | |||
| This document describes the authentication of IS-IS PDUs using the | This document describes the authentication of IS-IS PDUs using the | |||
| HMAC-MD5 algorithm [1]. IS-IS is specified in [2], with extensions | HMAC-MD5 algorithm as found in RFC 2104. IS-IS is specified in ISO | |||
| to support IPv4 described in [3]. The base specification includes an | 10589 and RFC 1142, with extensions to support IPv4 described in RFC | |||
| authentication mechanism that allows for multiple authentication | 1195. The base specification includes an authentication mechanism | |||
| algorithms. The base specification only specifies the algorithm for | that allows for multiple authentication algorithms. The base | |||
| cleartext passwords. | specification only specifies the algorithm for cleartext passwords. | |||
| This document proposes an extension to that specification that | ||||
| allows the use of the HMAC-MD5 authentication algorithm to be used in | This document proposes an extension to that specification that allows | |||
| the use of the HMAC-MD5 authentication algorithm to be used in | ||||
| conjunction with the existing authentication mechanisms. | conjunction with the existing authentication mechanisms. | |||
| 1. Introduction | 1. Introduction | |||
| The IS-IS protocol, as specified in ISO 10589, provides for the | The IS-IS protocol, as specified in ISO 10589 and RFC 1142[1], | |||
| authentication of Link State PDUs (LSPs) through the inclusion of | provides for the authentication of Link State PDUs (LSPs) through the | |||
| authentication information as part of the LSP. This authentication | inclusion of authentication information as part of the LSP. This | |||
| information is encoded as a Type-Length-Value (TLV) tuple. | authentication information is encoded as a Type-Length-Value (TLV) | |||
| tuple. The use of IS-IS for IPv4 networks is described in [2]. | ||||
| The type of the TLV is specified as 10. The length of the TLV | The type of the TLV is specified as 10. The length of the TLV is | |||
| is variable. The value of the TLV depends on the authentication | variable. The value of the TLV depends on the authentication | |||
| algorithm and related secrets being used. The first octet of the | algorithm and related secrets being used. The first octet of the | |||
| value is used to specify the authentication type. Type 0 is | value is used to specify the authentication type. Type 0 is | |||
| reserved, type 1 indicates a cleartext password, and type 255 is used | reserved, type 1 indicates a cleartext password, and type 255 is used | |||
| for routing domain private authentication methods. The remainder of | for routing domain private authentication methods. The remainder of | |||
| the TLV value is known as the Authentication Value. | the TLV value is known as the Authentication Value. | |||
| This document extends the above situation by allocating a new | This document extends the above situation by allocating a new | |||
| authentication type for HMAC-MD5 and specifying the algorithms for | authentication type for HMAC-MD5 and specifying the algorithms for | |||
| the computation of the Authentication Value. This document also | the computation of the Authentication Value. This document also | |||
| describes modifications to the base protocol to insure that the | describes modifications to the base protocol to insure that the | |||
| authentication mechanisms described in this document are effective. | authentication mechanisms described in this document are effective. | |||
| This document is a publication of the IS-IS Working Group within | This document is a publication of the IS-IS Working Group within the | |||
| the IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual | IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual | |||
| inclusion with ISO 10589. | inclusion with ISO 10589. | |||
| 2. Authentication Procedures | 2. Authentication Procedures | |||
| The authentication type used for HMAC-MD5 is 54 (0x36). The | The authentication type used for HMAC-MD5 is 54 (0x36). The length | |||
| length of the Authentication Value for HMAC-MD5 is 16, and the length | of the Authentication Value for HMAC-MD5 is 16, and the length field | |||
| field in the TLV is 17. | in the TLV is 17. | |||
| The HMAC-MD5 algorithm requires a key K and text T as input. | The HMAC-MD5 algorithm requires a key K and text T as input [3]. The | |||
| The key K is the password for the PDU type, as specified in ISO | key K is the password for the PDU type, as specified in ISO 10589. | |||
| 10589. The text T is the IS-IS PDU to be authenticated with the | The text T is the IS-IS PDU to be authenticated with the | |||
| Authentication Value field inside of the Authentication Information | Authentication Value field inside of the Authentication Information | |||
| TLV set to zero. Note that the Authentication Type is set to 54 and | TLV set to zero. Note that the Authentication Type is set to 54 and | |||
| the length of the TLV is set to 17 before authentication is computed. | the length of the TLV is set to 17 before authentication is computed. | |||
| When LSPs are authenticated, the Checksum and Remaining Lifetime | When LSPs are authenticated, the Checksum and Remaining Lifetime | |||
| fields are set to zero (0) before authentication is computed. The | fields are set to zero (0) before authentication is computed. The | |||
| result of the algorithm is placed in the Authentication Value field. | result of the algorithm is placed in the Authentication Value field. | |||
| When calculating the HMAC-MD5 result for Sequence Number PDUs | When calculating the HMAC-MD5 result for Sequence Number PDUs, Level | |||
| and IS-IS HELLO PDUs, Level 1 Sequence Number PDUs SHALL use the Area | 1 Sequence Number PDUs SHALL use the Area Authentication string as in | |||
| Authentication string as in Level 1 Link State PDUs. Level 2 | Level 1 Link State PDUs. Level 2 Sequence Number PDUs shall use the | |||
| Sequence Number PDUs shall use the domain authentication string as in | domain authentication string as in Level 2 Link State PDUs. IS-IS | |||
| Level 2 Link State PDUs. IS-IS HELLO PDUs SHALL use the Link Level | HELLO PDUs SHALL use the Link Level Authentication String, which MAY | |||
| Authentication String, which MAY be different from that of Link State | be different from that of Link State PDUs. The HMAC-MD5 result for | |||
| PDUs. The HMAC-MD5 result for the IS-IS HELLO PDUs SHALL be | the IS-IS HELLO PDUs SHALL be calculated after the Packet is padded | |||
| calculated after the Packet is padded to the MTU size, if padding is | to the MTU size, if padding is not disabled. Implementations that | |||
| not disabled. Implementations that support the optional checksum for | support the optional checksum for the Sequence Number PDUs and IS-IS | |||
| the Sequence Number PDUs and IS-IS HELLO PDUs MUST NOT include the | HELLO PDUs MUST NOT include the Checksum TLV. | |||
| Checksum TLV. | ||||
| An implementation that implements HMAC-MD5 authentication and | To authenticate an incoming PDU, a system should save the values of | |||
| receives HMAC-MD5 Authentication Information MUST discard the PDU if | the Authentication Value field, the Checksum and the Remaining | |||
| Lifetime field, set these fields to zero, compute authentication, and | ||||
| then restore the values of these fields. | ||||
| An implementation that implements HMAC-MD5 authentication and | ||||
| receives HMAC-MD5 Authentication Information MUST discard the PDU if | ||||
| the Authentication Value is incorrect. | the Authentication Value is incorrect. | |||
| An implementation MAY have a transition mode where it includes | An implementation MAY have a transition mode where it includes HMAC- | |||
| HMAC-MD5 Authentication Information in PDUs but does not verify the | MD5 Authentication Information in PDUs but does not verify the HMAC- | |||
| HMAC-MD5 authentication information. This is a transition aid for | MD5 authentication information. This is a transition aid for | |||
| networks in the process of deploying authentication. | networks in the process of deploying authentication. | |||
| An implementation MAY check a set of passwords when verifying the | An implementation MAY check a set of passwords when verifying the | |||
| Authentication Value. This provides a mechanism for incrementally | Authentication Value. This provides a mechanism for incrementally | |||
| changing passwords in a network. | changing passwords in a network. | |||
| An implementation that does not implement HMAC-MD5 authentication | An implementation that does not implement HMAC-MD5 authentication MAY | |||
| MAY accept a PDU that contains the HMAC-MD5 Authentication Type. | accept a PDU that contains the HMAC-MD5 Authentication Type. ISes | |||
| ISes (routers) that implement HMAC-MD5 authentication and initiate | (routers) that implement HMAC-MD5 authentication and initiate LSP | |||
| LSP purges MUST remove the body of the LSP and add the authentication | purges MUST remove the body of the LSP and add the authentication | |||
| TLV. ISes implementing HMAC-MD5 authentication MUST NOT accept | TLV. ISes implementing HMAC-MD5 authentication MUST NOT accept | |||
| unauthenticated purges. ISes MUST NOT accept purges that contain | unauthenticated purges. ISes MUST NOT accept purges that contain | |||
| TLVs other than the authentication TLV. These restrictions are | TLVs other than the authentication TLV. These restrictions are | |||
| necessary to prevent a hostile system from receiving an LSP, setting | necessary to prevent a hostile system from receiving an LSP, setting | |||
| the Remaining Lifetime field to zero, and flooding it, thereby | the Remaining Lifetime field to zero, and flooding it, thereby | |||
| initiating a purge without knowing the authentication password. | initiating a purge without knowing the authentication password. | |||
| 2.1 Implementation Considerations | 2.1 Implementation Considerations | |||
| There is an implementation issue just after password rollover on | There is an implementation issue just after password rollover on an | |||
| an IS-IS router that might benefit from additional commentary. | IS-IS router that might benefit from additional commentary. | |||
| Immediately after password rollover on the router, the router or IS- | Immediately after password rollover on the router, the router or IS- | |||
| IS process may restart. If this happens, this causes the LSP | IS process may restart. If this happens, this causes the LSP | |||
| Sequence Number restarts from the value 1 using the new password. | Sequence Number restarts from the value 1 using the new password. | |||
| However, neighbors will reject those new LSPs because the Sequence | However, neighbors will reject those new LSPs because the Sequence | |||
| Number is smaller. The router can not increase its own LSP Sequence | Number is smaller. The router can not increase its own LSP Sequence | |||
| Number because it fails to authenticate its own old LSP that | Number because it fails to authenticate its own old LSP that | |||
| neighbors keep sending to it. So the router can not update its LSP | neighbors keep sending to it. So the router can not update its LSP | |||
| Sequence Number to its neighbors until all the neighbors time out all | Sequence Number to its neighbors until all the neighbors time out all | |||
| of the original LSPs. One possible solution to this problem is for | of the original LSPs. One possible solution to this problem is for | |||
| the IS-IS process to detect if any inbound LSP with an authentication | the IS-IS process to detect if any inbound LSP with an authentication | |||
| failure has the local System ID and also has a higher Sequence Number | failure has the local System ID and also has a higher Sequence Number | |||
| than the IS-IS process has. In this event, the IS-IS process SHOULD | than the IS-IS process has. In this event, the IS-IS process SHOULD | |||
| increase its own LSP Sequence Number accordingly and re-flood the | increase its own LSP Sequence Number accordingly and re-flood the | |||
| LSPs. However, as this scenario could also be triggered by an active | LSPs. However, as this scenario could also be triggered by an active | |||
| attack by an adversary, it is recommended that a counter also be kept | attack by an adversary, it is recommended that a counter also be kept | |||
| on this case to mitigate the risk from such an active attack. | on this case to mitigate the risk from such an active attack. | |||
| 3. Security Considerations | 3. Security Considerations | |||
| This document enhances the security of the IS-IS routing | This document enhances the security of the IS-IS routing protocol. | |||
| protocol. Because a routing protocol contains information that need | Because a routing protocol contains information that need not be kept | |||
| not be kept secret, privacy is not a requirement. However, | secret, privacy is not a requirement. However, authentication of the | |||
| authentication of the messages within the protocol is of interest, to | messages within the protocol is of interest, to reduce the risk of an | |||
| reduce the risk of an adversary compromising the routing system by | adversary compromising the routing system by deliberately injecting | |||
| deliberately injecting false information into the routing system. | false information into the routing system. | |||
| The technology in this document provides an authentication | ||||
| mechanism for IS-IS. The mechanism described here is not perfect and | ||||
| does not need to be perfect. Instead, this mechanism represents a | ||||
| significant increase in the work function of an adversary attacking | ||||
| the IS-IS protocol, while not causing undue implementation, | ||||
| deployment, or operational complexity. | ||||
| This mechanism does not prevent replay attacks, however such | The technology in this document provides an authentication mechanism | |||
| attacks would trigger existing mechanisms in the IS-IS protocol that | for IS-IS. The mechanism described here is not perfect and does not | |||
| would effectively reject old information. Denial of service attacks | need to be perfect. Instead, this mechanism represents a significant | |||
| are not generally preventable in a useful networking protocol [4]. | increase in the work function of an adversary attacking the IS-IS | |||
| protocol, while not causing undue implementation, deployment, or | ||||
| operational complexity. | ||||
| Changes to the authentication mechanism described here | This mechanism does not prevent replay attacks, however, in most | |||
| (primarily: to add a Key-ID field such as OSPFv2 and RIPv2 have) were | cases, such attacks would trigger existing mechanisms in the IS-IS | |||
| considered at some length, but ultimately were rejected. The | protocol that would effectively reject old information. Denial of | |||
| mechanism here was already widely implemented in 1999. As of this | service attacks are not generally preventable in a useful networking | |||
| writing, this mechanism is fairly widely deployed within the users | protocol [4]. | |||
| interested in cryptographic authentication of IS-IS. The improvement | ||||
| provided by the proposed revised mechanism was not large enough to | ||||
| justify the change, given the installed base and lack of operator | ||||
| interest in deploying the proposed revised mechanism. | ||||
| If and when a key management protocol appears that is both | Changes to the authentication mechanism described here (primarily: to | |||
| widely implemented and easily deployed to secure routing protocols | add a Key-ID field such as OSPFv2 and RIPv2 have) were considered at | |||
| such as IS-IS, a different authentication mechanism that is designed | some length, but ultimately were rejected. The mechanism here was | |||
| for use with that key management schema could be added if desired. | already widely implemented in 1999. As of this writing, this | |||
| mechanism is fairly widely deployed within the users interested in | ||||
| cryptographic authentication of IS-IS. The improvement provided by | ||||
| the proposed revised mechanism was not large enough to justify the | ||||
| change, given the installed base and lack of operator interest in | ||||
| deploying the proposed revised mechanism. | ||||
| If a stronger authentication were believed to be required, then | If and when a key management protocol appears that is both widely | |||
| implemented and easily deployed to secure routing protocols such as | ||||
| IS-IS, a different authentication mechanism that is designed for use | ||||
| with that key management schema could be added if desired. | ||||
| the use of a full digital signature [5] would be an approach that | If a stronger authentication were believed to be required, then the | |||
| should be seriously considered. It was rejected for this purpose at | use of a full digital signature [5] would be an approach that should | |||
| this time because the computational burden of full digital signatures | be seriously considered. It was rejected for this purpose at this | |||
| is believed to be much higher than is reasonable given the current | time because the computational burden of full digital signatures is | |||
| believed to be much higher than is reasonable given the current | ||||
| threat environment in operational commercial networks. | threat environment in operational commercial networks. | |||
| ACKNOWLEDGMENTS | ACKNOWLEDGMENTS | |||
| The author would like to thank (in alphabetical order) Ran | The authors would like to thank (in alphabetical order) Dave Katz, | |||
| Atkinson, Dave Katz, Steven Luong, Tony Przygienda, Nai-Ming Shen, | Steven Luong, Tony Przygienda, Nai-Ming Shen, and Henk Smit for their | |||
| and Henk Smit for their comments and suggestions on this document. | comments and suggestions on this document. | |||
| REFERENCES | NORMATIVE REFERENCES | |||
| [1] H. Krawczyk, M. Bellare, & R. Canetti, "HMAC: Keyed-Hashing for Message | [1] ISO, "Intermediate System to Intermediate System Intra- Domain | |||
| Routing | ||||
| Exchange Protocol for use in Conjunction with the Protocol for | ||||
| Providing | ||||
| the Connectionless-mode Network Service (ISO 8473)", International | ||||
| Standard | ||||
| 10589 [Also republished as RFC 1142]. | ||||
| [3] H. Krawczyk, M. Bellare, & R. Canetti, "HMAC: Keyed-Hashing for | ||||
| Message | ||||
| Authentication", RFC-2104, February 1997 | Authentication", RFC-2104, February 1997 | |||
| [2] ISO, "Intermediate System to Intermediate System Intra- Domain Routing | INFORMATIVE REFERENCES | |||
| Exchange Protocol for use in Conjunction with the Protocol for Providing | ||||
| the Connectionless-mode Network Service (ISO 8473)", International Standard | ||||
| 10589 [Also republished as RFC 1142]. | ||||
| [3] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual | [2] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual | |||
| environments", RFC-1195, December 1990. | environments", RFC-1195, December 1990. | |||
| [4] V.L. Voydock & S. T. Kent, "Security Mechanisms in High-level | [4] V.L. Voydock & S. T. Kent, "Security Mechanisms in High-level | |||
| Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. | Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983. | |||
| [5] S. Murphy, M. Badger, & B. Wellington, "OSPF with Digital Signatures", | [5] S. Murphy, M. Badger, & B. Wellington, "OSPF with Digital | |||
| RFC-2154, June 1997. | Signatures", | |||
| RFC-2154,June 1997. | ||||
| Author's Address | Author's Address | |||
| Tony Li | Tony Li | |||
| Procket Networks | Procket Networks | |||
| 1100 Cadillac Ct. | 1100 Cadillac Ct. | |||
| Milpitas, California | Milpitas, California | |||
| 95035 USA | 95035 USA | |||
| Email: tli@procket.net | Email: tli@procket.net | |||
| End of changes. 34 change blocks. | ||||
| 136 lines changed or deleted | 148 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||