idnits 2.17.1 draft-polk-saag-rtg-auth-keytable-02.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 299 has weird spacing: '...FInputs non...' == Line 302 has weird spacing: '...rection bot...' == Line 314 has weird spacing: '...FInputs non...' == Line 317 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 (4 December 2009) is 5256 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: 7 June 2010 4 December 2009 8 Routing Authentication Using A Database of Long-Lived Cryptographic Keys 9 draft-polk-saag-rtg-auth-keytable-02.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 2. Session Initiation 173 Figure 3 illustrates how the long-lived cryptographic keys are 174 accessed and employed when an entity receives a request establish a 175 protected session with a peer. As step one in the session 176 establishment process, the receiver extracts the keyID for the long- 177 term keyID from the received data. The receiver then requests the 178 specified long-term key from the table. The long-term key is provided 179 as an input, along with session-specific information (e.g., ports or 180 initial counters), to a key derivation function. The result is 181 session-specific key material which is used to verify the 182 cryptographic authentication information. 184 +-------------------------+ 185 | | 186 | Long-Lived | 187 | Crypto Keys | 188 | | 189 +-+---------------------+-+ 190 ^ | 191 | | 192 | V 193 +-------+-------+ +-------+-------+ 194 | | | | 195 | Lookup Key | | Session Key | 196 | By KeyID | | Derivation | 197 | | | | 198 +-------+-------+ +-------+-------+ 199 ^ | 200 | | 201 | V 202 +-------+-------+ +-------+-------+ 203 | | | | 204 | Receive Data | |Authentication | 205 | From Peer | | Mechanism | 206 | | | | 207 +---------------+ +---------------+ 209 Figure 3. Session Acceptance 211 4 Identifier Mapping 213 [KEYTAB] specifies a 16-bit identifier, but protocols already exist 214 with key identifiers of various sizes. Where the identifiers are of 215 different sizes, an extra mapping step may be required. Note that 216 mapping mechanisms are local - that is, different mapping mechanisms 217 could be employed on different peers. 219 In practice, the mapping process need only be applied to the 220 LocalKeyID, whose value must be unique in the context of the 221 database, as defined in [KEYTAB]. Uniqueness is not required for the 222 PeerKeyID, so mapping is generally restricted to truncation. Mapping 223 would only be needed to expand PeerKeyID's value beyond 16 bits. 225 4.1 Selected Range Reservation 227 Where a protocol uses an index of less than 16 bits, a selected range 228 of the local index space can be reserved for a particular protocol. 229 For example, consider two protocols P1 and P2 that each use 8 bit key 230 identifiers. Without identifier mapping these protocols would share 231 the space {0x0000 through 0x00ff} which would limit the pair of 232 protocols to 256 keys in total. By reserving the ranges {0x7f00 233 through 0x7fff} and {0x7e00 through 0x7eff} for P1 and P2 234 respectively permits each protocol to use the full 256 key 235 identifiers and establishes an unambiguous mapping for the protocol 236 key identifiers and local table identifiers. 238 When an initiator selects a key from the set in the table, the given 239 key identifier needs to be masked or shifted to the on-the-wire 240 range. Before requesting a specific key, the receiver would use a 241 shim layer to map the on-the-wire identifier into the reserved range. 243 4.2 Protocol Specific Mapping Tables 245 Each protocol can also maintain a simple mapping table with two 246 fields: the 16 bit index and the protocol specific value: 248 KEYTAB index (16 bits) | Protocol specific index (8 bits) 250 In this case, the host system would maintain separate mapping tables 251 for protocols P1 and P2. 253 5 Worked Example: TCP-AO 255 This section describes the way a TCP-AO implementation could use the 256 database. [tcpao] TCP-AO protocol is an example where the key 257 identifier is limited to 8 bits, so an identifier mapping is needed. 259 We will assume two peers Xp and Yp. Xp employs the range reservation 260 method for mapping and has reserved the range {0x7f00 ... 0x7fff} for 261 LocalKeyIDs for TCP-AO, mapping to {0x00 ... 0xff}. Yp employs a 262 protocol specific mapping table in its TCP-AO implementation. 264 The following subsections describe how peers Xp and Yp make use of 265 the database of long-lived cryptographic keys when Xp and Yp 266 respectively initiate a session. (Note: Rollover to new sessions 267 keys during a session is described in [tcpao].) 269 5.1 Setup 270 The owners of Xp and Yp determine a need for authenticated 271 communication using TCP-AO. They decide to use AES-CMAC-128 for 272 authentication, so a 128 bit key is needed. They decide to use the 273 same key for both directions (inbound and outbound), and that the key 274 will be available from 12/31/2010 through 12/31/2011. Through an out- 275 of-band channel, the administrators establish the shared secret: 276 0x0123456789ABCDEF0123456789ABCDEF 277 Peer Xp selects the first available TCP-AO identifier in the reserved 278 range, which is 0x7f05 and maps to an eight-bit identifier 0x05. 279 Peer Yp selects the next available TCP-AO identifier, 0x12, and the 280 next available LocalKeyID, which is 0x0107. Peer Yp also adds an 281 entry to its TCP-AO mapping table mapping the LocalKeyID to the TCP- 282 AO identifier, as shown in Figure 5: 284 LocalKeyID TCP-AO identifier 285 -------------------------------- 286 0x001a | 0x01 287 0x004d | 0x02 288 ... ... 289 0x0107 | 0x12 291 Figure 5. Protocol Specific KeyID Mapping Table for TCP-AO 293 After exchanging the TCP-AO identifiers, the peers have sufficient 294 information to establish their [KEYTAB] entries. Peer Xp's [KEYTAB] 295 entry is shown as Figure 6: 297 LocalKeyID 0x7f05 298 PeerKeyID 0x0012 299 KDFInputs none 300 AlgID AES-CMAC-128 301 Key 0x0123456789ABCDEF0123456789ABCDEF 302 Direction both 303 NotBefore 12/31/2010 304 NotAfter 12/31/2011 305 Peers yp.example.com 306 Protocol TCP-AO 308 Figure 6. Key Table Entry on Xp 310 Peer Yp's [KEYTAB] entry is shown as Figure 6: 312 LocalKeyID 0x0107 313 PeerKeyID 0x0005 314 KDFInputs none 315 AlgID AES-CMAC-128 316 Key 0x0123456789ABCDEF0123456789ABCDEF 317 Direction both 318 NotBefore 12/31/2010 319 NotAfter 12/31/2011 320 Peers xp.example.com 321 Protocol TCP-AO 323 Figure 7. Key Table Entry on Yp 325 5.2 Protocol Operation: Xp Initiates a Connection 327 Peer Xp wishes to initiate a connection with Peer Yp. 329 (1) Xp performs a key lookup for {Peer=Yp, Protocol=TCP-AO}, and the 330 entry with LocalKeyID 0x7f05 is returned. 331 (2) The LocalKeyID 0x7f05 is range mapped by Xp to the TCP-AO 332 identifier 0x05. 333 (3) Xp performs the session key derivation using the mechanism 334 specified for the TCP-AO protocol in [ao-crypto]. 335 (4) Xp generates the AES-CMAC-128 MACs for the outgoing traffic using 336 the derived key, and asserts the key identifier 0x05 in the packets. 337 (5) Yp receives a protected packet from Xp, and extracts the key 338 identifier 0x05. 339 (6) Yp performs a a key lookup for {Peer=Xp, Protocol=TCP-AO, 340 PeerKeyID=0x05}, and the entry with LocalKeyID 0x0107 is returned. 341 (7) Yp performs the session key derivation using the mechanism 342 specified for the TCP-AO protocol in [ao-crypto]. 343 (8) Yp verifies the MACs for the incoming traffic using the derived 344 key. 346 5.3 Protocol Operation: Yp Initiates a Connection 348 Where Peer Yp establishes the connection, the same process is 349 followed, except that the range mapping process from step (2) is 350 replaced by a table lookup. 352 6 Security Considerations 354 356 6 IANA Considerations 358 This document requires no actions by IANA. 360 7 References 362 7.1 Normative References 364 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, March 1997. 367 [KEYTAB] R. Housley and Polk, T. "Database of Long-Lived 368 Cryptographic Keys", draft-housley-saag-crypto-key-table- 369 00.txt, September 2009. 371 7.2 Informative References 373 [tcpao] J. Touch, Mankin A., and Bonica R. "The TCP Authentication 374 Option", draft-ietf-tcpm-tcp-auth-opt-08.txt, October 375 2009. 377 [ao-crypto] Lebovitz, G., "Cryptographic Algorithms, Use, & 378 Implementation Requirments for TCP Authentication 379 Option", draft-lebovitz-ietf-tcpm-tcp-ao-crypto-02.txt, 380 July 2009. 382 Author's Addresses 384 Tim Polk 385 National Institute of Standards and Technology 386 100 Bureau Drive, Mail Stop 8930 387 Gaithersburg, MD 20899-8930 388 USA 389 EMail: tim.polk@nist.gov 391 Russell Housley 392 Vigil Security, LLC 393 918 Spring Knoll Drive 394 Herndon, VA 20170 395 USA 396 EMail: housley@vigilsec.com 398 Full Copyright Statement 400 Copyright (c) 2009 IETF Trust and the persons identified as the 401 document authors. All rights reserved. 403 This document is subject to BCP 78 and the IETF Trust's Legal 404 Provisions Relating to IETF Documents in effect on the date of 405 publication of this document (http://trustee.ietf.org/license-info). 406 Please review these documents carefully, as they describe your rights 407 and restrictions with respect to this document. 409 All IETF Documents and the information contained therein are provided 410 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 411 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 412 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 413 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 414 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 415 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 416 FOR A PARTICULAR PURPOSE.