Using short-lived traffic keys for Routing Protocols
draft-bhatia-karp-short-lived-keys-00

Abstract

This draft proposes a generic mechanism for deriving short-lived traffic keys from the longed-lived keys. The long-lived key could be a preshared secret or a key obtained from some key management protocol. The mechanism described in this draft can be used to implement key rollovers without requiring the participating routers to exchange any additional information.

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].

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 October 19, 2011.

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 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
• 2. Design Considerations
• 3. Session Specific Value fed into the KDF
• 4. Exchanging the Nonce
• 4.1. Generating a Key based on Peer's Nonce
• 4.2. Generating a Key based on your own Nonce
• 5. Security Considerations
• 6. IANA Considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Author's Address

1. Introduction

[I-D.ietf-karp-design-guide] describes why the cryptographic keys must be periodically changed for greater security. These should be changed when an operator who had access to them leaves. It is known that using the key chains also does not help as one still has to change all the keys in the key chain when an operator having access to all those keys leaves the company. Another threat against the long-lived key is that one of the systems storing the key, or one of the users entrusted with the key, will be subverted. So, while there may not be cryptographic motivations for changing the keys, there could be systems security motivations for doing the same.

On the other hand, where manual key distribution methods are subject to human error and frailty, more frequent key changes might actually increase the risk of exposure as it is during the time that the keys are being changed that they are likely to get disclosed. In these cases, especially when very strong cryptography is employed, it may be more prudent to have fewer, well controlled manual key distributions rather than more frequent, poorly controlled manual key distributions. In general, where strong cryptography is employed, physical, procedural, and logical access protection considerations often have more impact on the key life than do algorithm and key size factors.

For incremental deployments [I-D.ietf-karp-design-guide] suggests associating life times with the send and the receive keys in the key chain for the long-lived keys. This is an incremental approach that we could use till the cryptographic keying material for individual sessions is derived from the keying material stored in the database of long-lived cryptographic keys as described in [I-D.ietf-karp-crypto-key-table]. A key derivation function (KDF) and its inputs are specified in the database of long-lived cryptographic keys and session specific values based on the routing protocol are input to the KDF. This document describes how the routing protocols can use session specific values that can be fed into the KDF to derive a short-lived traffic key that the routing protocols can use.

2. Design Considerations

It is desired that the algorithm be such that if even if an attacker is aware of the long-lived key, guessing the short-lived traffic key that will be generated next should not be possible. This directly implies that the session specific values used by the routing protocols should not be deterministic and predictible.

Thus for instance choosing the Router ID is a bad example of a session specific value as this is deterministic and will not change with time and upon router cold restarts. Ideally, it should be a value that can be easily changed whenever the operators requires and must never be the same upon successive cold restarts.

Changing the session specific value would lead to a change in the short-lived key as its this thats fed into the KDF along with the long-lived key. Thus traffic key rollover can be easily implemented by passing the new session specific values. This means that changing the traffic keys is directly dependent upon the ease with which the session specific parameters can be generated, changed and exchanged.

There are two ways to exchange the session specific values between the peers. One is to use a new key management protocol that does this. The other is to keep this control with the routing protocols that want to use these short-lived keys. This document goes with the second approach as it is belived that the key management protocol will be used for exchanging the long-lived keys and the onus lies on the routing protocols or some other entity to provide the material that will be fed to the KDF to generate the short-lived traffic keys.

3. Session Specific Value fed into the KDF

This document proposes a simple extension to the routing protocols where a Nonce (really nothing more than a random number) is mixed with the longed-lived key, fed into the KDF to derive a short-lived key. Since the Nonce is a random, unsigned 32 - 64 bits number, it can be easily generated and exchanged between the peers. Its unpredictible and will never be the same upon router cold restarts. It thus fullfills all the requirements listed in the preceeding section.

4. Exchanging the Nonce

There are two ways to generate the short-lived traffic key that will be used to authenticate the protocol packets. It is assumed that the routers have a long-lived cryptographic key that was either exchanged manually or was exchanged using an automated key management protocol.

This document uses OSPF [RFC2328] as an example to illustrate how the mechanism will work. This however, is a generic mechanism and will work for other protocols as well. It might require a few tweaks here and there, but the overall mechanism will remain the same.

4.1. Generating a Key based on Peer's Nonce

In this approach a router generates a short-lived traffic key based on the Nonce that its peer router sends.

Each router generates a Nonce that is sent with the OSPF Hello packets. Initially, each router uses the long-lived key to authenticate the packet. It also uses a new Authentication Type that will indicate that the packet is using a long-lived key to secure the packet. The reciever, upon successfully authenticating the packet, will use the Nonce thats carried in the packet to derive a short-lived traffic key. It will use this traffic key to secure all subsequent OSPF protocol packets. Since the Nonces generated by each router would be different, the traffic keys derived would also be different. Thus asymmetrical keys will be used for transmitting and receiving the packets. Whenever a router uses the short-lived key, it will indicate so in the protocol packets so that the reciever knows what key to use when authenticating the incoming protocol packets. Since the sender has derived the traffic key based on the Nonce that the reciever had sent, the reciever can trivially authenticate the packet.

While this scheme works very well when there are two routers speaking to each other, it becomes slightly convoluted when you try to implement this on a shared medium (local area network) where one router could be speaking to multiple routers. Since this scheme relies on generating the short-lived key based on what you recieve, how would a router decide what traffic key to use when it recieves a Nonce for multiple routers. We could decide on some complex algorithm based on what the designated router (DR) on the LAN announces, but that in my opinion will become needlessly complex as we will have to keep the failure scenarios in mind when the DR goes down and the backup designated router (BDR) takes over. Instead, we can use the other approach that is described in the following section.

4.2. Generating a Key based on your own Nonce

In this approach a router generates a short-lived traffic key based on the Nonce that it generates.

Each router generates a Nonce that is sent in the OSPF Hello packets. Initially, routers use a long-lived key to secure the packet. They also use a new Authentication Type that indicates that the packet is using a long-lived key to secure the packet. The reciever has to use the challenge and response mechanism described in [I-D.bhatia-karp-ospf-ip-layer-protection] to be really sure that its speaking to a live router and not someone who is replaying the packets from an earlier stale session.

Once the routers have verified that they are speaking to live, legitimate peers they can each switch to using the short-lived key derived from the Nonce that they have generated. The sender will indicate in the protocol packet that it is using a traffic key generated from the Nonce thats carried there. Since the Nonce is carried in clear in the protocol packet, the reciever, is able to constuct the traffic key as its also aware of the KDF and the long lived key. The receiver thus uses the short-lived key for authenticating the packets.

To generate a new short-lived traffic key the router has to generate a new Nonce. Once thats verified using the mechanisms defined in [I-D.bhatia-karp-ospf-ip-layer-protection] all routers will use the new traffic key to authenticate the packets coming from this peer. Thus session key rollover can be easily implemented.

5. Security Considerations

This document enhances the security of the routing protocols by describing a mechanism that can be used to implement short-lived key rollovers.

6. IANA Considerations

This draft places no request to IANA.

7. Acknowledgements

TBD

8. References

8.1. Normative References

8.2. Informative References

Author's Address