Internet DRAFT - draft-chunduri-tcp-ao-extensions-for-karp-kmp

draft-chunduri-tcp-ao-extensions-for-karp-kmp





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]