idnits 2.17.1 draft-polk-saag-rtg-auth-keytable-03.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 == Line 315 has weird spacing: '...FInputs non...' == Line 318 has weird spacing: '...rection bot...' == Line 330 has weird spacing: '...FInputs non...' == Line 333 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 (July 28, 2010) is 5021 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-02 Summary: 0 errors (**), 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: January 29, 2011 July 28, 2010 8 Routing Authentication Using A Database of Long-Lived Cryptographic Keys 9 draft-polk-saag-rtg-auth-keytable-03.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 Database Maintenance . . . . . . . . . . . . . . . . . . . . . . 6 50 6 Worked Example: TCP-AO . . . . . . . . . . . . . . . . . . . . . 6 51 6.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 52 6.2 Protocol Operation: Xp Initiates a Connection . . . . . . . 8 53 6.3 Protocol Operation: Yp Initiates a Connection . . . . . . . 8 54 7 Security Considerations . . . . . . . . . . . . . . . . . . . 10 55 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 56 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 57 9.1 Normative References . . . . . . . . . . . . . . . . . . 10 58 9.2 Informative References . . . . . . . . . . . . . . . . . 10 59 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 60 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 12 62 1 Introduction 64 This document describes the application of a database of long-lived 65 cryptographic keys, as defined in [KEYTAB], to establish session- 66 specific cryptographic keys to provide authentication services in 67 routing protocols. Keys may be established between two peers for 68 pair-wise communications, or between groups of peers for multicast 69 traffic. 71 1.1 Terminology 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [RFC2119]. 77 2 Architecture and Design 78 Figure 1 illustrates the establishment and use of cryptographic keys 79 for authentication in routing protocols. Long-lived cryptographic 80 keys are inserted in a database manually. In the future, we 81 anticipate an automated key management protocol to insert these keys 82 in the database. (While this future environment conceivably includes 83 automated key management protocols to negotiate short-lived 84 cryptographic session keys, such keys are out of scope for this 85 database.) The structure of the database of long-lived cryptographic 86 keys is described in [KEYTAB]. 88 The cryptographic keying material for individual sessions is derived 89 from the keying material stored in the database of long-lived 90 cryptographic keys. A key derivation function (KDF) and its inputs 91 are named in the database of long-lived cryptographic keys; session 92 specific values based on the routing protocol are input the the KDF. 93 Protocol specific key identifiers may be assigned to the 94 cryptographic keying material for individual sessions if needed. 96 +--------------+ +----------------+ 97 | | | | 98 | Manual Key | | Automated Key | 99 | Installation | | Mgmt. Protocol | 100 | | | | 101 +------+-------+ +--+----------+--+ 102 | | | 103 | | | 104 V V |<== Out of scope for this model. 105 +------------------------+ | Often used in other 106 | | | protocol environments 107 | Long-lived Crypto Keys | | like IPsec and TLS. 108 | | | 109 +------------+-----------+ | 110 | | 111 | | 112 V V 113 +---------------------------------+ 114 | | 115 | Short-lived Crypto Session Keys | 116 | | 117 +---------------------------------+ 119 Figure 1. Cryptographic key establishment and use. 121 3 Pair-wise Application 123 Figure 2 illustrates how the long-lived cryptographic keys are 124 accessed and employed when an entity wishes to establish a protected 125 session with a peer. As one step in the initiation process, the 126 initiator requests the set of long term keys associated with the peer 127 for the particular protocol. If the set contains more than one key, 128 the initiator selects one long-term key based on the local policy. 129 The long-term key is provided as an input, along with session- 130 specific information (e.g., ports or initial counters), to a key 131 derivation function. The result is session-specific key material 132 which is used to generate cryptographic authentication. 134 Where the initiator is establishing a multicast session, the Peer in 135 the key request identifies the set of systems that will receive this 136 information. 138 +-------------------------+ 139 | | 140 | Long-Lived | 141 | Crypto Keys | 142 | | 143 +-+---------------------+-+ 144 ^ | 145 | | 146 | V 147 +-------+-------+ +-------+-------+ 148 | | | | 149 | Lookup Keys | | Select Key | 150 | By Peer | | By Policy | 151 | and Protocol | | | 152 | | +-------+-------+ 153 +-------+-------+ | 154 ^ | 155 | V 156 | +-------+-------+ 157 | | | 158 | | Session Key | 159 | | Derivation | 160 | | | 161 | +-------+-------+ 162 | | 163 | | 164 +-------+-------+ V 165 | | +-------+-------+ 166 | Initiate | | | 167 | Session | |Authentication | 168 | with Peer | | Mechanism | 169 | | | | 170 +---------------+ +---------------+ 172 Figure 2. Session Initiation 174 Figure 3 illustrates how the long-lived cryptographic keys are 175 accessed and employed when an entity receives a request establish a 176 protected session with a peer. As step one in the session 177 establishment process, the receiver extracts the keyID for the long- 178 term keyID from the received data. The receiver then requests the 179 specified long-term key from the table. The long-term key is provided 180 as an input, along with session-specific information (e.g., ports or 181 initial counters), to a key derivation function. The result is 182 session-specific key material which is used to verify the 183 cryptographic authentication information. 185 +-------------------------+ 186 | | 187 | Long-Lived | 188 | Crypto Keys | 189 | | 190 +-+---------------------+-+ 191 ^ | 192 | | 193 | V 194 +-------+-------+ +-------+-------+ 195 | | | | 196 | Lookup Key | | Session Key | 197 | By KeyID | | Derivation | 198 | | | | 199 +-------+-------+ +-------+-------+ 200 ^ | 201 | | 202 | V 203 +-------+-------+ +-------+-------+ 204 | | | | 205 | Receive Data | |Authentication | 206 | From Peer | | Mechanism | 207 | | | | 208 +---------------+ +---------------+ 210 Figure 3. Session Acceptance 212 4 Identifier Mapping 214 [KEYTAB] specifies a 16-bit identifier, but protocols already exist 215 with key identifiers of various sizes. Where the identifiers are of 216 different sizes, an extra mapping step may be required. Note that 217 mapping mechanisms are local - that is, different mapping mechanisms 218 could be employed on different peers. 220 In practice, the mapping process need only be applied to the 221 LocalKeyID, whose value must be unique in the context of the 222 database, as defined in [KEYTAB]. Uniqueness is not required for the 223 PeerKeyID, so mapping is generally restricted to truncation. Mapping 224 would only be needed to expand PeerKeyID's value beyond 16 bits. 226 4.1 Selected Range Reservation 228 Where a protocol uses an index of less than 16 bits, a selected range 229 of the local index space can be reserved for a particular protocol. 230 For example, consider two protocols P1 and P2 that each use 8 bit key 231 identifiers. Without identifier mapping these protocols would share 232 the space {0x0000 through 0x00ff} which would limit the pair of 233 protocols to 256 keys in total. By reserving the ranges {0x7f00 234 through 0x7fff} and {0x7e00 through 0x7eff} for P1 and P2 235 respectively permits each protocol to use the full 256 key 236 identifiers and establishes an unambiguous mapping for the protocol 237 key identifiers and local table identifiers. 239 When an initiator selects a key from the set in the table, the given 240 key identifier needs to be masked or shifted to the on-the-wire 241 range. Before requesting a specific key, the receiver would use a 242 shim layer to map the on-the-wire identifier into the reserved range. 244 4.2 Protocol Specific Mapping Tables 246 Each protocol can also maintain a simple mapping table with two 247 fields: the 16 bit index and the protocol specific value: 249 KEYTAB index (16 bits) | Protocol specific index (8 bits) 251 In this case, the host system would maintain separate mapping tables 252 for protocols P1 and P2. 254 5 Database Maintenance 256 The previous sections focus upon installing and using the 257 cryptographic keys in the database. A mechanism or mechanisms to 258 remove unneeded keys is also needed to ensure that the key material 259 up-to-date. [KEYTAB] provides mechanisms for expiration of entries; 260 such key management could be performed in a fully automated fashion. 261 Other reasons for key removal, such as severing a business 262 relationship, or deciding a long lived key has been compromised 263 before its expiration date, would inherently require a manual key 264 removal process. 266 6 Worked Example: TCP-AO 268 This section describes the way a TCP-AO implementation could use the 269 database. [tcpao] TCP-AO protocol is an example where the key 270 identifier is limited to 8 bits, so an identifier mapping is needed. 272 We will assume two peers Xp and Yp. Xp employs the range reservation 273 method for mapping and has reserved the range {0x7f00 ... 0x7fff} for 274 LocalKeyIDs for TCP-AO, mapping to {0x00 ... 0xff}. Yp employs a 275 protocol specific mapping table in its TCP-AO implementation. 277 The following subsections describe how peers Xp and Yp make use of 278 the database of long-lived cryptographic keys when Xp and Yp 279 respectively initiate a session. (Note: Rollover to new sessions 280 keys during a session is described in [tcpao].) 282 6.1 Setup 284 The owners of Xp and Yp determine a need for authenticated 285 communication using TCP-AO. They decide to use AES-CMAC-128 for 286 authentication, so a 128 bit key is needed. They decide to use the 287 same key for both directions (inbound and outbound), and that the key 288 will be available from 12/31/2010 through 12/31/2011. Through an out- 289 of-band channel, the administrators establish the shared secret: 291 0x0123456789ABCDEF0123456789ABCDEF 293 Peer Xp selects the first available TCP-AO identifier in the reserved 294 range, which is 0x7f05 and maps to an eight-bit identifier 0x05. 295 Peer Yp selects the next available TCP-AO identifier, 0x12, and the 296 next available LocalKeyID, which is 0x0107. Peer Yp also adds an 297 entry to its TCP-AO mapping table mapping the LocalKeyID to the TCP- 298 AO identifier, as shown in Figure 5: 300 LocalKeyID TCP-AO identifier 301 -------------------------------- 302 0x001a | 0x01 303 0x004d | 0x02 304 ... ... 305 0x0107 | 0x12 307 Figure 5. Protocol Specific KeyID Mapping Table for TCP-AO 309 After exchanging the TCP-AO identifiers, the peers have sufficient 310 information to establish their [KEYTAB] entries. Peer Xp's [KEYTAB] 311 entry is shown as Figure 6: 313 LocalKeyID 0x7f05 314 PeerKeyID 0x0012 315 KDFInputs none 316 AlgID AES-CMAC-128 317 Key 0x0123456789ABCDEF0123456789ABCDEF 318 Direction both 319 NotBefore 12/31/2010 320 NotAfter 12/31/2011 321 Peers yp.example.com 322 Protocol TCP-AO 324 Figure 6. Key Table Entry on Xp 326 Peer Yp's [KEYTAB] entry is shown as Figure 6: 328 LocalKeyID 0x0107 329 PeerKeyID 0x0005 330 KDFInputs none 331 AlgID AES-CMAC-128 332 Key 0x0123456789ABCDEF0123456789ABCDEF 333 Direction both 334 NotBefore 12/31/2010 335 NotAfter 12/31/2011 336 Peers xp.example.com 337 Protocol TCP-AO 339 Figure 7. Key Table Entry on Yp 341 6.2 Protocol Operation: Xp Initiates a Connection 343 Peer Xp wishes to initiate a connection with Peer Yp. 345 (1) Xp performs a key lookup for {Peer=Yp, Protocol=TCP-AO}, and the 346 entry with LocalKeyID 0x7f05 is returned. 347 (2) The LocalKeyID 0x7f05 is range mapped by Xp to the TCP-AO 348 identifier 0x05. 349 (3) Xp performs the session key derivation using the mechanism 350 specified for the TCP-AO protocol in [ao-crypto]. 351 (4) Xp generates the AES-CMAC-128 MACs for the outgoing traffic using 352 the derived key, and asserts the key identifier 0x05 in the packets. 353 (5) Yp receives a protected packet from Xp, and extracts the key 354 identifier 0x05. 355 (6) Yp performs a a key lookup for {Peer=Xp, Protocol=TCP-AO, 356 PeerKeyID=0x05}, and the entry with LocalKeyID 0x0107 is returned. 357 (7) Yp performs the session key derivation using the mechanism 358 specified for the TCP-AO protocol in [ao-crypto]. 359 (8) Yp verifies the MACs for the incoming traffic using the derived 360 key. 362 6.3 Protocol Operation: Yp Initiates a Connection 364 Where Peer Yp establishes the connection, the same process is 365 followed, except that the range mapping process from step (2) is 366 replaced by a table lookup. 368 7 Security Considerations 370 372 8 IANA Considerations 374 This document requires no actions by IANA. 376 9 References 378 9.1 Normative References 380 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, March 1997. 383 [KEYTAB] R. Housley and Polk, T. "Database of Long-Lived 384 Cryptographic Keys", draft-housley-saag-crypto-key-table- 385 02.txt, September 2010. 387 9.2 Informative References 389 [tcpao] J. Touch, Mankin A., and Bonica R. "The TCP Authentication 390 Option", draft-ietf-tcpm-tcp-auth-opt-08.txt, October 391 2009. 393 [ao-crypto] Lebovitz, G., "Cryptographic Algorithms, Use, & 394 Implementation Requirments for TCP Authentication 395 Option", draft-lebovitz-ietf-tcpm-tcp-ao-crypto-02.txt, 396 July 2009. 398 Author's Addresses 400 Tim Polk 401 National Institute of Standards and Technology 402 100 Bureau Drive, Mail Stop 8930 403 Gaithersburg, MD 20899-8930 404 USA 405 EMail: tim.polk@nist.gov 407 Russell Housley 408 Vigil Security, LLC 409 918 Spring Knoll Drive 410 Herndon, VA 20170 411 USA 412 EMail: housley@vigilsec.com 414 Full Copyright Statement 416 Copyright (c) 2010 IETF Trust and the persons identified as the 417 document authors. All rights reserved. 419 This document is subject to BCP 78 and the IETF Trust's Legal 420 Provisions Relating to IETF Documents 421 (http://trustee.ietf.org/license-info) in effect on the date of 422 publication of this document. Please review these documents 423 carefully, as they describe your rights and restrictions with respect 424 to this document. 426 All IETF Documents and the information contained therein are provided 427 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 428 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 429 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 430 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 431 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 432 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 433 FOR A PARTICULAR PURPOSE.