idnits 2.17.1 draft-polk-saag-rtg-auth-keytable-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 == Line 296 has weird spacing: '...FInputs non...' == Line 299 has weird spacing: '...rection bot...' == Line 311 has weird spacing: '...FInputs non...' == Line 314 has weird spacing: '...rection bot...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (26 October 2009) is 5295 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-housley-saag-crypto-key-table-00 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT T. Polk 3 Intended Status: Informational NIST 4 R. Housley 5 Vigil Security 6 Expires: 29 April 2010 26 October 2009 8 Routing Authentication Using A Database of Long-Lived Cryptographic Keys 9 draft-polk-saag-rtg-auth-keytable-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document describes the application of a database of long-lived 35 cryptographic keys to establish session-specific cryptographic keys 36 to support authentication services in routing protocols. Keys may be 37 established between two peers for pair-wise communications, or 38 between groups of peers for multicast traffic. 40 Table of Contents 42 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 43 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2 44 2 Architecture and Design . . . . . . . . . . . . . . . . . . . . . 2 45 3 Pair-wise Application . . . . . . . . . . . . . . . . . . . . . . 3 46 4 Identifier Mapping . . . . . . . . . . . . . . . . . . . . . . . 5 47 4.1 Selected Range Reservation . . . . . . . . . . . . . . . . . 6 48 4.2 Protocol Specific Mapping Tables . . . . . . . . . . . . . . 6 49 5 Worked Example: TCP-AO . . . . . . . . . . . . . . . . . . . . . 6 50 5.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 51 5.2 Protocol Operation: Xp Initiates a Connection . . . . . . . 8 52 5.3 Protocol Operation: Yp Initiates a Connection . . . . . . . 8 53 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 54 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 55 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 7.1 Normative References . . . . . . . . . . . . . . . . . . . 9 57 7.2 Informative References . . . . . . . . . . . . . . . . . . 9 58 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 59 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 11 61 1 Introduction 63 This document describes the application of a database of long-lived 64 cryptographic keys, as defined in [KEYTAB], to establish session- 65 specific cryptographic keys to provide authentication services in 66 routing protocols. Keys may be established between two peers for 67 pair-wise communications, or between groups of peers for multicast 68 traffic. 70 1.1 Terminology 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119 [RFC2119]. 76 2 Architecture and Design 77 Figure 1 illustrates the establishment and use of cryptographic keys 78 for authentication in routing protocols. Long-lived cryptographic 79 keys are inserted in a database manually. In the future, we 80 anticipate an automated key management protocol to insert these keys 81 in the database. In this future environment, we do not anticipate an 82 environment where the automated key management protocol will be used 83 to create short-lived cryptographic session keys. The structure of 84 the database of long-lived cryptographic keys is described in 85 [KEYTAB]. 87 The cryptographic keying material for individual sessions is derived 88 from the keying material stored in the database of long-lived 89 cryptographic keys. A key derivation function (KDF) and its inputs 90 are named in the database of long-lived cryptographic keys; session 91 specific values based on the routing protocol are input the the KDF. 92 Protocol specific key identifiers may be assigned to the 93 cryptographic keying material for individual sessions if needed. 95 +--------------+ +----------------+ 96 | | | | 97 | Manual Key | | Automated Key | 98 | Installation | | Mgmt. Protocol | 99 | | | | 100 +------+-------+ +--+----------+--+ 101 | | | 102 | | | 103 V V |<== Not expected for security 104 +------------------------+ | of routing protocols, but 105 | | | often used in other 106 | Long-lived Crypto Keys | | protocol environments 107 | | | like IPsec and TLS. 108 +------------+-----------+ | 109 | | 110 | | 111 V V 112 +---------------------------------+ 113 | | 114 | Short-lived Crypto Session Keys | 115 | | 116 +---------------------------------+ 118 Figure 1. Cryptographic key establishment and use. 120 3 Pair-wise Application 122 Figure 2 illustrates how the long-lived cryptographic keys are 123 accessed and employed when an entity wishes to establish a protected 124 session with a peer. As one step in the initiation process, the 125 intitator requests the set of long term keys associated with the peer 126 for the particular protocol. If the set contains more than one key, 127 the initiator selects one long-term key based on the local policy. 128 The long-term key is provided as an input, along with session- 129 specific information (e.g., ports or initial counters), to a key 130 derivation function. The result is session-specific key material 131 which is used to generate cryptographic authentication. 133 Where the initiator is establishing a multicast session, the Peer in 134 the key request identifies the set of systems that will receive this 135 information. 137 +-------------------------+ 138 | | 139 | Long-Lived | 140 | Crypto Keys | 141 | | 142 +-+---------------------+-+ 143 ^ | 144 | | 145 | V 146 +-------+-------+ +-------+-------+ 147 | | | | 148 | Lookup Keys | | Select Key | 149 | By Peer | | By Policy | 150 | and Protocol | | | 151 | | +-------+-------+ 152 +-------+-------+ | 153 ^ | 154 | V 155 | +-------+-------+ 156 | | | 157 | | Session Key | 158 | | Derivation | 159 | | | 160 | +-------+-------+ 161 | | 162 | | 163 +-------+-------+ V 164 | | +-------+-------+ 165 | Initiate | | | 166 | Session | |Authentication | 167 | with Peer | | Mechanism | 168 | | | | 169 +---------------+ +---------------+ 171 Figure 3 illustrates how an entity that receives a session generates 172 the necessary long-lived cryptographic keys to verify data when a 173 protected session is requested. As step one in the initiation 174 process, the receiver extracts the keyID for the long-term keyID from 175 the received data. The receiver then requests the specified long- 176 term key from the table. The long-term key is provided as an input, 177 along with session-specific information (e.g., ports or initial 178 counters), to a key derivation function. The result is session- 179 specific key material which is used to verify the cryptographic 180 authentication information. 182 +-------------------------+ 183 | | 184 | Long-Lived | 185 | Crypto Keys | 186 | | 187 +-+---------------------+-+ 188 ^ | 189 | | 190 | V 191 +-------+-------+ +-------+-------+ 192 | | | | 193 | Lookup Key | | Session Key | 194 | By KeyID | | Derivation | 195 | | | | 196 +-------+-------+ +-------+-------+ 197 ^ | 198 | | 199 | V 200 +-------+-------+ +-------+-------+ 201 | | | | 202 | Receive Data | |Authentication | 203 | From Peer | | Mechanism | 204 | | | | 205 +---------------+ +---------------+ 207 4 Identifier Mapping 209 [KEYTAB] specifies a 16-bit identifier, but protocols already exist 210 with key identifiers of various sizes. Where the identifiers are of 211 different sizes, an extra mapping step may be required. Note that 212 mapping mechanisms are local - that is, different mapping mechanisms 213 could be employed on different peers. 215 In practice, the mapping process need only be applied to the 216 LocalKeyID, whose value must be unique in the context of the 217 database, as defined in [KEYTAB]. Uniqueness is not required for the 218 PeerKeyID, so mapping is generally restricted to truncation. Mapping 219 would only be needed to expand PererKeyID's value beyond 16 bits. 221 4.1 Selected Range Reservation 223 Where a protocol uses an index of less than 16 bits, a selected range 224 of the local index space can be reserved for a particular protocol. 225 For example, consider two protocols P1 and P2 that each use 8 bit key 226 identifiers. Without identifier mapping these protocols would share 227 the space {0x0000 through 0x00ff} which would limit the pair of 228 protocols to 256 keys in total. By reserving the ranges {0x7f00 229 through 0x7fff} and {0x7e00 through 0x7eff} for P1 and P2 230 respectively permits each protocol to use the full 256 key 231 identifiers and establishes an unambiguous mapping for the protocol 232 key identifiers and local table identifiers. 234 When an initiator selects a key from the set in the table, the given 235 key identifier needs to be masked or shifted to the on-the-wire 236 range. Before requesting a specific key, the receiver would use a 237 shim layer would need to map the on-the-wire identifier into the 238 reserved range. 240 4.2 Protocol Specific Mapping Tables 242 Each protocol can also maintain a simple mapping table with two 243 fields: the l6 bit index and the protocol specific value 245 KEYTAB index (16 bits) | Protocol specific index (8 bits) 247 In this case, the host system would maintain separate mapping tables 248 for protocols P1 and P2. 250 5 Worked Example: TCP-AO 252 This section describes the way a TCP-AO implementation could use the 253 database. [tcpao] TCP-AO protocol is an example where the key 254 identifier is limited to 8 bits, so an identifier mapping is needed. 256 We will assume two peers Xp and Yp. Xp employs the range reservation 257 method for mapping and has reserved the range {0x7f00 ... 0x7fff} for 258 LocalKeyIDs for TCP-AO, mapping to {0x00 ... 0xff}. Yp employs a 259 protocol specific mapping table in its TCP-AO implementation. 261 The following subsections describe how peers Xp and Yp make use of 262 the database of long-lived cryptographic keys when Xp and Yp 263 respectively initiate a session. (Note: Rollover to new sessions 264 keys during a session is described in [tcpao].) 266 5.1 Setup 267 The owners of Xp and Yp determine a need for authenticated 268 communication using TCP-AO. They decide to use AES-CMAC-128 for 269 authentication, so a 128 bit key is needed. They decide to use the 270 same key for both directions (inbound and outbound), and that the key 271 will be available from 12/31/2010 through 12/31/2011. Through an out- 272 of-band channel, the administrators establish the shared secret: 273 0x0123456789ABCDEF0123456789ABCDEF 274 Peer Xp selects the first available TCP-AO identifier in the reserved 275 range, which is 0x7f05 and maps to an eight bit identifier 0x05. 276 Peer Yp selects the next available TCP-AO identifier, 0x12, and the 277 next available LocalKeyID, which is 0x0107. Peer Yp also adds an 278 entry to its TCP-AO mapping table mapping the LocalKeyID to the TCP- 279 AO identifier, as shown in Figure 5: 281 LocalKeyID TCP-AO identifier 282 -------------------------------- 283 0x001a | 0x01 284 0x004d | 0x02 285 ... ... 286 0x0107 | 0x12 288 Figure 5. Protocol Specific KeyID Mapping Table for TCP-AO 290 After exchanging the TCP-AO identifiers, the peers have sufficient 291 information to establish their [KEYTAB] entries. Peer Xp's [KEYTAB] 292 entry is shown as Figure 6: 294 LocalKeyID 0x7f05 295 PeerKeyID 0x0012 296 KDFInputs none 297 AlgID AES-CMAC-128 298 Key 0x0123456789ABCDEF0123456789ABCDEF 299 Direction both 300 NotBefore 12/31/2010 301 NotAfter 12/31/2011 302 Peers yp.example.com 303 Protocol TCP-AO 305 Figure 6. Key Table Entry on Xp 307 Peer Yp's [KEYTAB] entry is shown as Figure 6: 309 LocalKeyID 0x0107 310 PeerKeyID 0x0005 311 KDFInputs none 312 AlgID AES-CMAC-128 313 Key 0x0123456789ABCDEF0123456789ABCDEF 314 Direction both 315 NotBefore 12/31/2010 316 NotAfter 12/31/2011 317 Peers xp.example.com 318 Protocol TCP-AO 320 Figure 7. Key Table Entry on Yp 322 5.2 Protocol Operation: Xp Initiates a Connection 324 Peer Xp wishes to initiate a connection with Peer Yp. 326 (1) Xp performs a key lookup for {Peer=Yp, Protocol=TCP-AO}, and the 327 entry with LocalKeyID 0x7f05 is returned. 328 (2) The LocalKeyID 0x7f05 is range mapped by Xp to the TCP-AO 329 identifier 0x05. 330 (3) Xp performs the session key derivation using the mechanism 331 specified for the TCP-AO protocol in [ao-crypto]. 332 (4) Xp generates the AES-CMAC-128 MACs for the outgoing traffic using 333 the derived key, and asserts the key identifier 0x05 in the packets. 334 (5) Yp receives a protected packet from Xp, and extracts the key 335 identifier 0x05. 336 (6) Yp performs a a key lookup for {Peer=Xp, Protocol=TCP-AO, 337 PeerKeyID=0x05}, and the entry with LocalKeyID 0x0107 is returned. 338 (7) Yp performs the session key derivation using the mechanism 339 specified for the TCP-AO protocol in [ao-crypto]. 340 (8) Yp verifies the MACs for the incoming traffic using the derived 341 key. 343 5.3 Protocol Operation: Yp Initiates a Connection 345 Where Peer Yp establishes the connection, the same process is 346 followed, except that range mapping process from step (2) is replaced 347 by a table lookup. 349 6 Security Considerations 351 353 6 IANA Considerations 355 This document requires no actions by IANA. 357 7 References 359 7.1 Normative References 361 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, March 1997. 364 [KEYTAB] R. Housley and Polk, T. "Database of Long-Lived 365 Cryptographic Keys", draft-housley-saag-crypto-key-table- 366 00.txt, September 2009. 368 7.2 Informative References 370 [tcpao] J. Touch, Mankin A., and Bonica R. "The TCP Authentication 371 Option", draft-ietf-tcpm-tcp-auth-opt-05.txt, July 2009. 373 [ao-crypto] Lebovitz, G., "Cryptographic Algorithms, Use, & 374 Implementation Requirments for TCP Authentication 375 Option", draft-lebovitz-ietf-tcpm-tcp-ao-crypto-02.txt, 376 July 2009. 378 Author's Addresses 380 Tim Polk 381 National Institute of Standards and Technology 382 100 Bureau Drive, Mail Stop 8930 383 Gaithersburg, MD 20899-8930 384 USA 385 EMail: tim.polk@nist.gov 387 Russell Housley 388 Vigil Security, LLC 389 918 Spring Knoll Drive 390 Herndon, VA 20170 391 USA 392 EMail: housley@vigilsec.com 394 Full Copyright Statement 396 Copyright (c) 2009 IETF Trust and the persons identified as the 397 document authors. All rights reserved. 399 This document is subject to BCP 78 and the IETF Trust's Legal 400 Provisions Relating to IETF Documents in effect on the date of 401 publication of this document (http://trustee.ietf.org/license-info). 402 Please review these documents carefully, as they describe your rights 403 and restrictions with respect to this document. 405 All IETF Documents and the information contained therein are provided 406 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 407 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 408 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 409 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 410 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 411 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 412 FOR A PARTICULAR PURPOSE.