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]