draft-ietf-karp-ops-model-06.txt   draft-ietf-karp-ops-model-07.txt 
Network Working Group S. Hartman Network Working Group S. Hartman
Internet-Draft Painless Security Internet-Draft Painless Security
Intended status: Informational D. Zhang Intended status: Informational D. Zhang
Expires: November 21, 2013 Huawei Expires: January 6, 2014 Huawei
May 20, 2013 July 5, 2013
Operations Model for Router Keying Operations Model for Router Keying
draft-ietf-karp-ops-model-06.txt draft-ietf-karp-ops-model-07.txt
Abstract Abstract
Developing an operational and management model for routing protocol Developing an operational and management model for routing protocol
security that works across protocols will be critical to the success security that works with all the routing protocols will be critical
of routing protocol security efforts. This document discusses issues to the success of routing protocol security efforts. This document
and begins to consider development of these models. discusses issues and begins to consider development of these models.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 21, 2013. This Internet-Draft will expire on January 6, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
4.1.2. Key Separation and Protocol Design . . . . . . . . . . 11 4.1.2. Key Separation and Protocol Design . . . . . . . . . . 11
4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 11 4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 11
4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 12 4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 12
4.4. The role of Central Servers . . . . . . . . . . . . . . . 12 4.4. The role of Central Servers . . . . . . . . . . . . . . . 12
5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 14 5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 14
6. Administrator Involvement . . . . . . . . . . . . . . . . . . 16 6. Administrator Involvement . . . . . . . . . . . . . . . . . . 16
6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 16 6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 16
7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 18 7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The KARP working group is designing improvements to the cryptographic The KARP working group is designing improvements to the cryptographic
authentication of IETF routing protocols. These improvements include authentication of IETF routing protocols. These improvements include
improvements to how integrity functions are handled within each improvements to how integrity functions are handled within each
protocol as well as designing an automated key management solution. protocol as well as designing an automated key management solution.
This document discusses issues to consider when thinking about the This document discusses issues to consider when thinking about the
operational and management model for KARP. Each implementation will operational and management model for KARP. Each implementation will
skipping to change at page 5, line 43 skipping to change at page 5, line 43
configuration store. Each routing protocol is responsible for configuration store. Each routing protocol is responsible for
defining the form of the Peer specification used by that protocol. defining the form of the Peer specification used by that protocol.
Thus each routing protocol needs to define the scope of keys. For Thus each routing protocol needs to define the scope of keys. For
group keying, the Peer specification names the group. A protocol group keying, the Peer specification names the group. A protocol
could define a Peer specification indicating the key had a link scope 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. 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 For link-scoped keys it is generally best to define a single Peer
specification indicating the key has a link scope and to use specification indicating the key has a link scope and to use
interface restrictions to restrict the key to the appropriate link. interface restrictions to restrict the key to the appropriate link.
Operational Requirements: KARP MUST support configuration of keys at Operational Requirements: implementations of this model MUST support
the most general scope for the underlying protocol; protocols configuration of keys at the most general scope for the underlying
supporting per-peer keys MUST permit configuration of per-peer keys, protocol; protocols supporting per-peer keys MUST permit
protocols supporting per-interface keys MUST support configuration of configuration of per-peer keys, protocols supporting per-interface
per-interface keys, and so on. KARP MUST NOT permit configuration of keys MUST support configuration of per-interface keys, and so on.
an inappropriate key scope. For example, configuration of separate Implementations MUST NOT permit configuration of an inappropriate key
keys per interface MUST NOT be supported for a protocol requiring scope. For example, configuration of separate keys per interface
per-area keys. This restriction can be enforced by rules specified MUST NOT be supported for a protocol requiring per-area keys. This
by each routing protocol for validating key table entries. 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.
3.1. Integrity of the Key Table 3.1. Integrity of the Key Table
The routing key table [I-D.ietf-karp-crypto-key-table] provides a The routing key table [I-D.ietf-karp-crypto-key-table] provides a
very general mechanism to abstract the storage of keys for routing very general mechanism to abstract the storage of keys for routing
protocols. To avoid misconfiguration and simplify problem protocols. To avoid misconfiguration and simplify problem
determination, the router MUST verify the internal consistency of determination, the router MUST verify the internal consistency of
entries added to the table. Routing protocols describe how their entries added to the table. Routing protocols describe how their
protocol interacts with the key table including what validation MUST protocol interacts with the key table including what validation MUST
be performed. At a minimum, the router MUST verify: be performed. At a minimum, the router MUST verify:
skipping to change at page 8, line 17 skipping to change at page 8, line 17
Several methods for authentication have been proposed for KARP. The Several methods for authentication have been proposed for KARP. The
simplest is preshared keys used directly as traffic keys. In this simplest is preshared keys used directly as traffic keys. In this
mode, the traffic integrity keys are directly configured. This is mode, the traffic integrity keys are directly configured. This is
the mode supported by most of today's routing protocols. the mode supported by most of today's routing protocols.
As discussed in [I-D.polk-saag-rtg-auth-keytable], preshared keys can As discussed in [I-D.polk-saag-rtg-auth-keytable], preshared keys can
be used as the input to a key derivation function (KDF) to generate be used as the input to a key derivation function (KDF) to generate
traffic keys. For example the TCP Authentication Option (TCP-AO) traffic keys. For example the TCP Authentication Option (TCP-AO)
[RFC5925] derives keys based on the initial TCP session state. [RFC5925] derives keys based on the initial TCP session state.
Typically a KDF will combine a long-term key with public inputs 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 exchanged as part of the protocol to form fresh session keys. A KDF
could potentially be used with some inputs that are configured along 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 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 private and exchanged as part of the protocol, although this
will be uncommon in KARP's uses of KDFs. will be uncommon in KARP's uses of KDFs.
Preshared keys could also be used by an automated key management Preshared keys could also be used by an automated key management
protocol. In this mode, preshared keys would be used for protocol. In this mode, preshared keys would be used for
authentication. However traffic keys would be generated by some key authentication. However traffic keys would be generated by some key
agreement mechanism or transported in a key encryption key derived agreement mechanism or transported in a key encryption key derived
from the preshared key. This mode may provide better replay from the preshared key. This mode may provide better replay
skipping to change at page 9, line 18 skipping to change at page 9, line 18
4.1. Preshared Keys 4.1. Preshared Keys
In the protocol, manual preshared keys are either unnamed or named by In the protocol, manual preshared keys are either unnamed or named by
a small integer (typically 16 or 32 bits) key ID. Implementations a small integer (typically 16 or 32 bits) key ID. Implementations
that support multiple keys for protocols that have no names for keys that support multiple keys for protocols that have no names for keys
need to try all possible keys before deciding a packet cannot be need to try all possible keys before deciding a packet cannot be
validated [RFC4808]. Typically key IDs are names used by one group validated [RFC4808]. Typically key IDs are names used by one group
or peer. or peer.
Manual preshared keys are often known by a group of peers rather than Manual preshared keys are often known by a group of peers rather than
just oneother peer. This is an interesting security property: unlike just one other peer. This is an interesting security property:
with digitally signed messages or protocols where symmetric keys are unlike with digitally signed messages or protocols where symmetric
known only to two parties, it is impossible to identify the peer keys are known only to two parties, it is impossible to identify the
sending a message cryptographically. However, it is possible to show peer sending a message cryptographically. However, it is possible to
that the sender of a message is one of the parties who knows the 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 preshared key. Within the routing threat model the peer sending a
message can be identified only because peers are trusted and thus can message can be identified only because peers are trusted and thus can
be assumed to correctly label the packets they send. This contrasts be assumed to correctly label the packets they send. This contrasts
with a protocol where cryptographic means such as digital signatures with a protocol where cryptographic means such as digital signatures
are used to verify the origin of a message. As a consequence, are used to verify the origin of a message. As a consequence,
authorization is typically based on knowing the preshared key rather authorization is typically based on knowing the preshared key rather
than on being a particular peer. Note that once an authorization than on being a particular peer. Note that once an authorization
decision is made, the peer can assert its identity; this identity is decision is made, the peer can assert its identity; this identity is
trusted just as the routing information from the peer is trusted. trusted just as the routing information from the peer is trusted.
Doing an additional check for authorization based on the identity Doing an additional check for authorization based on the identity
skipping to change at page 10, line 20 skipping to change at page 10, line 20
Care needs to be taken when symmetric keys are used for multiple Care needs to be taken when symmetric keys are used for multiple
purposes. Consider the implications of using the same preshared key purposes. Consider the implications of using the same preshared key
for two interfaces: it becomes impossible to cryptographically for two interfaces: it becomes impossible to cryptographically
distinguish a router on one interface from a router on another distinguish a router on one interface from a router on another
interface. So, a router that is trusted to participate in a routing interface. So, a router that is trusted to participate in a routing
protocol on one interface becomes implicitly trusted for the other protocol on one interface becomes implicitly trusted for the other
interfaces that share the key. For many cases, such as link-state interfaces that share the key. For many cases, such as link-state
routers in the same routing area, there is no significant advantage routers in the same routing area, there is no significant advantage
that an attacker could gain from this trust within the KARP threat that an attacker could gain from this trust within the KARP threat
model. However, distance-vector protocols, such as BGP and RIP, model. However, other protocols such as BGP and RIP, permit routes
permit routes to be filtered across a trust boundary. For these to be filtered across a trust boundary. For these protocols,
protocols, participation in one interface might be more advantageous participation in one interface might be more advantageous than
than another. Operationally, when this trust distinction is another. Operationally, when this trust distinction is important to
important to a deployment, different keys need to be used on each a deployment, different keys need to be used on each side of the
side of the trust boundary. Key derivation can help prevent this trust boundary. Key derivation can help prevent this problem in
problem in cases of accidental misconfiguration. However, key cases of accidental misconfiguration. However, key derivation cannot
derivation cannot protect against a situation where a system was protect against a situation where a system was incorrectly trusted to
incorrectly trusted to have the key used to perform the derivation. have the key used to perform the derivation. This question of trust
This question of trust is important to the KARP threat model because is important to the KARP threat model because it is essential to
it is essential to determining whether a party is an insider for a determining whether a party is an insider for a particular routing
particular routing protocol. A customer router that is an an insider protocol. A customer router that is an an insider for a BGP peering
for a BGP peering relationship with a service provider is not relationship with a service provider is not typically an insider when
typically an insider when considering the security of that service considering the security of that service provider's IGP. Similarly,
provider's IGP. Similarly, To the extent that there are multiple To the extent that there are multiple zones of trust and a routing
zones of trust and a routing protocol is determining whether a protocol is determining whether a particular router is within a
particular router is within a certain zone, the question of untrusted certain zone, the question of untrusted actors is within the scope of
actors is within the scope of the routing threat model. the routing threat model.
Key derivation can be part of a management solution to a desire to Key derivation can be part of a management solution to a desire to
have multiple keys for different zones of trust. A master key could have multiple keys for different zones of trust. A master key could
be combined with peer, link or area identifiers to form a router- be combined with peer, link or area identifiers to form a router-
specific preshared key that is loaded onto routers. Provided that specific preshared key that is loaded onto routers. Provided that
the master key lives only on the management server and not the the master key lives only on the management server and not the
individual routers, trust is preserved. However in many cases, individual routers, trust is preserved. However in many cases,
generating independent keys for the routers and storing the result is generating independent keys for the routers and storing the result is
more practical. If the master key were somehow compromised, all the more practical. If the master key were somehow compromised, all the
resulting keys would need to be changed. However if independent keys resulting keys would need to be changed. However if independent keys
skipping to change at page 17, line 19 skipping to change at page 17, line 19
Monitoring will also play an important role in avoiding security Monitoring will also play an important role in avoiding security
faults such as certificate expiration. Some classes of security faults such as certificate expiration. Some classes of security
fault, including issues with certificates, will affect only key fault, including issues with certificates, will affect only key
management protocols. other security faults can affect routing management protocols. other security faults can affect routing
protocols directly. However, the protocols MUST still have adequate protocols directly. However, the protocols MUST still have adequate
operational mechanisms to recover from these situations. Also, some operational mechanisms to recover from these situations. Also, some
faults, such as those resulting from a compromise or actual attack on faults, such as those resulting from a compromise or actual attack on
a facility are inherent and may not be prevented. a facility are inherent and may not be prevented.
A second class of faults is equipment faults that impact security. A second class of faults is equipment faults that impact security.
For example if keys are stored on a router and never moved from that For example if keys are stored on a router and never exported from
device, failure of a router implies a need to update security that device, failure of a router implies a need to update security
provisioning on the replacement router and its peers. provisioning on the replacement router and its peers.
One approach, recommended by work on securing BGP One approach, recommended by work on securing BGP
[I-D.ietf-sidr-rtr-keying] is to maintain the router's keying [I-D.ietf-sidr-rtr-keying] is to maintain the router's keying
material so that when a router is replaced the same keys can be used. 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 Router keys can be maintained on a central server. These approaches
permit the credentials of a router to be recovered. This provides permit the credentials of a router to be recovered. This provides
valuable options in case of hardware fault. The failing router can valuable options in case of hardware fault. The failing router can
be recovered without changing credentials on other routers or waiting be recovered without changing credentials on other routers or waiting
for keys to be certified. One disadvantage of this approach is that for keys to be certified. One disadvantage of this approach is that
even if public-key cryptography is used, the private keys are located 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 more than just the router. a system in which keys were generated
on a router and never exported from that router would typically make on a router and never exported from that router would typically make
it more difficult for an attacker to obtain the keys. For most it more difficult for an attacker to obtain the keys. For most
environments the ability to quickly replace a router justifies environments the ability to quickly replace a router justifies
maintaining keys centrally. maintaining keys centrally.
More generally keying is another item of configuration that needs to More generally keying is another item of configuration that needs to
be restored to restore service when equipment fails. Operators be restored to restore service when equipment fails. Operators
typically perform the minimal configuration necessary to get a router typically perform the minimal configuration necessary to get a router
back in contact with the management server. The same would apply for back in contact with the management server. The same would apply for
keys. Operators who do not maintain copies of key material for keys. Operators who do not maintain copies of key material for
skipping to change at page 20, line 5 skipping to change at page 20, line 5
removed will generate a new fresh key. Group key management removed will generate a new fresh key. Group key management
protocols are RECOMMENDED to support an option to export existing protocols are RECOMMENDED to support an option to export existing
manual keys during initial deployment of automated key management. manual keys during initial deployment of automated key management.
8. Security Considerations 8. Security Considerations
This document does not define a protocol. It does discuss the This document does not define a protocol. It does discuss the
operational and management implications of several security operational and management implications of several security
technologies. technologies.
9. Acknowledgments 9. IANA Considerations
This document has no actions for IANA.
10. Acknowledgments
Funding for Sam Hartman's work on this memo is provided by Huawei. Funding for Sam Hartman's work on this memo is provided by Huawei.
The authors would like to thank Bill Atwood , Randy Bush, Wes George, The authors would like to thank Bill Atwood , Randy Bush, Wes George,
Gregory Lebovitz, and Russ White for valuable reviews. Gregory Lebovitz, and Russ White for valuable reviews.
10. References 11. References
10.1. Normative References 11.1. Normative References
[I-D.ietf-karp-crypto-key-table] [I-D.ietf-karp-crypto-key-table]
Housley, R., Polk, T., Hartman, S., and D. Zhang, Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys", "Database of Long-Lived Symmetric Cryptographic Keys",
draft-ietf-karp-crypto-key-table-07 (work in progress), draft-ietf-karp-crypto-key-table-07 (work in progress),
March 2013. March 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References 11.2. Informative References
[I-D.ietf-karp-design-guide] [I-D.ietf-karp-design-guide]
Lebovitz, G. and M. Bhatia, "Keying and Authentication for Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", Routing Protocols (KARP) Design Guidelines",
draft-ietf-karp-design-guide-10 (work in progress), draft-ietf-karp-design-guide-10 (work in progress),
December 2011. December 2011.
[I-D.ietf-sidr-rtr-keying] [I-D.ietf-sidr-rtr-keying]
Turner, S., Patel, K., and R. Bush, "Router Keying for Turner, S., Patel, K., and R. Bush, "Router Keying for
BGPsec", draft-ietf-sidr-rtr-keying-01 (work in progress), BGPsec", draft-ietf-sidr-rtr-keying-01 (work in progress),
 End of changes. 15 change blocks. 
52 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/