summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7210.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7210.txt')
-rw-r--r--doc/rfc/rfc7210.txt787
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]
+