idnits 2.17.1 draft-bhatia-karp-short-lived-keys-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 16, 2011) is 4730 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-karp-crypto-key-table-00 == Outdated reference: A later version (-10) exists of draft-ietf-karp-design-guide-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bhatia 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track April 16, 2011 5 Expires: October 18, 2011 7 Using short-lived traffic keys for Routing Protocols 8 draft-bhatia-karp-short-lived-keys-00 10 Abstract 12 This draft proposes a generic mechanism for deriving short-lived 13 traffic keys from the longed-lived keys. The long-lived key could be 14 a preshared secret or a key obtained from some key management 15 protocol. The mechanism described in this draft can be used to 16 implement key rollovers without requiring the participating routers 17 to exchange any additional information. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 18, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Design Considerations . . . . . . . . . . . . . . . . . . . . . 3 61 3. Session Specific Value fed into the KDF . . . . . . . . . . . . 4 62 4. Exchanging the Nonce . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. Generating a Key based on Peer's Nonce . . . . . . . . . . 5 64 4.2. Generating a Key based on your own Nonce . . . . . . . . . 5 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 [I-D.ietf-karp-design-guide] describes why the cryptographic keys 76 must be periodically changed for greater security. These should be 77 changed when an operator who had access to them leaves. It is known 78 that using the key chains also does not help as one still has to 79 change all the keys in the key chain when an operator having access 80 to all those keys leaves the company. Another threat against the 81 long-lived key is that one of the systems storing the key, or one of 82 the users entrusted with the key, will be subverted. So, while there 83 may not be cryptographic motivations for changing the keys, there 84 could be systems security motivations for doing the same. 86 On the other hand, where manual key distribution methods are subject 87 to human error and frailty, more frequent key changes might actually 88 increase the risk of exposure as it is during the time that the keys 89 are being changed that they are likely to get disclosed. In these 90 cases, especially when very strong cryptography is employed, it may 91 be more prudent to have fewer, well controlled manual key 92 distributions rather than more frequent, poorly controlled manual key 93 distributions. In general, where strong cryptography is employed, 94 physical, procedural, and logical access protection considerations 95 often have more impact on the key life than do algorithm and key size 96 factors. 98 For incremental deployments [I-D.ietf-karp-design-guide] suggests 99 associating life times with the send and the receive keys in the key 100 chain for the long-lived keys. This is an incremental approach that 101 we could use till the cryptographic keying material for individual 102 sessions is derived from the keying material stored in the database 103 of long-lived cryptographic keys as described in 104 [I-D.ietf-karp-crypto-key-table]. A key derivation function (KDF) 105 and its inputs are specified in the database of long-lived 106 cryptographic keys and session specific values based on the routing 107 protocol are input to the KDF. This document describes how the 108 routing protocols can use session specific values that can be fed 109 into the KDF to derive a short-lived traffic key that the routing 110 protocols can use. 112 2. Design Considerations 114 It is desired that the algorithm be such that if even if an attacker 115 is aware of the long-lived key, guessing the short-lived traffic key 116 that will be generated next should not be possible. This directly 117 implies that the session specific values used by the routing 118 protocols should not be deterministic and predictible. 120 Thus for instance choosing the Router ID is a bad example of a 121 session specific value as this is deterministic and will not change 122 with time and upon router cold restarts. Ideally, it should be a 123 value that can be easily changed whenever the operators requires and 124 must never be the same upon successive cold restarts. 126 Changing the session specific value would lead to a change in the 127 short-lived key as its this thats fed into the KDF along with the 128 long-lived key. Thus traffic key rollover can be easily implemented 129 by passing the new session specific values. This means that changing 130 the traffic keys is directly dependent upon the ease with which the 131 session specific parameters can be generated, changed and exchanged. 133 There are two ways to exchange the session specific values between 134 the peers. One is to use a new key management protocol that does 135 this. The other is to keep this control with the routing protocols 136 that want to use these short-lived keys. This document goes with the 137 second approach as it is belived that the key management protocol 138 will be used for exchanging the long-lived keys and the onus lies on 139 the routing protocols or some other entity to provide the material 140 that will be fed to the KDF to generate the short-lived traffic keys. 142 3. Session Specific Value fed into the KDF 144 This document proposes a simple extension to the routing protocols 145 where a Nonce (really nothing more than a random number) is mixed 146 with the longed-lived key, fed into the KDF to derive a short-lived 147 key. Since the Nonce is a random, unsigned 32 - 64 bits number, it 148 can be easily generated and exchanged between the peers. Its 149 unpredictible and will never be the same upon router cold restarts. 150 It thus fullfills all the requirements listed in the preceeding 151 section. 153 4. Exchanging the Nonce 155 There are two ways to generate the short-lived traffic key that will 156 be used to authenticate the protocol packets. It is assumed that the 157 routers have a long-lived cryptographic key that was either exchanged 158 manually or was exchanged using an automated key management protocol. 160 This document uses OSPF [RFC2328] as an example to illustrate how the 161 mechanism will work. This however, is a generic mechanism and will 162 work for other protocols as well. It might require a few tweaks here 163 and there, but the overall mechanism will remain the same. 165 4.1. Generating a Key based on Peer's Nonce 167 In this approach a router generates a short-lived traffic key based 168 on the Nonce that its peer router sends. 170 Each router generates a Nonce that is sent with the OSPF Hello 171 packets. Initially, each router uses the long-lived key to 172 authenticate the packet. It also uses a new Authentication Type that 173 will indicate that the packet is using a long-lived key to secure the 174 packet. The reciever, upon successfully authenticating the packet, 175 will use the Nonce thats carried in the packet to derive a short- 176 lived traffic key. It will use this traffic key to secure all 177 subsequent OSPF protocol packets. Since the Nonces generated by each 178 router would be different, the traffic keys derived would also be 179 different. Thus asymmetrical keys will be used for transmitting and 180 receiving the packets. Whenever a router uses the short-lived key, 181 it will indicate so in the protocol packets so that the reciever 182 knows what key to use when authenticating the incoming protocol 183 packets. Since the sender has derived the traffic key based on the 184 Nonce that the reciever had sent, the reciever can trivially 185 authenticate the packet. 187 While this scheme works very well when there are two routers speaking 188 to each other, it becomes slightly convoluted when you try to 189 implement this on a shared medium (local area network) where one 190 router could be speaking to multiple routers. Since this scheme 191 relies on generating the short-lived key based on what you recieve, 192 how would a router decide what traffic key to use when it recieves a 193 Nonce for multiple routers. We could decide on some complex 194 algorithm based on what the designated router (DR) on the LAN 195 announces, but that in my opinion will become needlessly complex as 196 we will have to keep the failure scenarios in mind when the DR goes 197 down and the backup designated router (BDR) takes over. Instead, we 198 can use the other approach that is described in the following 199 section. 201 4.2. Generating a Key based on your own Nonce 203 In this approach a router generates a short-lived traffic key based 204 on the Nonce that it generates. 206 Each router generates a Nonce that is sent in the OSPF Hello packets. 207 Initially, routers use a long-lived key to secure the packet. They 208 also use a new Authentication Type that indicates that the packet is 209 using a long-lived key to secure the packet. The reciever has to use 210 the challenge and response mechanism described in 211 [I-D.bhatia-karp-ospf-ip-layer-protection] to be really sure that its 212 speaking to a live router and not someone who is replaying the 213 packets from an earlier stale session. 215 Once the routers have verified that they are speaking to live, 216 legitimate peers they can each switch to using the short-lived key 217 derived from the Nonce that they have generated. The sender will 218 indicate in the protocol packet that it is using a traffic key 219 generated from the Nonce thats carried there. Since the Nonce is 220 carried in clear in the protocol packet, the reciever, is able to 221 constuct the traffic key as its also aware of the KDF and the long 222 lived key. The receiver thus uses the short-lived key for 223 authenticating the packets. 225 To generate a new short-lived traffic key the router has to generate 226 a new Nonce. Once thats verified using the mechanisms defined in 227 [I-D.bhatia-karp-ospf-ip-layer-protection] all routers will use the 228 new traffic key to authenticate the packets coming from this peer. 229 Thus session key rollover can be easily implemented. 231 5. Security Considerations 233 This document enhances the security of the routing protocols by 234 describing a mechanism that can be used to implement short-lived key 235 rollovers. 237 6. IANA Considerations 239 This draft places no request to IANA. 241 7. Acknowledgements 243 TBD 245 8. References 247 8.1. Normative References 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, March 1997. 252 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 254 8.2. Informative References 256 [I-D.bhatia-karp-ospf-ip-layer-protection] 257 Bhatia, M., Hartman, S., and D. Zhang, "Security Extension 258 for OSPFv2 when using Manual Key Management", 259 draft-bhatia-karp-ospf-ip-layer-protection-03 (work in 260 progress), February 2011. 262 [I-D.ietf-karp-crypto-key-table] 263 Housley, R. and T. Polk, "Database of Long-Lived Symmetric 264 Cryptographic Keys", draft-ietf-karp-crypto-key-table-00 265 (work in progress), November 2010. 267 [I-D.ietf-karp-design-guide] 268 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 269 Routing Protocols (KARP) Design Guidelines", 270 draft-ietf-karp-design-guide-02 (work in progress), 271 March 2011. 273 Author's Address 275 Manav Bhatia 276 Alcatel-Lucent 277 India 279 Email: manav.bhatia@alcatel-lucent.com