Internet Engineering Task Force (IETF) S. Hartman Request for Comments: 7211 Painless Security Category: Informational D. Zhang ISSN: 2070-1721 Huawei Technologies Co. Ltd. June 2014 Operations Model for Router Keying
AbstractThe IETF is engaged in an effort to analyze the security of routing protocol authentication according to design guidelines discussed in RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines". Developing an operational and management model for routing protocol security that works with all the routing protocols will be critical to the deployability of these efforts. This document gives recommendations to operators and implementors regarding management and operation of router authentication. These recommendations will also assist protocol designers in understanding management issues they will face. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see 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/rfc7211.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 3. Breakdown of KARP Configuration . . . . . . . . . . . . . . . 3 3.1. Integrity of the Key Table . . . . . . . . . . . . . . . 5 3.2. Management of Key Table . . . . . . . . . . . . . . . . . 5 3.3. Interactions with Automated Key Management . . . . . . . 6 3.4. Virtual Routing and Forwarding Instances (VRFs) . . . . . 6 4. Credentials and Authorization . . . . . . . . . . . . . . . . 6 4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Sharing Keys and Zones of Trust . . . . . . . . . . . 9 4.1.2. Key Separation and Protocol Design . . . . . . . . . 10 4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 10 4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 11 4.4. The Role of Central Servers . . . . . . . . . . . . . . . 12 5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 12 6. Administrator Involvement . . . . . . . . . . . . . . . . . . 14 6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 15 7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 18
RFC7210]. Routing security faces interesting challenges not present with some other security domains. Routers need to function in order to establish network connectivity. As a result, centralized services cannot typically be used for authentication or other security tasks; see Section 4.4. In addition, routers' roles affect how new routers are installed and how problems are handled; see Section 6. RFC2119]. RFC7210] describes configuration needed for manual keying. Configuration of automated key management is a work in progress.
There are multiple ways of structuring configuration information. One factor to consider is the scope of the configuration information. Several protocols are peer-to-peer routing protocols where a different key could potentially be used for each neighbor. Other protocols require that the same group key be used for all nodes in an administrative domain or routing area. In other cases, the same group key needs to be used for all routers on an interface, but different group keys can be used for each interface. Within situations where a per-interface, per-area, or per-peer key can be used for manually configured long-term keys, that flexibility may not be desirable from an operational standpoint. For example, consider OSPF [RFC2328]. Each router on an OSPF link needs to use the same authentication configuration, including the set of keys used for reception and the set of keys used for transmission, but it may use different keys for different links. The most general management model would be to configure keys per link. However, for deployments where the area uses the same key, it would be strongly desirable to configure the key as a property of the area. If the keys are configured per link, they can get out of sync. In order to support generality of configuration and common operational situations, it would be desirable to have some sort of inheritance where default configurations are made per area unless overridden per interface. As described in [RFC7210], the cryptographic keys are separated from the interface configuration into their own configuration store. Each routing protocol is responsible for defining the form of the peer specification used by that protocol. Thus, each routing protocol needs to define the scope of keys. For group keying, the peer specification names the group. A protocol could define a peer specification indicating the key had a link scope and also a peer specification for scoping a key to a specific area. For link-scoped keys, it is generally best to define a single peer specification indicating the key has a link scope and to use interface restrictions to restrict the key to the appropriate link. Operational Requirements: implementations of this model MUST support configuration of keys at the most general scope for the underlying protocol; protocols supporting per-peer keys MUST permit configuration of per-peer keys, protocols supporting per-interface keys MUST support configuration of per-interface keys, and so on for any additional scopes. Implementations MUST NOT permit configuration of an inappropriate key scope. For example, configuration of separate keys per interface would be inappropriate to support for a protocol requiring per-area keys. This restriction can be enforced by rules specified by each routing protocol for validating key table
entries. As such, these implementation requirements are best addressed by care being taken in how routing protocols specify the use of the key tables. RFC7210] provides a very general mechanism to abstract the storage of keys for routing protocols. To avoid misconfiguration and simplify problem determination, the router MUST verify the internal consistency of entries added to the table. Routing protocols describe how their protocol interacts with the key table including what validation MUST be performed. At a minimum, the router MUST verify: o The cryptographic algorithms are valid for the protocol. o The key derivation function is valid for the protocol. o The direction is valid for the protocol. For example, if a protocol requires the same session key be used in both directions, the direction field in the key table entry associated with the session key MUST be specified as "both". o The peer specification is consistent with the protocol. Other checks are possible. For example, the router could verify that if a key is associated with a peer, that peer is a configured peer for the specified protocol. However, this may be undesirable. It may be desirable to load a key table when some peers have not yet been configured. Also, it may be desirable to share portions of a key table across devices even when their current configuration does not require an adjacency with a particular peer in the interest of uniform configuration or preparing for fail-over. For these reasons, these additional checks are generally undesirable.
As part of adding a new key, it is typically desirable to set an expiration time for an old key. The management interface SHOULD provide a mechanism to easily update the expiration time for a current key used with a given peer or interface. Also, when adding a key, it is desirable to push the key out to nodes that will need it, allowing use for receiving packets and then later for enabling transmit. This can be accomplished automatically by providing a delay between when a key becomes valid for reception and transmission. However, some environments may not be able to predict when all the necessary changes will be made. In these cases, having a mechanism to enable a key for sending is desirable. The management interface SHOULD provide an easy mechanism to update the direction of an existing key or to enable a disabled key. Implementations SHOULD permit a configuration in which if no unexpired key is available, existing security associations continue using the expired key with which they were established. Implementations MUST support a configuration in which security associations fail if no unexpired key is available for them. See Section 6.2 for a discussion of reporting and managing security faults including those related to key expiration.
As discussed in [RTG-AUTH], preshared keys can be used as the input to a key derivation function (KDF) to generate traffic keys. For example, the TCP Authentication Option (TCP-AO) [RFC5925] derives keys based on the initial TCP session state. Typically, a KDF will combine a long-term key with public inputs exchanged as part of the protocol to form fresh session keys. A KDF could potentially be used with some inputs that are configured along with the long-term key. Also, it's possible that inputs to a KDF will be private and exchanged as part of the protocol, although this will be uncommon in KARP's uses of KDFs. Preshared keys could also be used by an automated key management protocol. In this mode, preshared keys would be used for authentication. However, traffic keys would be generated by some key-agreement mechanism or transported in a key encryption key derived from the preshared key. This mode may provide better replay protection. Also, in the absence of active attackers, key-agreement strategies such as Diffie-Hellman can be used to produce high-quality traffic keys even from relatively weak preshared keys. These key- agreement mechanisms are valuable even when active attackers are present, although an active attacker can mount a man-in-the-middle attack if the preshared key is sufficiently weak. Public keys can be used for authentication within an automated key management protocol. The KARP design guide [RFC6518] describes a mode in which routers have the hashes of peer routers' public keys. In this mode, a traditional public-key infrastructure is not required. The advantage of this mode is that a router only contains its own keying material, limiting the scope of a compromise. The disadvantage is that when a router is added or deleted from the set of authorized routers, all routers in that set need to be updated. Note that self-signed certificates are a common way of communicating public keys in this style of authentication. Certificates signed by a certification authority or some other PKI could be used for authentication within an automated key management protocol. The advantage of this approach is that routers may not need to be directly updated when peers are added or removed. The disadvantage is that more complexity and cost are required. Each of these approaches has a different set of management and operational requirements. Key differences include how authorization is handled and how identity works. This section discusses these differences.
RFC4808]. Typically key IDs are names used by one group or peer. Manual preshared keys are often known by a group of peers rather than just one other peer. This is an interesting security property: unlike with digitally signed messages or protocols where symmetric keys are known only to two parties, it is impossible to identify the peer sending a message cryptographically. However, it is possible to show that the sender of a message is one of the parties who knows the preshared key. Within the routing threat model, the peer sending a message can be identified only because peers are trusted and thus can be assumed to correctly label the packets they send. This contrasts with a protocol where cryptographic means such as digital signatures are used to verify the origin of a message. As a consequence, authorization is typically based on knowing the preshared key rather than on being a particular peer. Note that once an authorization decision is made, the peer can assert its identity; this identity is trusted just as the routing information from the peer is trusted. Doing an additional check for authorization based on the identity included in the packet would provide little value: an attacker who somehow had the key could claim the identity of an authorized peer, and an attacker without the key should be unable to claim the identity of any peer. Such a check is not required by the KARP threat model: inside attacks are not in scope. Preshared keys used with key derivation work similarly to manual preshared keys. However, to form the actual traffic keys, session- or peer-specific information is combined with the key. From an authorization standpoint, the derivation key works the same as a manual key. An additional routing protocol step or transport step forms the key that is actually used. Preshared keys that are used via automatic key management have not yet been specified for KARP, although ongoing work suggests they will be needed. Their naming and authorization may differ from existing uses of preshared keys in routing protocols. In particular, such keys may end up being known only by two peers. Alternatively, they may also be known by a group of peers. Authorization could potentially be based on peer identity, although it is likely that knowing the right key will be sufficient. There does not appear to
be a compelling reason to decouple the authorization of a key for some purpose from the authorization of peers holding that key to perform the authorized function.
Section 5 of [RFC4572]). KARP SHOULD adopt this approach or another approach already standardized within the IETF rather than inventing a new mechanism for naming public keys. A public key is typically expected to belong to one peer. As a peer generates new keys and retires old keys, its public key may change. For this reason, from a management standpoint, peers should be
thought of as associated with multiple public keys rather than as containing a single public-key hash as an attribute of the peer object. Authorization of public keys could be done either by key hash or by peer identity. Performing authorizations by peer identity should make it easier to update the key of a peer without risk of losing authorizations for that peer. However, management interfaces need to be carefully designed to avoid making this extra level of indirection complicated for operators.
OSPF-AUTO] discusses the potential need for key-agreement servers in OSPF. Other routing protocols that use multicast or broadcast such as IS-IS are likely to need a similar approach. Multicast key-agreement protocols need to allow operators to choose which key servers will generate traffic keys. The quality of random numbers [RFC4086] is likely to differ between systems. As a result, operators may have preferences for where keys are generated.
Establishing a management model is difficult because of the complex relationships between each set of objects. As discussed, there may be more than one key for a peer. However, in the preshared key case, there may be more than one peer for a key. This is true both for group security association protocols such as an IGP or one-to-one protocols where the same key is used administratively. In some of these situations, it may be undesirable to explicitly enumerate the peers in the configuration; for example, IGP peers are auto- discovered for broadcast links but not for non-broadcast multi-access links. Peers may be identified either by name or key. If peers are identified by key, it is strongly desirable from an operational standpoint to consider any peer identifiers or names to be a local matter and not require the identifiers or names to be synchronized. Obviously, if peers are identified by names (for example, with certificates in a PKI), identifiers need to be synchronized between the authorized peer and the peer making the authorization decision. In many cases, peers will explicitly be identified in routing protocol configuration. In these cases, it is possible to attach the authorization information (keys or identifiers) to the peer's configuration object. Two cases do not involve enumerating peers. The first is the case where preshared keys are shared among a group of peers. It is likely that this case can be treated from a management standpoint as a single peer representing all the peers that share the keys. The other case is one where certificates in a PKI are used to introduce peers to a router. In this case, rather than configuring peers, the router needs to be configured with information on which certificates represent acceptable peers. Another consideration is which routing protocols share peers. For example, it may be common for LDP peers to also be peers of some other routing protocol. Also, RSVP - Traffic Engineering (RSVP-TE) may be associated with some TE-based IGP. In some of these cases, it would be desirable to use the same authorization information for both routing protocols. Finally, as discussed in Section 7, it is sometimes desirable to override some aspect of the configuration for a peer in a group. As an example, when rotating to a new key, it is desirable to be able to roll that key out to each peer that will use the key, even if in the stable state the key is configured for a peer group. In order to develop a management model for authorization, the working group needs to consider several questions. What protocols support auto-discovery of peers? What protocols require more configuration of a peer than simply the peer's authorization information and
network address? What management operations are going to be common as security information for peers is configured and updated? What operations will be common while performing key transitions or while migrating to new security technologies?
KEYING] is to maintain the router's keying material so that when a router is replaced the same keys can be used. Router keys can be maintained on a central server. These approaches permit the credentials of a router to be recovered. This provides valuable options in case of hardware fault. The failing router can be recovered without changing credentials on other routers or waiting for keys to be certified. One disadvantage of this approach is that even if public-key cryptography is used, the private keys are located on more than just the router. A system in which keys were generated on a router and never exported from that router would typically make it more difficult for an attacker to obtain the keys. For most environments, the ability to quickly replace a router justifies maintaining keys centrally. More generally, keying is another item of configuration that needs to be restored to reestablish service when equipment fails. Operators typically perform the minimal configuration necessary to get a router
back in contact with the management server. The same would apply for keys. Operators who do not maintain copies of key material for performing key recovery on routers would need to perform a bit more work to regain contact with the management server. It seems reasonable to assume that management servers will be able to cause keys to be generated or distributed sufficiently to fully restore service. RFC2385] to the TCP Authentication Option [RFC5925]. Today, routers typically need to understand whether a given peer supports TCP MD5 or TCP-AO before opening a TCP connection. In addition, many implementations support grouping configuration (including security configuration) of related peers together. Implementations make it challenging to move from TCP MD5 to TCP-AO before all peers in the group are ready. Operators perceive it as high risk to update the configuration of a large number of peers. One particularly risky situation is upgrading the configuration of Internal BGP (iBGP) peers. The situation is more complicated for multicast protocols. It's typically not desirable to bring down an entire link to reconfigure it as using automated key management. Two approaches should be considered. One is to support key table rows that enable the
automated key management and manually configured keying for the same link at the same time. Coordinating this may be challenging from an operational standpoint. Another possibility is for the automated key management protocol to actually select the same traffic key that is being used manually. This could be accomplished by having an option in the key management protocol to export the current manual group key through the automated key management protocol. Then after all nodes are configured with automated key management, manual key entries can be removed. The next re-key after all nodes have manual entries removed will generate a new fresh key. Group key management protocols are RECOMMENDED to support an option to export existing manual keys during initial deployment of automated key management. RFC7210]. Routers need to have tight enough time synchronization that receivers permit a key to be utilized for validation prior to the first use of that key for generation of integrity-protected messages; otherwise, availability will be impacted. If time synchronization is too loose, then a key can be used beyond its intended lifetime. The Network Time Protocol (NTP) can be used to provide time synchronization. For some protocols, time synchronization is also important for replay detection. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, "Database of Long-Lived Symmetric Cryptographic Keys", RFC 7210, April 2014.
[KEYING] Turner, S., Patel, K., and R. Bush, "Router Keying for BGPsec", Work in Progress, May 2014. [OSPF-AUTO] Liu, Y., "OSPFv3 Automated Group Keying Requirements", Work in Progress, July 2007. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006. [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC 4808, March 2007. [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010. [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012. [RTG-AUTH] Polk, T. and R. Housley, "Routing Authentication Using A Database of Long-Lived Cryptographic Keys", Work in Progress, November 2010.