Key Coordination enhancement for TCP-AO
draft-duan-tcpm-tcp-ao-rekeying-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Shili Duan , Hongyan Wang , Yinxing Wei | ||
| Last updated | 2010-03-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
TCP-AO technology was proposed to obsolete the TCP-MD5 option which was developed to protect the BGP sessions between routers. Besides of allowing users to choose which cryptographic algorithm(s) they want to use to meet their security needs, TCP-AO provides key coordination mechanism giving the ability to move from one key to another within the same connection with zero segment loss by using two ID fields i.e. KeyID and RNextKeyID. The sender uses the RNextKeyID to indicate the receiver using the preferred MKT which will authenticate the next incoming segments. However, if the sender finds its MKT which is used to authenticate the outgoing segments has been attacked and should be changed into a new one, it can do nothing but wait for receiver to send a segment which carries a different RNextKeyID. In this case, the communication becomes dangerous probably because the sender always authenticates outgoing segments by an attacked key before the receiver wants to change the incoming key. This document provides a method giving the sender ability to inform the other part change the RNextKeyID when the sender finds the key used in outgoing segment is not safe any longer.
Authors
Shili Duan
Hongyan Wang
Yinxing Wei
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)