doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc7210.txt b/doc/rfc/rfc7210.txt
new file mode 100644
index 0000000..73ea5f6
--- /dev/null
+++ b/doc/rfc/rfc7210.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        R. Housley
+Request for Comments: 7210                                Vigil Security
+Category: Standards Track                                        T. Polk
+ISSN: 2070-1721                                                     NIST
+                                                              S. Hartman
+                                                       Painless Security
+                                                                D. Zhang
+                                            Huawei Technologies Co. Ltd.
+                                                              April 2014
+
+
+          Database of Long-Lived Symmetric Cryptographic Keys
+
+Abstract
+
+   This document specifies the information contained in a conceptual
+   database of long-lived cryptographic keys used by many different
+   routing protocols for message security.  The database is designed to
+   support both manual and automated key management.  In addition to
+   describing the schema for the database, this document describes the
+   operations that can be performed on the database as well as the
+   requirements for the routing protocols that wish to use the database.
+   In many typical scenarios, the protocols do not directly use the
+   long-lived key, but rather a key derivation function is used to
+   derive a short-lived key from a long-lived key.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7210.
+
+
+
+
+
+
+
+
+
+
+
+
+Housley, et al.              Standards Track                    [Page 1]
+
+RFC 7210               Table of Cryptographic Keys            April 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+1.  Introduction
+
+   This document specifies the information that needs to be included in
+   a database of long-lived cryptographic keys in order to key the
+   cryptographic authentication of routing protocols.  This conceptual
+   database is designed to separate protocol-specific aspects from both
+   manual and automated key management.  The intent is to allow many
+   different implementation approaches to the specified cryptographic
+   key database, while simplifying specification and heterogeneous
+   deployments.  This conceptual database avoids the need to build
+   knowledge of any security protocol into key management protocols.  It
+   minimizes protocol-specific knowledge in operational/management
+   interfaces, and it constrains where that knowledge can appear.
+   Textual conventions are provided for the representation of keys and
+   other identifiers.  These conventions should be used when presenting
+   keys and identifiers to operational/management interfaces or reading
+   keys/identifiers from these interfaces.  This satisfies the
+   operational requirement that all implementations represent the keys
+   and key identifiers in the same way so that cross-vendor
+   configuration instructions can be provided.
+
+   Routing protocols can employ the services of more-generic security
+   protocols such as TCP-AO [RFC5925].  Implementations of routing
+   protocols may need to supply keys to databases specific to these
+   security protocols as the associated entries in this document's
+   conceptual database are manipulated.
+
+   In many instances, the long-lived keys are not used directly in
+   security protocols, but rather a key derivation function is used to
+   derive short-lived keys from the long-lived key in the database.  In
+   other instances, security protocols will directly use the long-lived
+   key from the database.  The database design supports both use cases.
+
+
+
+
+Housley, et al.              Standards Track                    [Page 2]
+
+RFC 7210               Table of Cryptographic Keys            April 2014
+
+
+1.1.  Requirements Notation
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2.  Conceptual Database Structure
+
+   The database is characterized as a table, where each row represents a
+   single long-lived symmetric cryptographic key.  Normally, each key
+   should only have one row.  Only in the (hopefully) very rare cases
+   where a key is used for more than one purpose, or where the same key
+   is used with multiple key derivation functions (KDFs) will multiple
+   rows contain the same key value.  The columns in the table represent
+   the key value and attributes of the key.
+
+   To accommodate manual key management, the format of the fields has
+   been purposefully chosen to allow updates with a plain-text editor
+   and to provide equivalent display on multiple systems.
+
+   The columns that the table consists of are listed as follows:
+
+      AdminKeyName
+         The AdminKeyName field contains a human-readable string meant
+         to identify the key for the user.  Implementations can use this
+         field to uniquely identify rows in the key table.  The same
+         string can be used on the local system and peer systems, but
+         this is not required.  Routing protocols do not make use of
+         this string; they use the LocalKeyName and the PeerKeyName.
+         However, if these strings are to be used as protocol elements
+         in other protocols or otherwise transferred between systems,
+         they will need to follow the requirements of Section 5.1.
+
+      LocalKeyName
+         The LocalKeyName field contains a string identifying the key.
+         It can be used to retrieve the key in the local database when
+         received in a message.  As discussed in Section 4, the protocol
+         defines the form of this field.  For example, many routing
+         protocols restrict the format of their key names to integers
+         that can be represented in 16 or 32 bits.  Typically, this
+         field does not contain data in human character sets requiring
+         internationalization.  If there ever are any routing Protocols
+         with key names requiring internationalization, those
+         specifications need to address issues of canonicalization and
+         normalization so that key names can be compared using binary
+         comparison.
+
+
+
+
+
+Housley, et al.              Standards Track                    [Page 3]
+
+RFC 7210               Table of Cryptographic Keys            April 2014
+
+
+      PeerKeyName
+         PeerKeyName is the name of the key used by the local system in
+         an outgoing message.  For unicast communication, the
+         PeerKeyName of a key on a system matches the LocalKeyName of
+         the identical key that is maintained on one or multiple peer
+         systems.  Similar to LocalKeyName, a protocol defines the form
+         of this identifier and will often restrict it to be an integer.
+         For group keys, the protocol will typically require this field
+         be an empty string as the sending and the receiving key names
+         need to be the same.
+
+      Peers
+         Typically for unicast keys, this field lists the peer systems
+         that have this key in their database.  For group keys, this
+         field names the groups for which the key is appropriate.  For
+         example, this might name a routing area for a multicast routing
+         protocol.  Formally, this field provides a protocol-specific
+         set of restrictions on the scope in which the key is
+         appropriate.  The format of the identifiers in the Peers field
+         is specified by the protocol.
+
+      Interfaces
+         The Interfaces field identifies the set of physical and/or
+         virtual interfaces for which it is appropriate to use this key.
+         When the long-lived value in the Key field is intended for use
+         on any interface, this field is set to "all".  The interfaces
+         field consists of a set of strings; the form of these strings
+         is specified by the implementation and is independent of the
+         protocol in question.  Protocols may require support for the
+         Interfaces field or may indicate that support for constraining
+         keys based on interface is not required.  As an example, TCP-AO
+         implementations are unlikely to make the decision of what
+         interface to use prior to key selection.  In that case, the
+         implementations are expected to use the same keying material
+         across all of the interfaces and then require the "all"
+         setting.
+
+      Protocol
+         The Protocol field identifies a single routing protocol where
+         this key may be used to provide cryptographic protection.  This
+         specification establishes a registry for this field; the
+         registry also specifies the format of the following field,
+         ProtocolSpecificInfo, for each registered protocol.
+
+
+
+
+
+
+
+
+Housley, et al.              Standards Track                    [Page 4]
+
+RFC 7210               Table of Cryptographic Keys            April 2014
+
+
+      ProtocolSpecificInfo
+         This field contains the protocol-specified information that may
+         be useful for a protocol to apply the key correctly.  Note that
+         such information MUST NOT be required for a protocol to locate
+         an appropriate key.  When a protocol does not need the
+         information in ProtocolSpecificInfo, it will require this field
+         be empty.  Key table rows MAY specify a Direction of "both".
+         As a result, the encoding of this field needs to support
+         encoding protocol-specific information for sending and
+         receiving in the same row.
+
+      KDF
+         The KDF field indicates the key derivation function that is
+         used to generate short-lived keys from the long-lived value in
+         the Key field.  When the long-lived value in the Key field is
+         intended for direct use, the KDF field is set to "none".  A key
+         derivation function is a one-way function that provides
+         cryptographic separation of key material.  The KDF MAY use
+         inputs from the row in the key table and the message being sent
+         or received but MUST NOT depend on other configuration state.
+         This document establishes an IANA registry for the values in
+         the KDF field to simplify references in future specifications.
+         The protocol indicates what (if any) KDFs are valid.
+
+      AlgID
+         The AlgID field indicates which cryptographic algorithm is to
+         be used with the security protocol for the specified peer or
+         peers.  Such an algorithm can be an encryption algorithm and
+         mode (e.g., AES-128-CBC), an authentication algorithm (e.g.,
+         HMAC-SHA1-96 or AES-128-CMAC), or any other symmetric
+         cryptographic algorithm needed by a security protocol.  If the
+         KDF field contains "none", then the long-lived key is used
+         directly with this algorithm; otherwise, the derived short-
+         lived key is used with this algorithm.  When the long-lived key
+         is used to generate a set of short-lived keys for use with the
+         security protocol, the AlgID field identifies a ciphersuite
+         rather than a single cryptographic algorithm.  This document
+         establishes an IANA registry for the values in the AlgID field
+         to simplify references in future specifications.  Protocols
+         indicate which algorithms are appropriate.
+
+      Key
+         The Key field contains a long-lived symmetric cryptographic key
+         in the format of a lowercase hexadecimal string.  The size of
+         the Key depends on the KDF and the AlgID.  For instance,
+         KDF=none and AlgID=AES128 require a 128-bit key, which is
+         represented by 32 hexadecimal digits.
+
+
+
+
+Housley, et al.              Standards Track                    [Page 5]
+
+RFC 7210               Table of Cryptographic Keys            April 2014
+
+
+      Direction
+         The Direction field indicates whether this key may be used for
+         inbound traffic, outbound traffic, both, or whether the key has
+         been disabled and may not currently be used at all.  The
+         supported values are "in", "out", "both", and "disabled",
+         respectively.  The Protocol field will determine which of these
+         values are valid.
+
+      SendLifetimeStart
+         The SendLifetimeStart field specifies the earliest date and
+         time in Coordinated Universal Time (UTC) at which this key
+         should be considered for use when sending traffic.  The format
+         is YYYYMMDDHHSSZ, where four digits specify the year, two
+         digits specify the month, two digits specify the day, two
+         digits specify the hour, two digits specify the minute, and two
+         digits specify the second.  The "Z" is included as a clear
+         indication that the time is in UTC.
+
+      SendLifeTimeEnd
+         The SendLifeTimeEnd field specifies the latest date and time at
+         which this key should be considered for use when sending
+         traffic.  The format is the same as the SendLifetimeStart
+         field.
+
+      AcceptLifeTimeStart
+         The AcceptLifeTimeStart field specifies the earliest date and
+         time in Coordinated Universal Time (UTC) at which this key
+         should be considered for use when processing received traffic.
+         The format is YYYYMMDDHHSSZ, where four digits specify the
+         year, two digits specify the month, two digits specify the day,
+         two digits specify the hour, two digits specify the minute, and
+         two digits specify the second.  The "Z" is included as a clear
+         indication that the time is in UTC.
+
+      AcceptLifeTimeEnd
+         The AcceptLifeTimeEnd field specifies the latest date and time
+         at which this key should be considered for use when processing
+         the received traffic.  The format of this field is identical to
+         the format of AcceptLifeTimeStart.
+
+
+
+
+
+
+
+
+
+
+
+
+Housley, et al.              Standards Track                    [Page 6]
+
+RFC 7210               Table of Cryptographic Keys            April 2014
+
+
+3.  Key Selection and Rollover
+
+   A protocol may directly consult the key table to find the key to use
+   on an outgoing message.  The protocol provides a protocol (P) and a
+   peer identifier (H) into the key selection function.  Optionally, an
+   interface identifier (I) may also need to be provided.  Any key that
+   satisfies the following conditions may be selected:
+
+      (1)  the Peers field includes H;
+
+      (2)  the Protocol field matches P;
+
+      (3)  If an interface is specified by the protocol, the Interfaces
+           field in the key table row includes I or "all";
+
+      (4)  the Direction field is either "out" or "both"; and
+
+      (5)  SendLifetimeStart <= current time <= SendLifeTimeEnd.
+
+   During key selection, there may be multiple entries that
+   simultaneously exist and are associated with different cryptographic
+   algorithms or ciphersuites.  Systems should support selection of keys
+   based on algorithm preference to facilitate algorithm transition.
+
+   In addition, multiple entries with overlapping valid periods are
+   expected to be available for orderly key rollover.  In these cases,
+   the expectation is that systems will transition to the newest key
+   available.  To meet this requirement, this specification recommends
+   supplementing the key selection algorithm with the following
+   differentiation: select the long-lived key specifying the most recent
+   time in the SendLifetimeStart field.
+
+   In order to look up a key for validating an incoming message, the
+   protocol provides its protocol (P), the peer identifier (H), the key
+   identifier (L), and optionally the interface (I).  If one key matches
+   the following conditions, it is selected:
+
+      (1)  the Peer field includes H;
+
+      (2)  the Protocol field matches P;
+
+      (3)  if the Interface field is provided, it includes I or is
+           "all";
+
+      (4)  the Direction field is either "in" or "both";
+
+
+
+
+
+
+Housley, et al.              Standards Track                    [Page 7]
+
+RFC 7210               Table of Cryptographic Keys            April 2014
+
+
+      (5)  the LocalKeyName is L; and
+
+      (6)  AcceptLifeTimeStart <= current time <= AcceptLifeTimeEnd.
+
+   Note that the key usage is loosely bound by the times specified in
+   the AcceptLifeTimeStart and AcceptLifeTimeEnd fields.  New security
+   associations should not be established except within the period of
+   use specified by these fields, while allowing some grace time for
+   clock skew.  However, if a security association has already been
+   established based on a particular long-lived key, exceeding the
+   lifetime does not have any direct impact.  The implementations of
+   security protocols that involve long-lived security associations
+   should be designed to periodically interrogate the database and
+   rollover to new keys without tearing down the security associations.
+
+   Rather than consulting the conceptual database, a security protocol
+   such as TCP-AO may update its own tables as keys are added and
+   removed.  In this case, the protocol needs to maintain its own key
+   information.  Some routing protocols use IP Security (IPsec) to
+   provide integrity.  If a specification describes how to use the
+   conceptual database described in this document to configure keys for
+   these routing protocols, similar concerns apply.  The specification
+   mapping those routing protocols onto this conceptual database needs
+   to describe how the Security Policy Database is manipulated as rows
+   are added and removed from the conceptual database.
+
+4.  Application of the Database in a Security Protocol
+
+   In order to use the key table database in a protocol specification, a
+   protocol needs to specify certain information.  This section
+   enumerates items that a protocol must specify.
+
+      (1) The ways of mapping the information in a key table row to the
+           information needed to produce an outgoing message; specified
+           as an explanation of either how to fill in authentication-
+           related fields in a message based on key table information,
+           or (for protocols such as TCP-AO) how to construct Master Key
+           Tuples (MKTs) or other protocol-specific structures from a
+           key table row
+
+      (2)  The ways of locating the peer identifier (a member of the
+           Peers set) and the LocalKeyName inside an incoming message
+
+      (3)  The methods of verifying a message given a key table row;
+           this may be stated directly or in terms of protocol-specific
+           structures such as MKTs
+
+
+
+
+
+Housley, et al.              Standards Track                    [Page 8]
+
+RFC 7210               Table of Cryptographic Keys            April 2014
+
+
+      (4)  The form and validation rules for LocalKeyName and
+           PeerKeyName; if either of these is an integer, the
+           conventions in Section 5.1 are used as a vendor-independent
+           format
+
+      (5)  The form and validation rules for members of the Peers set
+
+      (6)  The algorithms and KDFs supported
+
+      (7)  The form of the ProtocolSpecificInfo field
+
+      (8)  The rules for canonicalizing LocalKeyName, PeerKeyName,
+           entries in the Peers set, or ProtocolSpecificInfo; this may
+           include normalizations such as lowercasing hexadecimal
+           strings
+
+      (9)  The Indication whether the support for Interfaces is required
+           by this protocol
+
+   The form of the interfaces field is not protocol specific but instead
+   is shared among all protocols on an implementation.  If a protocol
+   needs to distinguish instances running over the same interface, this
+   is included in the specification of peers.  Generally, it is
+   desirable to define the specification of peers so that an operator
+   can use the Interfaces field to refer to all instances of a protocol
+   on a link without having to specify both generic interfaces
+   information and protocol-specific peer information.
+
+5.  Textual Conventions
+
+5.1.  Key Names
+
+   When a key for a given protocol is identified by an integer key
+   identifier, the associated key name will be represented as lowercase
+   hexadecimal digits with the most significant octet first.  This
+   integer is padded with leading zero digits until the width of the key
+   identifier field in the protocol is reached.  If a key name contains
+   non-integer human-readable text, its format and encoding may be an
+   issue, particularly if it is used in protocol between two different
+   types of systems.  If characters from the ASCII range [RFC20] are
+   sufficient for a key name, then they SHOULD be used.  If characters
+   outside of that range are desirable or required, then they MUST be in
+   an encoding of Unicode [UNICODE].
+
+   In the case of an AdminKeyName that uses characters outside of the
+   ASCII range, the AdminKeyName MUST be encoded using UTF-8 [RFC3629]
+   and SHOULD be normalized using Unicode Normalization Form KC [UAX15]
+   to maximize the chance that the strings will compare correctly.
+
+
+
+Housley, et al.              Standards Track                    [Page 9]
+
+RFC 7210               Table of Cryptographic Keys            April 2014
+
+
+   However, simply using Unicode Normalization Form KC is not sufficient
+   to account for all issues of string comparison; refer to
+   [PRECIS-FRAMEWORK] for additional information.
+
+5.2.  Keys
+
+   A key is represented as a lowercase hexadecimal string with the most
+   significant octet of the key first.  As discussed in Section 2, the
+   length of this string depends on the associated algorithm and KDF.
+
+6.  Operational Considerations
+
+   If the valid periods for long-lived keys do not overlap or the system
+   clocks are inconsistent, it is possible to construct scenarios where
+   systems cannot agree upon a long-lived key.  When installing a series
+   of keys to be used one after another, operators should configure the
+   SendLifetimeStart field of the key to be several hours after the
+   AcceptLifeTimeStart field of the key to guarantee there is some
+   overlap.  This overlap is intended to address the clock-skew issue
+   and allow for basic operational considerations.  Operators may choose
+   to specify a longer overlap (e.g., several days) to allow for
+   exceptional circumstances.
+
+7.  Security Considerations
+
+   Management of encryption and authentication keys has been a
+   significant operational problem, both in terms of key synchronization
+   and key selection.  For instance, the current guidance [RFC3562]
+   warns against sharing TCP MD5 keying material between systems and
+   recommends changing keys according to a schedule.  The same general
+   operational issues are relevant for the management of other
+   cryptographic keys.
+
+   It has been recognized in [RFC4107] that automated key management is
+   not viable in multiple scenarios.  The conceptual database specified
+   in this document is designed to accommodate both manual key
+   management and automated key management.  A future specification to
+   automatically populate rows in the database is envisioned.
+
+   Designers should recognize the warning provided in [RFC4107]:
+
+      Automated key management and manual key management provide very
+      different features.  In particular, the protocol associated with
+      an automated key management technique will confirm the liveness of
+      the peer, protect against replay, authenticate the source of the
+      short-term session key, associate protocol state information with
+      the short-term session key, and ensure that a fresh short-term
+      session key is generated.  Further, an automated key management
+
+
+
+Housley, et al.              Standards Track                   [Page 10]
+
+RFC 7210               Table of Cryptographic Keys            April 2014
+
+
+      protocol can improve interoperability by including negotiation
+      mechanisms for cryptographic algorithms.  These valuable features
+      are impossible or extremely cumbersome to accomplish with manual
+      key management.
+
+8.  IANA Considerations
+
+   This specification defines three registries.
+
+8.1.  KeyTable Protocols
+
+   Per this document, IANA has established a registry called "KeyTable
+   Protocols".
+
+   All assignments to the KeyTable Protocols registry are made on a
+   Specification Required basis per Section 4.1 of [RFC5226].
+
+   Each registration entry must contain the three fields:
+
+      - Protocol Name (unique within the registry);
+      - Protocol-Specific Info; and
+      - Reference.
+
+   The specification needs to describe parameters required for using the
+   conceptual database as outlined in Section 4.  This typically means
+   that the specification focuses more on the application of security
+   protocols with the key tables rather than being a new security
+   protocol specification for general purposes.  Of course, new
+   protocols may combine information on how to use the key table
+   database with the protocol specification.
+
+   The registry has three columns.  The first column is a string of
+   Unicode characters encoded in UTF-8 representing the name protocol.
+   The second column is a string of Unicode characters encoded in UTF-8
+   providing a brief description of Protocol-Specific Info.  The third
+   column is a reference to a specification defining how the protocol is
+   used with the key table.
+
+   There are no initial registrations.
+
+8.2.  KeyTable KDFs
+
+   Per this document, IANA has established a registry called "KeyTable
+   KDFs".  The remainder of this section describes the registry.
+
+   All assignments to the KeyTable KDFs registry are made on a First
+   Come First Served basis per Section 4.1 of RFC 5226.
+
+
+
+
+Housley, et al.              Standards Track                   [Page 11]
+
+RFC 7210               Table of Cryptographic Keys            April 2014
+
+
+   The registry has three columns.  The first column is a string of
+   Unicode characters encoded in UTF-8 representing the name of a KDF.
+   The second column is a string of Unicode characters encoded in UTF-8
+   providing a brief description of the KDF.  The third column is a
+   reference to a specification defining the KDF, if available.
+
+   The initial contents of this registry and that in Section 8.3 are
+   chosen based on the algorithms defined for TCP-AO [RFC5926].
+
+      KDF             Description                     Reference
+      ------------    ----------------------------    ---------
+      none            No KDF is used with this key    N/A
+      AES-128-CMAC    AES-CMAC using 128-bit keys     [RFC4493]
+      HMAC-SHA-1      HMAC using the SHA-1 hash       [RFC2104]
+
+8.3.  KeyTable AlgIDs
+
+   Per this document, IANA has established a registry called "KeyTable
+   AlgIDs".  The remainder of this section describes the registry.
+
+   All assignments to the KeyTable AlgIDs registry are made on a First
+   Come First Served basis per Section 4.1 of RFC 5226.
+
+   The registry has three columns.  The first column is a string of
+   Unicode characters encoded in UTF-8 representing the algorithm
+   identifier (AlgID).  The second column is a string of Unicode
+   characters encoded in UTF-8 providing a brief description of the
+   identified algorithm.  The third column is a reference to a
+   specification defining the identified algorithm.
+
+   The initial contents of this registry and that in Section 8.2 are
+   chosen based on the algorithms defined for TCP-AO [RFC5926].
+
+      AlgID             Description                          Reference
+      ------------      ---------------------------------    ---------
+      AES-128-CMAC      AES-CMAC using 128-bit keys          [RFC4493]
+      AES-128-CMAC-96   AES-128-CMAC truncated to 96 bits    [RFC5926]
+      HMAC-SHA-1-96     HMAC SHA-1 truncated to 96 bits      [RFC2104]
+
+
+
+
+
+
+
+
+
+
+
+
+
+Housley, et al.              Standards Track                   [Page 12]
+
+RFC 7210               Table of Cryptographic Keys            April 2014
+
+
+9.  Acknowledgments
+
+   This document reflects many discussions with many different people
+   over many years.  In particular, the authors thank Jari Arkko, Ran
+   Atkinson, Ron Bonica, Ross Callon, Lars Eggert, Pasi Eronen, Adrian
+   Farrel, Gregory Lebovitz, Acee Lindem, Sandy Murphy, Eric Rescorla,
+   Mike Shand, Dave Ward, and Brian Weis for their insights.  The
+   authors additionally thank Brian Weis for supplying text to address
+   IANA concerns and for help with formatting.
+
+   Sam Hartman's work on this document is funded by Huawei.
+
+10.  Normative References
+
+   [RFC20]    Cerf, V., "ASCII format for network interchange", RFC 20,
+              October 1969.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [UAX15]    The Unicode Consortium, "Unicode Standard Annex #15:
+              Unicode Normalization Forms", Unicode 6.3.0, September
+              2013, <http://www.unicode.org/reports/tr15/tr15-39.html>.
+
+   [UNICODE]  The Unicode Consortium, "The Unicode Standard, Version
+              6.3.0", (Mountain View, CA: The Unicode Consortium, 2013.
+              ISBN 978-1-936213-08-5),
+              <http://www.unicode.org/versions/Unicode6.3.0/>.
+
+11.  Informative References
+
+   [PRECIS-FRAMEWORK]
+              Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
+              Preparation and Comparison of Internationalized Strings in
+              Application Protocols", Work in Progress, March 2014.
+
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104, February
+              1997.
+
+   [RFC3562]  Leech, M., "Key Management Considerations for the TCP MD5
+              Signature Option", RFC 3562, July 2003.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+   [RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographic
+              Key Management", BCP 107, RFC 4107, June 2005.
+
+
+
+Housley, et al.              Standards Track                   [Page 13]
+
+RFC 7210               Table of Cryptographic Keys            April 2014
+
+
+   [RFC4493]  Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
+              AES-CMAC Algorithm", RFC 4493, June 2006.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
+              Authentication Option", RFC 5925, June 2010.
+
+   [RFC5926]  Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
+              for the TCP Authentication Option (TCP-AO)", RFC 5926,
+              June 2010.
+
+Authors' Addresses
+
+   Russell Housley
+   Vigil Security, LLC
+   918 Spring Knoll Drive
+   Herndon, VA 20170
+   USA
+   EMail: housley@vigilsec.com
+
+   Tim Polk
+   National Institute of Standards and Technology
+   100 Bureau Drive, Mail Stop 8930
+   Gaithersburg, MD 20899-8930
+   USA
+   EMail: tim.polk@nist.gov
+
+   Sam Hartman
+   Painless Security, LLC
+   USA
+   EMail: hartmans-ietf@mit.edu
+
+   Dacheng Zhang
+   Huawei Technologies Co. Ltd.
+   China
+   EMail: zhangdacheng@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+Housley, et al.              Standards Track                   [Page 14]
+