Working Group U. Chunduri Internet-Draft A. Tian Intended status: Standards Track Ericsson Inc., Expires: April 26, 2012 October 24, 2011 TCP-AO extensions for KARP-KMP draft-chunduri-tcp-ao-extensions-for-karp-kmp-00 Abstract This document discusses the possible extensions for TCP Authentication Option (TCP-AO) to better integrate and maximize the benefits, when deployed with Key Management Protocols (KMPs). TCP-AO as defined in RFC5925 can obtain master key from KMP and uses a Key Derivation Function (KDF) to generate traffic keys to protect the TCP sessions. In this mode, not all the benefits from the KMP can be realized. This document introduces an alternative approach for TCP-AO that allows TCP-AO to realize all the operational and security benefits from the deployed KMP. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 April 26, 2012. Copyright Notice Copyright (c) 2011 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 carefully, as they describe your rights and restrictions with respect Chunduri & Tian Expires April 26, 2012 [Page 1] Internet-Draft TCP-AO extensions for KARP-KMP October 2011 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Current Approach: Obtaining Master Key from KMPs . . . . . . . 4 3. Limitations of the current approach with KMPs . . . . . . . . 4 3.1. Operational (non-security) Limitations . . . . . . . . . . 4 3.1.1. Parameter Negotiation . . . . . . . . . . . . . . . . 5 3.1.2. Re-authentication . . . . . . . . . . . . . . . . . . 5 3.2. Security Limitations . . . . . . . . . . . . . . . . . . . 5 3.2.1. Limited Randomness . . . . . . . . . . . . . . . . . . 5 3.2.2. Exposure and re-use of Master Key . . . . . . . . . . 6 4. Obtaining Traffic Keys from KMPs . . . . . . . . . . . . . . . 6 5. Changes required to use Traffic Keys from KMP . . . . . . . . 8 5.1. Key Trigger . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Authentication Algo and Traffic Keys Life time . . . . . . 9 5.3. Impact on application process restart or reboot . . . . . 9 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Chunduri & Tian Expires April 26, 2012 [Page 2] Internet-Draft TCP-AO extensions for KARP-KMP October 2011 1. Introduction TCP-AO [RFC5925] is a generic mechanism to protect tcp segments for long-lived BGP/LDP sessions, BGP route reflectors and any other client-server TCP applications. Since TCP-AO obtains master key from KMP and uses a specific Key Derivation Function (KDF) to generate traffic keys for TCP sessions, it will not be able to realize all the non-security as well as security benefits from a well rounded KMP. This is due to the common KDF interface as defined in TCP-AO, even with the KMP usage. This document discusses the potential restrictions with TCP-AO in Section 3, when deployed with Key Management Protocols (KMPs) and harmonize the proposed approach in Section 4 to minimize changes to both KMP and application/routing protocols. To be specific this document gives capability to negotiate and apply session specific parameters with TCP-AO, when multiple TCP session between the same endpoints are opened as described in [ietf-idr-bgp- multisession]. Also with the proposed approach, TCP sessions can be protected with stronger and more uniformly random traffic keys with out being limited by the session specific parameter randomness. Recent discussions on NAT traversal is likely to put more restrictions on KDF inputs for traffic key generation. Lastly, this document analyze the consequences of out-of-band master key compromise, generated by KMP and how this leads to session compromise when the same more exposed master key is re-used for traffic key generation for multiple sessions. A simple solution that allows TCP-AO to directly obtain traffic keys, negotiated key life time, authentication algorithm from KMPs in Section 4 is discussed. The proposed solution is intended to minimize the changes required in application protocols, KMPs and allows seamless integration with TCP-AO. In the end, the cost of these extensions is discussed in Section 5. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2. Acronyms Chunduri & Tian Expires April 26, 2012 [Page 3] Internet-Draft TCP-AO extensions for KARP-KMP October 2011 AKM - Auto Key Management DIP - Destination IP Address EAP - Extensible Authentication Protocol IKE - Internet Key Exchange ISN - Initial Sequence Number KDF - Key Derivation Function KMP - Key Management Protocol (auto key management) MKM - Manual Key management Protocols MKT - Master Key Tuple MSK - Master Session Key NONCE - Number Once SIP - Source IP Address TCP-AO - TCP Authentication Option 2. Current Approach: Obtaining Master Key from KMPs When the number of connections increase, KMPs provide natural way to manage, rekey and distribute the keys to all the concerned systems in the network. Also per KARP WG and [ietf-karp-design-guide] KMPs are the preferred choice for routing protocols. Currently in TCP-AO [RFC5925], both manual and auto key management protocols populate the shared master key and other associated parameters in the MKT. Then using pre-defined KDFs in MKT and session specific parameters, traffic keys are generated to protect the TCP session. 3. Limitations of the current approach with KMPs This section discusses the potential limitations to current TCP-AO standard when deployed with key management protocols. 3.1. Operational (non-security) Limitations Chunduri & Tian Expires April 26, 2012 [Page 4] Internet-Draft TCP-AO extensions for KARP-KMP October 2011 3.1.1. Parameter Negotiation Sec 5.3 TCP-AO [RFC5925] states - "TCP-AO does not provide a mechanism for traffic key negotiation or parameter negotiation (MAC algorithm, length, or use of TCP-AO on a connection), or for coordinating rekeying during a connection. We assume out-of-band mechanisms for MKT establishment, parameter negotiation, and rekeying." But even with out-of-band mechanisms for MKT establishment, if MKT is re-used to protect multiple sessions as possible and specified in [ietf-idr-bgp-multisession], parameter negotiation/configuration (E.g. rekey lifetime) specific to particular session is not possible. 3.1.2. Re-authentication For long-lived TCP session per sec 5.3.2 and sec 6 TCP-AO [RFC5925], to change the traffic keys new MKT is required, in other words new shared master key must be negotiated. This approach could be inefficient because master key negotiation is not only computationally expensive and also need more message exchanges to do full re-authentication when there is no concern in the long term credentials of the parties involved. What is needed here is only re- negotiation of the traffic key. The above claim assumes master key defined in TCP-AO is similar to the master shared key in KMP (E.g. authenticated DH shared secret in IKE) which is used to generated traffic keys. But, one can re-define the KMP specification to one of the traffic keys of the KMP as TCP-AO master key and this require changes to the established KMP in question. 3.2. Security Limitations 3.2.1. Limited Randomness Sec 6 of [touch-tcp-ao-nat], discusses the randomness surrounding KDF inputs for generating traffic keys and in some cases traffic key randomness purely dominated by randomness of ISNs alone. As pointed out, this can be potential issue if multiple traffic keys are derived from the same MKT/master key and freshness of the traffic keys can't be guaranteed. KMPs e.g., [RFC5996] have even further restrictions on the length and quality of the random number to be used for key generations. Section 2.10 of RFC5996 [RFC5996] says "...These nonces are used to add freshness to the key derivation technique used to obtain keys for Child SA, and to ensure creation of strong pseudorandom bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST be randomly chosen, Chunduri & Tian Expires April 26, 2012 [Page 5] Internet-Draft TCP-AO extensions for KARP-KMP October 2011 MUST be at least 128 bits in size, and MUST be at least half the key size of the negotiated pseudorandom function (PRF)...". It is not possible to meet the above requirements of KMP, if traffic keys generated as specified in Section 3.2 of TCP-AO [RFC5925]. 3.2.2. Exposure and re-use of Master Key Sec 3.1 TCP-AO [RFC5925], specifies MKTs with all parameters including master key are provisioned manually or by external protocols. As per TCP-AO, even with KMP deployment traffic key parameters (Source/destination address, ports and ISNs) are exchanged in plain (un-encrypted) as part of the TCP control traffic. Then using shared master key in MKT, unique traffic keys are derived for all the sessions between the same end points and also for new traffic keys for any restarted session as specified in Sec 5.3.1 TCP-AO [RFC5925], between the endpoints. The problematic part here is keying material to generate the traffic keys are exchanged with no privacy. Any re-use of master key for long-lived sessions give attacker access to all the traffic keys should out-of-band master key compromise happen because of extraction from a router or by a threat as specified in [ietf-karp-threats-reqs] from terminated/turned employee. Therefore with the existing approach, an attacker with compromised master key can easily derive the traffic keys used for protecting all current and future TCP sessions. 4. Obtaining Traffic Keys from KMPs This document proposes and analyzes a direct way to obtain the traffic keys and the negotiated life time of these keys, authentication algorithm from KMPs with no additional KDF, when KMP is used. In other words, when TCP-AO is used with KMPs, traffic keys MUST be generated and populated in MKTs by the KMPs and SHALL be used directly to protect TCP sessions without going through additional KDF. Instead of shared master key, MKTs will have KMP negotiated traffic keys on the already established secure channel with the peer. This approach inherently immune to replay attacks as new crypto quality NONCE is used every time new traffic key pair is negotiated. Manual key deployments will continue to have the existing mechanism of having master key in MKT, as suggested in current TCP-AO standard. By letting Key Management Protocols generate the traffic keys, TCP-AO can inherit all the properties of KMP. It is important to note all Chunduri & Tian Expires April 26, 2012 [Page 6] Internet-Draft TCP-AO extensions for KARP-KMP October 2011 the perceived advantages can be realized by the proposed approach, only if right KMP with appropriate feature set is chosen. To summarize the benefits: o Granular Parameter Negotiation More granular negotiation of session specific parameters like crypto algorithm to protect the TCP session and life time of the traffic keys for particular session is possible for all the sessions shared by the same MKT/master key with the proposed approach. o Re-keying With the proposed approach, TCP-AO can benefit from more efficient use of rekeying as opposed to re-authentication, support provided by most KMPs with out re-defining master key in all KMPs (as being done currently for IKEv2 based KMP in KARP WG). If any existing protected session traffic key has to be changed, this can be done with out re-doing expensive negotiation of new master key through full authentication. o Stronger traffic keys With the proposed approach, it is possible to generate stronger and uniformly random traffic keys with out being limited by ISNs randomness. This is achieved by generating the NONCE meeting all requirements imposed by deployed KMP, on length of the random numbers and the cryptographic quality of the random numbers. o Secure traffic key material exchange KMPs in general, provide separation from shared master key and other keying materials used for integrity protection and encryption of the KMP message exchanges i.e., all KMP exchanges use the secure and private channel already established with the peer. If traffic keys are generated by KMPs by exchanging NONCE and session specific parameters securely, there is no exposure of mutually authenticated shared master key in MKTs. With this any out-of-band traffic key compromise is severely limited to the current traffic key duration and traffic keys negotiated for all new connections and restarted connections for the same peer will continue to be secure and unaffected. Authors recognize, it is not possible to completely mitigate the threat of terminated/turned employee as specified in [ietf- karp-threats-reqs]. This threat is abbreviated just by using KMP instead of manual keying method. This can even be further reduced by exchanging the traffic key material on secure channel with the proposed approach. It is important to note in this context, some KMPs for e.g., [RFC5996] can include extra Chunduri & Tian Expires April 26, 2012 [Page 7] Internet-Draft TCP-AO extensions for KARP-KMP October 2011 DH key exchange in the traffic key computation by completely not relying on the initial master key or to further secure the generation of traffic keys. Right KMP selection for particular deployment of TCP-AO and the type of mutual authentication methods used for getting shared master key by KMP is beyond the scope of this document. 5. Changes required to use Traffic Keys from KMP The main cost of this approach is changes needed to the current TCP-AO standard with KMP and keeping manual key management still intact. In summary this can be achieved by introducing the following changes: a. Two new fields KMP_send_key and KMP_receive_key will be added to MKT. They will be populated with KMP generated traffic keys. These new fields are initialized to all zeros when KMP is not in use. Since "Master Key" field is not used at the same time as KMP_send_key and KMP_receive_key, some optimization is possible in implementation. b. A new KDF function, KDF_DIRECT, will be introduced. With this new KDF, there will be no key computation for the following keys as defined in Sec 3.2 of TCP-AO [RFC5925], rather traffic keys will be directly assigned with the KMP supplied keys as: 1. Send_SYN_traffic_key = KMP_send_key 2. Send_other_traffic_key = KMP_send_key 3. Receive_SYN_traffic_key = KMP_receive_key 4. Receive_other_traffic_key = KMP_receive_key c. When MKT is created with KDF_DIRECT, application can also provision the configured authentication algorithms and configured key life time in the MKT. d. Sec 3.1 of TCP-AO [RFC5925], clearly mentions that, it does not specify how MKTs are created by users or processes. One way this can be achieved is by triggering the KMP with provisioned parameters in the MKT to get the traffic keys from KMP. This is applicable to brand new connections, restarted connections, as well as parallel connections between the peers. Session specific parameters need to be part of the trigger when new set of traffic keys to protect the session is requested. Chunduri & Tian Expires April 26, 2012 [Page 8] Internet-Draft TCP-AO extensions for KARP-KMP October 2011 e. A new field KMP_key_lifetime will be added to MKT. This will be populated with KMP negotiated life time of the traffic key. f. A new field KMP_auth_algo will be added to MKT. This will be populated with KMP negotiated authentication algorithm for protecting the TCP session. g. There is no change in MKT properties and Per-Connection TCP-AO Parameters. However, when KDF_DIRECT is used, we recommend each MKT SHALL correspond to only one TCP connection through the proper use of TCP connection identifier in the MKT. The above is an attempt to summarize the brief list of changes with the approach and this section will be revisited further. 5.1. Key Trigger When the first SYN packet on the session is initiated, a trigger to negotiate the session specific parameters with all provisioned authentication algorithms and optionally key lifetime SHOULD be given to KMP. Trigger may also be needed at the time of rekeying any particular session. This approach minimizes the changes at application/routing protocol to the point where these just need to create the MKT in TCP-AO with all configured parameters. 5.2. Authentication Algo and Traffic Keys Life time KMP negotiated authentication algorithm and optionally life time for traffic keys for each session, need to be populated in MKT. When the life time expires, these traffic keys and hence the MKT SHOULD not be used to protect the underlying TCP session any more. Implementations SHOULD pro-actively rekey new traffic keys before the life time expiry of current traffic keys. 5.3. Impact on application process restart or reboot With the proposed approach, there will be a delay in getting the traffic keys from KMP before sending the first protected TCP SYN packet, when application process is restarted. For most of the KMPs this can be a delay of one round trip and in some cases it could be just little more than a single round trip. In reboot scenario also for e.g., with BGP graceful restart [RFC4724] - even though remote side old connections can be closed much quicker, new traffic keys are required from KMP before initiating the new connection. In contrary, if BGP is deployed with out graceful restart procedure, one may not consider the extra KMP round trip delay for initiating new connection as remote side TCP connection Chunduri & Tian Expires April 26, 2012 [Page 9] Internet-Draft TCP-AO extensions for KARP-KMP October 2011 will stay up till BGP/TCP level keep alive mechanisms clear the old connection. 6. Conclusion The primary goal of this document is to provide awareness of the restrictions as specified in Section 3 for TCP-AO KMP deployments. Today even with right KMP is deployed with TCP-AO [RFC5925] all the benefits of KMPs are not realizable. Though all KMPs won't have the ability to derive traffic keys securely and independent to shared master key, with right KMP selection and with the proposed approach TCP-AO can inherit all KMP properties to derive traffic keys securely and more efficiently. Also with the proposed approach integration of KMP, as well as application protocols can be achieved with minimal changes at both ends and expedites the adoption of the KMP. 7. IANA Considerations This document defines no new namespaces. 8. Security Considerations This document analyzes and proposes remedy for KMP generated master key compromise as specified in Section 4. The proposed approach further minimizes the threat from terminated/turned employee as specified in [ietf-karp-threats-reqs] but still it is not possible to completely avoid the same with certain KMPs. This document will not introduce any new security concerns. There could be other KMP specific security issues viz., compromise of pre-shared key used for bootstrapping and authenticating the peer. This could enable an adversary to effect MITM attacks on the link where the compromised key is used. KMPs can mitigate this issue with public key authentication of the peer or authentication with selected EAP methods in conjunction with pre-shared keys. This document in no way can address other security concerns specific to particular KMP in question. 9. Acknowledgements The authors would like to thank Joel Halpern for providing valuable comments on the document and Ron Bonica for early discussions at Chunduri & Tian Expires April 26, 2012 [Page 10] Internet-Draft TCP-AO extensions for KARP-KMP October 2011 IETF81. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010. 10.2. Informative References [I-D.ietf-idr-bgp-multisession] Scudder, J., Appanna, C., and I. Varlashkin, "Multisession BGP", draft-ietf-idr-bgp-multisession-06 (work in progress), March 2011. [I-D.ietf-karp-design-guide] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", draft-ietf-karp-design-guide-02 (work in progress), March 2011. [I-D.ietf-karp-threats-reqs] Lebovitz, G., Bhatia, M., and R. White, "The Threat Analysis and Requirements for Cryptographic Authentication of Routing Protocols' Transports", draft-ietf-karp-threats-reqs-03 (work in progress), June 2011. [I-D.touch-tcp-ao-nat] Touch, J., "A TCP Authentication Option NAT Extension", draft-touch-tcp-ao-nat-02 (work in progress), March 2011. [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005. [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, January 2007. [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, June 2010. Chunduri & Tian Expires April 26, 2012 [Page 11] Internet-Draft TCP-AO extensions for KARP-KMP October 2011 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. Authors' Addresses Uma Chunduri Ericsson Inc., 300 Holger Way, San Jose, California 95134 USA Phone: 408 750-5678 Email: uma.chunduri@ericsson.com Albert Tian Ericsson Inc., 300 Holger Way, San Jose, California 95134 USA Phone: 408 750-5210 Email: albert.tian@ericsson.com Chunduri & Tian Expires April 26, 2012 [Page 12]