--- 1/draft-ietf-mpls-ldp-hello-crypto-auth-05.txt 2014-05-25 19:14:23.560550339 -0700 +++ 2/draft-ietf-mpls-ldp-hello-crypto-auth-06.txt 2014-05-25 19:14:23.592551080 -0700 @@ -1,20 +1,20 @@ Network Working Group L. Zheng Internet-Draft M. Chen Intended status: Standards Track Huawei Technologies -Expires: November 5, 2014 M. Bhatia +Expires: November 22, 2014 M. Bhatia Alcatel-Lucent - May 4, 2014 + May 21, 2014 LDP Hello Cryptographic Authentication - draft-ietf-mpls-ldp-hello-crypto-auth-05.txt + draft-ietf-mpls-ldp-hello-crypto-auth-06.txt Abstract This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. @@ -32,21 +32,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on November 5, 2014. + This Internet-Draft will expire on November 22, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -61,32 +61,32 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Cryptographic Authentication TLV . . . . . . . . . . . . . . 4 2.1. Optional Parameter for Hello Message . . . . . . . . . . 4 2.2. LDP Security Association . . . . . . . . . . . . . . . . 4 2.3. Cryptographic Authentication TLV Encoding . . . . . . . . 6 2.4. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 8 3. Cryptographic Authentication Procedure . . . . . . . . . . . 8 4. Cross Protocol Attack Mitigation . . . . . . . . . . . . . . 8 5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 8 5.1. Preparing the Cryptographic Key . . . . . . . . . . . . . 9 - 5.2. Computing the Hash . . . . . . . . . . . . . . . . . . . 10 + 5.2. Computing the Hash . . . . . . . . . . . . . . . . . . . 9 5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Processing Hello Message Using Cryptographic Authentication . 10 6.1. Transmission Using Cryptographic Authentication . . . . . 10 - 6.2. Receipt Using Cryptographic Authentication . . . . . . . 11 + 6.2. Receipt Using Cryptographic Authentication . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The Label Distribution Protocol (LDP) [RFC5036] sets up LDP sessions that run between LDP peers. The peers could either be directly connected at the link level or could be multiple hops away. An LDP Label Switching Router (LSR) could either be configured with the identity of its peers or could discover them using LDP Hello messages. These messages are sent encapsulated in UDP addressed to "all routers on this subnet" or to a specific IP address. Periodic @@ -134,24 +134,24 @@ number carried in the Hello messages that can be used to protect against replay attacks. The LSRs could be configured to only accept Hello messages from specific peers when authentication is in use. Using this Cryptographic Authentication TLV, one or more secret keys (with corresponding Security Association (SA) IDs) are configured in each system. For each LDP Hello message, the key is used to generate and verify a HMAC Hash that is stored in the LDP Hello message. For cryptographic hash function, this document proposes to use SHA-1, SHA-256, SHA-384, and SHA-512 defined in US NIST Secure Hash Standard - (SHS) [FIPS-180-3]. The HMAC authentication mode defined in NIST - FIPS 198 is used [FIPS-198]. Of the above, implementations MUST - include support for at least HMAC-SHA-256 and SHOULD include support - for HMAC-SHA-1 and MAY include support for either of HMAC-SHA-384 or + (SHS) [FIPS-180-3]. The HMAC authentication mode defined in + [RFC2104] is used. Of the above, implementations MUST include + support for at least HMAC-SHA-256 and SHOULD include support for + HMAC-SHA-1 and MAY include support for either of HMAC-SHA-384 or HMAC-SHA-512. 2. Cryptographic Authentication TLV 2.1. Optional Parameter for Hello Message [RFC5036] defines the encoding for the Hello message. Each Hello message contains zero or more Optional Parameters, each encoded as a TLV. Three Optional Parameters are defined by [RFC5036]. This document defines a new Optional Parameter: the Cryptographic @@ -243,21 +243,22 @@ generated with this LDP Security Association. In order to achieve smooth key transition, KeyStartAccept SHOULD be less than KeyStartGenerate and KeyStopGenerate SHOULD be less than KeyStopAccept. If KeyStartGenerate or KeyStartAccept are left unspecified, the time will default to 0 and the key will be used immediately. If KeyStopGenerate or KeyStopAccept are left unspecified, the time will default to infinity and the key's lifetime will be infinite. When a new key replaces an old, the KeyStartGenerate time for the new key MUST be less than or equal to - the KeyStopGenerate time of the old key. + the KeyStopGenerate time of the old key. Any unspecified values are + encoded as Zero. Key storage SHOULD persist across a system restart, warm or cold, to avoid operational issues. In the event that the last key associated with an interface expires, it is unacceptable to revert to an unauthenticated condition, and not advisable to disrupt routing. Therefore, the router SHOULD send a "last Authentication Key expiration" notification to the network manager and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured @@ -364,89 +366,71 @@ In order to prevent cross protocol replay attacks for protocols sharing common keys, the two octet LDP Cryptographic Protocol ID is appended to the authentication key prior to use (refer to Section 8). Other protocols using the common key similarly append their own Cryptographic Protocol IDs to their keys prior to use thus ensuring that a different key value is used for each protocol. 5. Cryptographic Aspects - In the algorithm description below, the following nomenclature, which - is consistent with [FIPS-198], is used: + In the algorithm description below, the following nomenclature is + used: H is the specific hashing algorithm (e.g. SHA-256). K is the Authentication Key from the LDP security association. Ks is a Protocol Specific Authentication Key obtained by appending Authentication Key (K) with the two-octet LDP Cryptographic Protocol - ID appended. + ID . Ko is the cryptographic key used with the hash algorithm. - B is the block size of H, measured in octets rather than bits. - - Note that B is the internal block size, not the hash size. - - For SHA-1 and SHA-256: B == 64 - - For SHA-384 and SHA-512: B == 128 - L is the length of the hash, measured in octets rather than bits. - XOR is the exclusive-or operation. - - Opad is the hexadecimal value 0x5c repeated B times. - - Ipad is the hexadecimal value 0x36 repeated B times. - - Apad is a value which is the same length as the hash output or - message digest. In case of IPv4, the first 4 octets contain the IPv4 - source address followed by the hexadecimal value 0x878FE1F3 repeated - (L-4)/4 times. In case of IPv6, the first 16 octets contain the IPv6 - source address followed by the hexadecimal value 0x878FE1F3 repeated - (L-16)/4 times. This implies that hash output is always a length of - at least 16 octets. + AuthTag is a value which is the same length as the hash output. In + case of IPv4, the first 4 octets contain the IPv4 source address + followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times. + In case of IPv6, the first 16 octets contain the IPv6 source address + followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. + This implies that hash output is always a length of at least 16 + octets. 5.1. Preparing the Cryptographic Key The LDP Cryptographic Protocol ID is appended to the Authentication Key (K) yielding a Protocol Specific Authentication Key (Ks). In - this application, Ko is always L octets long. While [RFC2104] - supports a key that is up to B octets long, this application uses L - as the Ks length consistent with [RFC4822], [RFC5310], [RFC5709] and - [RFC7166]. According to [FIPS-180-3], Section 3, keys greater than L - octets do not significantly increase the function strength. Ks is - computed as follows: + this application, Ko is always L octets long. Keys that are longer + than the bit length of the hash function are hashed to force them to + this length, as we describe below. Ks is computed as follows: If the Protocol Specific Authentication Key (Ks) is L octets long, then Ko is equal to Ks. If the Protocol Specific Authentication Key (Ks) is more than L octets long, then Ko is set to H(Ks). If the Protocol Specific Authentication Key (Ks) is less than L octets long, then Ko is set to the Protocol Specific Authentication Key (Ks) with zeros appended to the end of the Protocol Specific Authentication Key (Ks) such that Ko is L octets long. + For higher entropy it is RECOMMENDED that Key Ks should be at least L + octets long. + 5.2. Computing the Hash First, the Authentication Data field in the Cryptographic - Authentication TLV is filled with the value Apad. Then, to compute - HMAC over the Hello message it performs: - - H(Ko XOR Opad || H(Ko XOR Ipad || (Hello Message))) - - Hello Message refers to the LDP Hello message excluding the IP - header. + Authentication TLV is filled with the value AuthTag. Then, to + compute HMAC over the Hello message it performs: - When XORing Ko and Ipad, or XORing Ko and Opad, Ko must be padded - with zeros to the length of Ipad and the Opad. + AuthData = HMAC(Ko, Hello Message) + Hello Message refers to the LDP Hello message excluding the IP and + the UDP headers. 5.3. Result The resultant Hash becomes the Authentication Data that is sent in the Authentication Data field of the Cryptographic Authentication TLV. The length of the Authentication Data field is always identical to the message digest size of the specific hash function H that is being used. This also means that the use of hash functions with larger output @@ -482,21 +466,21 @@ current time >= KeyStopAccept), LDP Hello message MUST be discarded, and an error event SHOULD be logged. If the cryptographic sequence number in the LDP packet is less than or equal to the last sequence number received from the same neighbor, the LDP message MUST be discarded, and an error event SHOULD be logged. Before the receiving LSR performs any processing, it needs to save the values of the Authentication Data field. The receiving LSR then - replaces the contents of the Authentication Data field with Apad, + replaces the contents of the Authentication Data field with AuthTag, computes the Hash, using the authentication key specified by the received Security Association ID field, as explained in Section 3. If the locally computed Hash is equal to the received value of the Authentication Data field, the received packet is accepted for other normal checks and processing as described in [RFC5036]. Otherwise, if the locally computed Hash is not equal to the received value of the Authentication Data field, the received packet MUST be discarded, and an error event SHOULD be logged. The foresaid logging need to be carefully rate limited, since while a LDP router is under attack of a storm of spoofed hellos, the resource taking for logging could be @@ -524,31 +508,29 @@ authentication type used. It should be noted that the authentication method described in this document is not being used to authenticate the specific originator of a packet but is rather being used to confirm that the packet has indeed been issued by a router that has access to the Authentication Key. Deployments SHOULD use sufficiently long and random values for the Authentication Key so that guessing and other cryptographic attacks - on the key are not feasible in their environments. Furthermore, it - is RECOMMENDED that Authentication Keys incorporate at least 128 - pseudo-random bits to minimize the risk of such attacks. In support - of these recommendations, management systems SHOULD support - hexadecimal input of Authentication Keys. + on the key are not feasible in their environments. In support of + these recommendations, management systems SHOULD support hexadecimal + input of Authentication Keys. - The mechanism described herein is not perfect and does not need to be - perfect. Instead, this mechanism represents a significant increase - in the effort required for an adversary to successfully attack the - LDP Hello protocol while not causing undue implementation, - deployment, or operational complexity. + The mechanism described herein is not perfect . However, this + mechanism introduces a significant increase in the effort required + for an adversary to successfully attack the LDP Hello protocol while + not causing undue implementation, deployment, or operational + complexity. 8. IANA Considerations The IANA is requested to as assign a new TLV from the "Multiprotocol Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-TLVs" sub- registry. Value Meaning Reference ----- -------------------------------- --------- TBD1 Cryptographic Authentication TLV this document (sect 2.3) @@ -557,41 +539,46 @@ "Authentication Cryptographic Protocol ID", registry under the "Keying and Authentication for Routing Protocols (KARP) Parameters" category. Value Meaning Reference ----- -------------------------------- --------- TBD2 LDP Cryptographic Protocol ID this document (sect 4) 9. Acknowledgements - The authors would like to thank Liu Xuehu for his work on background - and motivation for LDP Hello authentication. The authors also would - like to thank Adrian Farrel, Eric Rosen, Sam Hartman, Eric Gray, - Kamran Raza and Acee Lindem for their valuable comments. + We are indebted to Yaron Sheffer who helped us enormously in + rewriting the draft to get rid of the redundant crypto mathematics + that we had added here. - We would also like to thank the authors of RFC 5709 and RFC 7166 from - where we have taken most of the cryptographic computation procedures - from. + We would also like to thank Liu Xuehu for his work on background and + motivation for LDP Hello authentication. And last but not the least, + we would also thank Adrian Farrel, Eric Rosen, Sam Hartman, Stephen + Farrell, Eric Gray, Kamran Raza and Acee Lindem for their valuable + comments. 10. References 10.1. Normative References [FIPS-180-3] "Secure Hash Standard (SHS), FIPS PUB 180-3", October 2008. [FIPS-198] "The Keyed-Hash Message Authentication Code (HMAC), FIPS PUB 198", March 2002. + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, February + 1997. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., @@ -600,24 +587,20 @@ [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009. [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, March 2014. 10.2. Informative References - [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, February - 1997. - [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007. [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, June 2010. [RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol @@ -639,11 +621,11 @@ Mach(Guoyi) Chen Huawei Technologies China Email: mach.chen@huawei.com Manav Bhatia Alcatel-Lucent India - Email: manav.bhatia@alcatel-lucent.com + Email: manavbhatia@gmail.com