idnits 2.17.1 draft-ietf-karp-crypto-key-table-10.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 19 has weird spacing: '...routing proto...' == Line 67 has weird spacing: '...tion of routi...' == Line 133 has weird spacing: '...defines the f...' == Line 340 has weird spacing: '...provide integ...' == Line 530 has weird spacing: '...e third colum...' -- The document date (4 December 2013) is 3788 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) == Missing Reference: 'RFC3629' is mentioned on line 409, but not defined == Missing Reference: 'RFC 2104' is mentioned on line 517, but not defined == Missing Reference: 'RFC5926' is mentioned on line 536, but not defined == Missing Reference: 'RFC2104' is mentioned on line 537, but not defined == Unused Reference: 'IEEE802.1X-2010' is defined on line 576, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'UAX15' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Housley 3 Internet Engineering Task Force (IETF) Vigil Security 4 Intended Status: Standards Track T. Polk 5 NIST 6 S. Hartman 7 Painless Security 8 D. Zhang 9 Huawei 10 Expires: 4 June 2014 4 December 2013 12 Database of Long-Lived Symmetric Cryptographic Keys 13 15 Abstract 17 This document specifies the information contained in a conceptual 18 database of long-lived cryptographic keys used by many different 19 routing protocols for message security. The database is designed to 20 support both manual and automated key management. In addition to 21 describing the schema for the database, this document describes the 22 operations that can be performed on the database as well as the 23 requirements for the routing protocols that wish to use the database. 24 In many typical scenarios, the protocols do not directly use the 25 long-lived key, but rather a key derivation function is used to 26 derive a short-lived key from a long-lived key. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that other 35 groups may also distribute working documents as Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 1. Introduction 65 This document specifies the information that needs to be included in 66 a database of long-lived cryptographic keys in order to key the 67 cryptographic authentication of routing protocols. This conceptual 68 database is designed to separate protocol-specific aspects from both 69 manual and automated key management. The intent is to allow many 70 different implementation approaches to the specified cryptographic 71 key database, while simplifying specification and heterogeneous 72 deployments. This conceptual database avoids the need to build 73 knowledge of any security protocol into key management protocols. It 74 minimizes protocol-specific knowledge in operational/management 75 interfaces, but it constrains where that knowledge can appear. 76 Textual conventions are provided for the representation of keys and 77 other identifiers. These conventions should be used when presenting 78 keys and identifiers to operational/management interfaces or reading 79 keys/identifiers from these interfaces. This satisfies the 80 operational requirement that all implementations represent the keys 81 and key identifiers in the same way so that cross-vendor 82 configuration instructions can be provided. 84 Routing protocols can employ the services of more generic security 85 protocols such as TCP-AO [RFC5925]. Implementations of routing 86 protocols may need to supply keys to databases specific to these 87 security protocols as the associated entries in this document's 88 conceptual database are manipulated. 90 In many instances, the long-lived keys are not used directly in 91 security protocols, but rather a key derivation function is used to 92 derive short-lived keys from the long-lived key in the database. In 93 other instances, security protocols will directly use the long-lived 94 key from the database. The database design supports both use cases. 96 1.1. Requirements Notation 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 2. Conceptual Database Structure 104 The database is characterized as a table, where each row represents a 105 single long-lived symmetric cryptographic key. Normally, each key 106 should only have one row. Only in the (hopefully) very rare cases 107 where a key is used for more than one purpose, or where the same key 108 is used with multiple key derivation functions (KDFs) will multiple 109 rows contain the same key value. The columns in the table represent 110 the key value and attributes of the key. 112 To accommodate manual key management, the format of the fields has 113 been purposefully chosen to allow updates with a plain text editor 114 and to provide equivalent display on multiple systems. 116 The columns that the table consists of are listed as follows: 118 AdminKeyName 119 The AdminKeyName field contains a human-readable string meant 120 to identify the key for the user. Implementations can use this 121 field to uniquely identify rows in the key table. The same 122 string can be used on the local system and peer systems, but 123 this is not required. Routing protocols do not make use of this 124 string; they use the LocalKeyName and the PeerKeyName. However, 125 if these strings are to be used as protocol elements in other 126 protocols or otherwise transferred between systems, they will 127 need to follow the requirements of section 5.1. 129 LocalKeyName 130 The LocalKeyName field contains a string identifying the key. 131 It can be used to retrieve the key in the local database when 132 received in a message. As discussed in Section 4, the 133 protocol defines the form of this field. For example, many 134 routing protocols restrict the format of their key names to 135 integers that can be represented in 16 or 32 bits. Typically 136 this field does not contain data in human character sets 137 requiring internationalization. If there ever are any routing 138 Protocols with key names requiring internationalization, those 139 specifications need to address issues of canonicalization and 140 normalization so that key names can be compared using binary 141 comparison. 143 PeerKeyName 144 PeerKeyName is the name of the key used by the local system in 145 an outgoing message. For unicast communication, the PeerKeyName 146 of a key on a system matches the LocalKeyName of the identical 147 key that is maintained on one or multiple peer systems. Similar 148 to LocalKeyName, a protocol defines the form of this identifier 149 and will often restrict it to be an integer. For group keys, 150 the protocol will typically require this field be an empty 151 string as the sending and the receiving key names need to be 152 the same. 154 Peers 155 Typically for unicast keys, this field lists the peer systems 156 that have this key in their database. For group keys this field 157 names the groups for which the key is appropriate. For example, 158 this might name a routing area for a multicast routing 159 protocol. Formally, this field provides a protocol-specific set 160 of restrictions on the scope in which the key is appropriate. 161 The format of the identifiers in the Peers field is specified 162 by the protocol. 164 Interfaces 165 The Interfaces field identifies the set of physical and/or 166 virtual interfaces for which it is appropriate to use this key. 167 When the long-lived value in the Key field is intended for use 168 on any interface, this field is set to "all". The interfaces 169 field consists of a set of strings; the form of these strings 170 is specified by the implementation and is independent of the 171 protocol in question. Protocols may require support for the 172 interfaces field or may indicate that support for constraining 173 keys based on interface is not required. As an example, TCP-AO 174 implementations are unlikely to make the decision of what 175 interface to use prior to key selection. In this case, the 176 implementations are expected to use the same keying material 177 across all of the interfaces and then require the "all" 178 setting. 180 Protocol 181 The Protocol field identifies a single routing protocol where 182 this key may be used to provide cryptographic protection. This 183 specification establishes a registry for this field; the 184 registry also specifies the format of the following field, 185 ProtocolSpecificInfo, for each registered protocol. 187 ProtocolSpecificInfo 188 This field contains the protocol-specified information that may 189 be useful for a protocol to apply the key correctly. Note that 190 such information MUST NOT be required for a protocol to locate 191 an appropriate key. When a protocol does not need the 192 information in ProtocolSpecificInfo, it will require this field 193 be empty. Key table rows MAY specify a Direction of "both". 194 As a result, the encoding of this field needs to support 195 encoding protocol specific information for sending and 196 receiving in the same row. 198 KDF 199 The KDF field indicates the key derivation function which is 200 used to generate short-lived keys from the long-lived value in 201 the Key field. When the long-lived value in the Key field is 202 intended for direct use, the KDF field is set to "none". A key 203 derivation function is a one-way function that provides 204 cryptographic separation of key material. The KDF MAY use 205 inputs from the row in the key table and the message being sent 206 or received but MUST NOT depend on other configuration state. 207 This document establishes an IANA registry for the values in 208 the KDF field to simplify references in future specifications. 209 The protocol indicates what (if any) KDFs are valid. 211 AlgID 212 The AlgID field indicates which cryptographic algorithm to be 213 used with the security protocol for the specified peer or 214 peers. Such an algorithm can be an encryption algorithm and 215 mode (e.g., AES-128-CBC), an authentication algorithm (e.g., 216 HMAC-SHA1-96 or AES-128-CMAC), or any other symmetric 217 cryptographic algorithm needed by a security protocol. If the 218 KDF field contains "none", then the long-lived key is used 219 directly with this algorithm, otherwise the derived short-lived 220 key is used with this algorithm. When the long-lived key is 221 used to generate a set of short-lived keys for use with the 222 security protocol, the AlgID field identifies a ciphersuite 223 rather than a single cryptographic algorithm. This document 224 establishes an IANA registry for the values in the AlgID field 225 to simplify references in future specifications. Protocols 226 indicate which algorithms are appropriate. 228 Key 229 The Key field contains a long-lived symmetric cryptographic key 230 in the format of a lower-case hexadecimal string. The size of 231 the Key depends on the KDF and the AlgID. For instance, a 232 KDF=none and AlgID=AES128 requires a 128-bit key, which is 233 represented by 32 hexadecimal digits. 235 Direction 236 The Direction field indicates whether this key may be used for 237 inbound traffic, outbound traffic, both, or whether the key 238 has been disabled and may not currently be used at all. The 239 supported values are "in", "out", "both", and "disabled", 240 respectively. The Protocol field will determine which of these 241 values are valid. 243 SendLifetimeStart 244 The SendLifetimeStart field specifies the earliest date and 245 time in Coordinated Universal Time (UTC) at which this key 246 should be considered for use when sending traffic. The format 247 is YYYYMMDDHHSSZ, where four digits specify the year, two 248 digits specify the month, two digits specify the day, two 249 digits specify the hour, two digits specify the minute, and 250 two digits specify the second. The "Z" is included as a clear 251 indication that the time is in UTC. 253 SendLifeTimeEnd 254 The SendLifeTimeEnd field specifies the latest date and time at 255 which this key should be considered for use when sending 256 traffic. The format is the same as the SendLifetimeStart 257 field. 259 AcceptLifeTimeStart 260 The AcceptLifeTimeStart field specifies the earliest date and 261 time in Coordinated Universal Time (UTC) at which this key 262 should be considered for use when processing received traffic. 263 The format is YYYYMMDDHHSSZ, where four digits specify the 264 year, two digits specify the month, two digits specify the day, 265 two digits specify the hour, two digits specify the minute, and 266 two digits specify the second. The "Z" is included as a clear 267 indication that the time is in UTC. 269 AcceptLifeTimeEnd 270 The AcceptLifeTimeEnd field specifies the latest date and time 271 at which this key should be considered for use when processing 272 the received traffic. The format of this field is identical to 273 the format of AcceptLifeTimeStart. 275 3. Key Selection and Rollover 277 A protocol may directly consult the key table to find the key to use 278 on an outgoing message. The protocol provides a protocol (P) and a 279 peer identifier (H) into the key selection function. Optionally, an 280 interface identifier (I) may also need to be provided. Any key that 281 satisfies the following conditions may be selected: 283 (1) the Peers field includes H; 285 (2) the Protocol field matches P; 287 (3) If an interface is specified by the protocol, the Interfaces 288 field in the key table row includes I or "all"; 290 (4) the Direction field is either "out" or "both"; and 292 (5) SendLifetimeStart <= current time <= SendLifeTimeEnd. 294 During key selection, multiple entries may simultaneously exist 295 associated with different cryptographic algorithms or ciphersuites. 296 Systems should support selection of keys based on algorithm 297 preference to facilitate algorithm transition. 299 In addition, multiple entries with overlapping valid periods are 300 expected to be available for orderly key rollover. In these cases, 301 the expectation is that systems will transition to the newest key 302 available. To meet this requirement, this specification recommends 303 supplementing the key selection algorithm with the following 304 differentiation: select the long-lived key specifying the most recent 305 time in the SendLifetimeStart field. 307 In order to look up a key for validating an incoming message, the 308 protocol provides its protocol (P), the peer identifier (H), the key 309 identifier (L), and optionally the interface (I). If one key matches 310 the following conditions it is selected: 312 (1) the Peer field includes H; 314 (2) the Protocol field matches P; 316 (3) if the Interface field is provided, it includes I or is 317 "all"; 319 (4) the Direction field is either "in" or "both"; 321 (5) the LocalKeyName is L; and 323 (6) AcceptLifeTimeStart <= current time <= AcceptLifeTimeEnd. 325 Note that the key usage is loosely bound by the times specified in 326 the AcceptLifeTimeStart and AcceptLifeTimeEnd fields. New security 327 associations should not be established except within the period of 328 use specified by these fields, while allowing some grace time for 329 clock skew. However, if a security association has already been 330 established based on a particular long-lived key, exceeding the 331 lifetime does not have any direct impact. The implementations of 332 security protocols that involve long-lived security association 333 should be designed to periodically interrogate the database and 334 rollover to new keys without tearing down the security association. 336 Rather than consulting the conceptual database, a security protocol 337 such as TCP-AO may update its own tables as keys are added and 338 removed. In this case, the protocol needs to maintain its own key 339 information. Some routing protocols use IP Security (IPsec) to 340 provide integrity. If a specification describes how to use the 341 conceptual database described in this document to configure keys for 342 these routing protocols, similar concerns apply. The specification 343 mapping those routing protocols onto this conceptual database needs 344 to describe how the Security Policy Database is manipulated as rows 345 are added and removed from the conceptual database. 347 4. Application of the Database in a Security Protocol 349 In order to use the key table database in a protocol specification, a 350 protocol needs to specify certain information. This section 351 enumerates items that a protocol must specify. 353 (1) The ways of mapping the information in a key table row to the 354 information needed to produce an outgoing message; specified 355 either as an explanation of how to fill in authentication-related 356 fields in a message based on key table information, or for 357 protocols such as TCP-AO how to construct Master Key Tuples (MKTs) 358 or other protocol-specific structures from a key table row 360 (2) The ways of locating the peer identifier (a member of the 361 Peers set) and the LocalKeyName inside an incoming message 363 (3) The methods of verifying a message given a key table row; 364 this may be stated directly or in terms of protocol-specific 365 structures such as MKTs 367 (4) The form and validation rules for LocalKeyName and 368 PeerKeyName; if either of these is an integer, the conventions in 369 Section 5.1 are used as a vendor-independent format 371 (5) The form and validation rules for members of the Peers set 373 (6) The algorithms and KDFs supported 375 (7) The form of the ProtocolSpecifics field 376 (8) The rules for canonicalizing LocalKeyName, PeerKeyName, 377 entries in the Peers set, or ProtocolSpecifics; this may include 378 normalizations such as lower-casing hexadecimal strings 380 (9) The Indication whether the support for Interfaces is required 381 by this protocol 383 The form of the interfaces field is not protocol-specific but instead 384 is shared among all protocols on an implementation. If a protocol 385 needs to distinguish instances running over the same interface, this 386 is included in the specification of peers. Generally it is desirable 387 to define the specification of peers so that an operator can use the 388 interfaces field to refer to all instances of a protocol on a link 389 without having to specify both generic interfaces information and 390 protocol-specific peer information. 392 5. Textual Conventions 394 5.1 Key Names 396 When a key for a given protocol is identified by an integer key 397 identifier, the associated key name will be represented as lower case 398 hexadecimal digits with the most significant octet first. This 399 integer is padded with leading zero digits until the width of the key 400 identifier field in the protocol is reached. If a key name contains 401 non-integer human-readable text, its format and encoding may be an 402 issue, particularly if it is used in protocol between two different 403 types of systems. If characters from the ASCII range [RFC20] are 404 sufficient for a key name, then they SHOULD be used. If characters 405 outside of that range are desirable or required, then they MUST be in 406 an encoding of Unicode [UNICODE]. 408 In the case of an AdminKeyName that uses characters outside of the 409 ASCII range, the AdminKeyName MUST be encoded using UTF-8 [RFC3629] 410 and SHOULD be normalized using Unicode Normalization Form KC [UAX15] 411 to maximize the chance that the strings will compare correctly. 412 However, simply using Unicode Normalization Form KC is not sufficient 413 to account for all issues of string comparison; refer to [draft-ietf- 414 precis-framework] for additional information. 416 5.2 Keys 418 A key is represented as a lower-case hexadecimal string with the most 419 significant octet of the key first. As discussed in Section 2, the 420 length of this string depends on the associated algorithm and KDF. 422 6. Operational Considerations 424 If the valid periods for long-lived keys do not overlap or the system 425 clocks are inconsistent, it is possible to construct scenarios where 426 systems cannot agree upon a long-lived key. When installing a series 427 of keys to be used one after another, operators should configure the 428 SendLifetimeStart field of the key to be several hours after the 429 AcceptLifeTimeStart field of the key to guarantee there is some 430 overlap. This overlap is intended to address the clock skew issue and 431 allow for basic operational considerations. Operators may choose to 432 specify a longer overlap (e.g., several days) to allow for 433 exceptional circumstances. 435 7. Security Considerations 437 Management of encryption and authentication keys has been a 438 significant operational problem, both in terms of key synchronization 439 and key selection. For instance, the current guidance [RFC3562] 440 warns against sharing TCP MD5 keying material between systems, and 441 recommends changing keys according to a schedule. The same general 442 operational issues are relevant for the management of other 443 cryptographic keys. 445 It has been recognized in [RFC4107] that automated key management is 446 not viable in multiple scenarios. The conceptual database specified 447 in this document is designed to accommodate both manual key 448 management and automated key management. A future specification to 449 automatically populate rows in the database is envisioned. 451 Designers should recognize the warning provided in [RFC4107]: 453 Automated key management and manual key management provide very 454 different features. In particular, the protocol associated with 455 an automated key management technique will confirm the liveness of 456 the peer, protect against replay, authenticate the source of the 457 short-term session key, associate protocol state information with 458 the short-term session key, and ensure that a fresh short-term 459 session key is generated. Moreover, an automated key management 460 protocol can improve the interoperability by including negotiation 461 mechanisms for cryptographic algorithms. These valuable features 462 are impossible or extremely cumbersome to accomplish with manual 463 key management. 465 8. IANA Considerations 467 This specification defines three registries. 469 8.1. KeyTable Protocols 471 This document requests establishment of a registry called "KeyTable 472 Protocols". 474 All assignments to the KeyTable Protocols registry are made on a 475 specification required basis per Section 4.1 of [RFC5226]. 477 Each registration entry must contain the three fields: 479 - Protocol Name (unique within the registry); 480 - Protocol Specific Info; and 481 - Specification. 483 The specification needs to describe parameters required for using the 484 conceptual database as outlined in Section 4. This typically means 485 that the specification focuses more on the application of security 486 protocols with the key tables rather than being a new security 487 protocol specification for general purposes. New protocols may of 488 course combine information on how to use the key tables database with 489 the protocol specification. 491 The registry has three columns. The first column is a string of UTF-8 492 characters representing the name protocol. The second column is a 493 string of UTF-8 characters providing a brief description of Protocol 494 Specific Info. The third column is a reference to a specification 495 defining how the protocol is used with the key table. 497 There are no initial registrations. 499 8.2. KeyTable KDFs 501 This document requests the establishment of a registry called 502 "KeyTable KDFs". 504 All assignments to the KeyTable KDFs registry are made on a First 505 Come First Served basis per Section 4.1 of RFC 5226. 507 The registry has three columns. The first column is a string of UTF-8 508 characters representing the name of a KDF. The second column is a 509 string of UTF-8 characters providing a brief description of the KDF. 510 The third column is a reference to a specification defining the KDF, 511 if available. 513 KDF Description Reference 514 ------------ ---------------------------- --------- 515 none No KDF is used with this key N/A 516 AES-128-CMAC AES-CMAC using 128-bit keys [RFC4493] 517 HMAC-SHA-1 HMAC using the SHA-1 hash [RFC 2104] 519 8.3. KeyTable AlgIDs 521 This document requests establishment of a registry called "KeyTable 522 AlgIDs". 524 All assignments to the KeyTable AlgIDs registry are made on a First 525 Come First Served basis per Section 4.1 of RFC 5226. 527 The registry has three columns. The first column is a string of 528 UTF-8 characters representing the algorithm identifier (AlgID). The 529 second column is a string of UTF-8 characters providing a brief 530 description of the identified algorithm. The third column is a 531 reference to a specification defining the identified algorithm. 533 AlgID Description Reference 534 ------------ --------------------------------- --------- 535 AES-128-CMAC AES-CMAC using 128-bit keys [RFC4493] 536 AES-128-CMAC-96 AES-128-CMAc truncated to 96-bits [RFC5926] 537 HMAC-SHA-1-96 HMAC SHA-1 truncated to 96-bits [RFC2104] 539 9. Acknowledgments 541 This document reflects many discussions with many different people 542 over many years. In particular, the authors thank Jari Arkko, Ran 543 Atkinson, Ron Bonica, Ross Callon, Lars Eggert, Pasi Eronen, Adrian 544 Farrel, Gregory Lebovitz, Acee Lindem, Sandy Murphy, Eric Rescorla, 545 Mike Shand, Dave Ward, and Brian Weis for their insights. The 546 authors additionally thank Brian Weis for supplying text to address 547 IANA concerns and for help with formatting. 549 Sam Hartman's work on this draft is funded by Huawei. 551 10. References 553 10.1. Normative References 555 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, 556 October 1969. 558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 559 Requirement Levels", BCP 14, RFC 2119, March 1997. 561 [UAX15] The Unicode Consortium, "Unicode Standard Annex #15: 562 Unicode Normalization Forms", August 2012, 563 . 565 [UNICODE] The Unicode Consortium, "The Unicode Standard", 2013, 566 . 568 10.2. Informational References 570 [draft-ietf-precis-framework] 571 Saint-Andre, P. and M. Blanchet, "PRECIS Framework: 572 Preparation and Comparison of Internationalized Strings 573 in Application Protocols", work-in-progress, 574 November 21, 2013. 576 [IEEE802.1X-2010] 577 IEEE Standard for Local and Metropolitan Area Networks -- 578 Port-Based Network Access Control", February 2010. 580 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 581 Signature Option", RFC 3562, July 2003. 583 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 584 Key Management", RFC 4107, BCP 107, June 2005. 586 [RFC4493] Song, J., Lee, J., Poovendran, R., and T. Iwata, "The AES-CMAC 587 Algorithm", RFC 4493, June 2006. 589 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 590 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 591 May 2008. 593 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 594 Authentication Option", RFC 5925, June 2010. 596 Authors' Addresses 598 Russell Housley 599 Vigil Security, LLC 600 918 Spring Knoll Drive 601 Herndon, VA 20170 602 USA 603 EMail: housley@vigilsec.com 605 Tim Polk 606 National Institute of Standards and Technology 607 100 Bureau Drive, Mail Stop 8930 608 Gaithersburg, MD 20899-8930 609 USA 610 EMail: tim.polk@nist.gov 612 Sam Hartman 613 Painless Security, LLC 614 USA 615 Email: hartmans@painless-security.com 617 Dacheng Zhang 618 Huawei 619 China 620 Email: zhangdacheng@huawei.com