ENHANCED APPROACH FOR TRANSMISSION CONTROL PROTOCOL AUTHENTICATION OPTION (TCP-AO) WITH KEY MANAGEMENT PROTOCOLS (KMPS)

• US 20130024684A1
• Filed: 08/26/2011
• Published: 01/24/2013
• Est. Priority Date: 07/24/2011
• Status: Active Grant

• Current Assignee: Telefonaktiebolaget LM Ericsson
• Original Assignee: Telefonaktiebolaget LM Ericsson
• Inventors: Chunduri, Uma S., Tian, Albert Jining
• Granted Patent: US 8,843,737 B2
• Time in Patent Office: Days
• US Class Current: 713/151
• CPC Class Codes: H04L 63/061 for key exchange, e.g. in peer-to-peer networks cryptographic mechanisms or cryptographic arrangements for key agreement H04L9/0838
• CPC Class Codes: H04L 63/08 for authentication of entities cryptographic mechanisms or cryptographic arrangements for entity authentication H04L9/32
• CPC Class Codes: H04L 63/166 at the transport layer

Abstract

A network element supports Transmission Control Protocol Authentication Option (TCP-AO) with a Key Management Protocol (KMP) to authenticate TCP segments over a TCP session. The network element negotiates multiple traffic keys to authenticate TCP segments over a TCP session with a peer network element, and protects the TCP session with the negotiated traffic keys.

Claims

1. A method in a network element for supporting Transmission Control Protocol Authentication Option (TCP-AO) with a Key Management Protocol (KMP) to authenticate TCP segments over a TCP session, the method comprising the steps of:

negotiating a first plurality of traffic keys to authenticate TCP segments over a first TCP session with a peer network element; and

protecting the first TCP session with the first negotiated traffic keys.

2. The method of claim 1, wherein the first negotiated traffic keys include a send key used for authenticating outgoing TCP segments transmitted to the peer network element over the first TCP session and a receive key for authenticating incoming TCP segments received from the peer network element over the first TCP session.

3. The method of claim 2, further comprising the steps of:

setting the send key as a send_SYN_traffic_key and send_other_traffic_key; and

setting the receive key as a receive_SYN_traffic_key and receive_other_traffic_key.

4. The method of claim 1, further comprising the step of:

negotiating a lifetime of the first negotiated traffic keys.

5. The method of claim 4, further comprising the steps of:

negotiating a second plurality of traffic keys to authenticate TCP segments over a second TCP session with the peer network element; and

negotiating a lifetime of the second negotiated traffic keys, wherein the lifetime of the first negotiated traffic keys is different than the lifetime of the second negotiated traffic keys.

6. The method of claim 1, further comprising the step of:

negotiating an indication of a first Message Authentication Code (MAC) algorithm to use when protecting the first TCP session.

7. The method of claim 6, further comprising the steps of:

negotiating a second plurality of traffic keys to authenticate TCP segments over a second TCP session with the peer network element;

negotiating an indication of a second MAC algorithm to use when protecting the second TCP session, wherein the first MAC algorithm and second MAC algorithm are different; and

protecting the second TCP session with the negotiated second plurality of traffic keys.

8. The method of claim 7, wherein the first negotiated traffic keys are unique to the first TCP session and the second negotiated traffic keys are unique to the second TCP session.

9. A network element for supporting Transmission Control Protocol Authentication Option (TCP-AO) with a Key Management Protocol (KMP) to authenticate TCP segments over TCP sessions, comprising:

a set of one or more processors;

a non-transitory computer-readable medium that stores instructions for a computer program that supports TCP-AO with a KMP to authenticate TCP segments over TCP sessions, the computer program including;

an application configured to transmit and receive traffic over a set of one or more TCP sessions and request authentication of outgoing and incoming TCP segments for the set of TCP sessions;

a KMP module configured to, for each of the set of TCP sessions, perform the following;

negotiate a plurality of traffic keys with a peer network element, and

populate the negotiated traffic keys into a data structure used by a TCP-AO module when authenticating the outgoing and incoming TCP segments for that TCP session; and

the TCP-AO module configured to, for each of the set of TCP sessions, use the negotiated traffic keys for that TCP session for authenticating outgoing and incoming TCP segments of that TCP session.

10. The network element of claim 9, wherein the TCP-AO module is further configured to trigger the KMP module to negotiate, for each TCP session, the plurality of traffic keys for that TCP session.

11. The network element of claim 10, wherein the TCP-AO module is configured to trigger the KMP to negotiate the traffic keys by transmitting one or more of the following to the KMP module:

an IP address of the peer network element;

an indication that an extra Diffie-Helman key exchange is to be performed when negotiating the traffic keys;

an indication of a set of one or more Message Authentication Code (MAC) algorithms supported on the network element that can be used when authenticating outgoing and incoming TCP segments of that TCP session;

a lifetime of the plurality of traffic keys for that TCP session; and

a set of one or more identifiers for that TCP session.

12. The network element of claim 9, wherein the plurality of traffic keys for each TCP session include,

a send key that the TCP-AO module is configured to use for authenticating outgoing TCP segments transmitted to the peer network element over that TCP session, and

a receive key that the TCP-AO module is configured to use for authenticating incoming segments received over that TCP session.

13. The network element of claim 12, wherein the KMP module is further configured to, for each of the set of TCP sessions, populate the send key as a send_SYN_traffic key and send_other_traffic_key and populate the receive key as a receive_SYN_traffic_key and receive_other_traffic key into the data structure.

14. The network element of claim 9, wherein the KMP module is further configured to, for each of the set of TCP sessions, negotiate an indication of a Message Authentication Code (MAC) algorithm used by the TCP-AO module when authenticating outgoing and incoming TCP segments of that TCP session.

15. The network element of claim 9, wherein the KMP module is further configured to, for each of the set of TCP sessions, negotiate a lifetime of the plurality of traffic keys for that TCP session.

16. The network element of claim 9, wherein for each of the set of TCP sessions, the negotiated traffic keys are unique.

17. The network element of claim 9, wherein the application is a TCP application.

18. A network element for supporting Transmission Control Protocol Authentication Option (TCP-AO) with a Key Management Protocol (KMP) to authenticate TCP segments over TCP sessions, comprising:

a set of one or more processors; and

a non-transitory computer-readable medium that stores instructions that, when executed by the set of processors, cause the set of processors to perform operations including;

negotiating a first plurality of traffic keys to authenticate TCP segments over a first TCP session with a peer network element; and

protecting the first TCP session with the first negotiated traffic keys.

19. The network element of claim 18, wherein the first negotiated traffic keys include a send key used for authenticating outgoing TCP segments transmitted to the peer network element over the first TCP session and a receive key for authenticating incoming TCP segments received from the peer network element over the first TCP session.

20. The network element of claim 19, wherein the non-transitory computer-readable medium further stores instructions that, when executed by the set of processors, cause the set of processors to perform operations including:

setting the send key as a send_SYN_traffic_key and send_other_traffic_key; and

setting the receive key as a receive_SYN_traffic_key and receive_other_traffic_key.

21. The network element of claim 18, wherein the non-transitory computer-readable medium further stores instructions that, when executed by the set of processors, cause the set of processors to perform operations including:

negotiate a lifetime of the first negotiated traffic keys.

22. The network element of claim 21, wherein the non-transitory computer-readable medium further stores instructions that, when executed by the set of processors, cause the set of processors to perform operations including:

negotiate a second plurality of traffic keys to authenticate TCP segments over a second TCP session with the peer network element; and

negotiate a lifetime of the second negotiated traffic keys, wherein the lifetime of the first negotiated traffic keys is different than the lifetime of the second negotiated traffic keys.

23. The network element of claim 18, wherein the non-transitory computer-readable medium further stores instructions that, when executed by the set of processors, cause the set of processors to perform operations including:

negotiating an indication of a first Message Authentication Code (MAC) algorithm to use when protecting the first TCP session.

24. The network element of claim 23, wherein the non-transitory computer-readable medium further stores instructions that, when executed by the set of processors, cause the set of processors to perform operations including:

negotiating a second plurality of traffic keys to authenticate TCP segments over a second TCP session with the peer network element;

negotiating an indication of a second MAC algorithm to use when protecting the second TCP session, wherein the first MAC algorithm and second MAC algorithm are different; and

protecting the second TCP session with the negotiated second plurality of traffic keys.

25. The network element of claim 24, wherein the first negotiated traffic keys are unique to the first TCP session and the second negotiated traffic keys are unique to the second TCP session.