draft-ietf-karp-ops-model-00.txt   draft-ietf-karp-ops-model-01.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: October 8, 2011 Huawei Expires: April 25, 2012 Huawei
April 6, 2011 October 23, 2011
Operations Model for Router Keying Operations Model for Router Keying
draft-ietf-karp-ops-model-00.txt draft-ietf-karp-ops-model-01.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 across protocols will be critical to the success
of routing protocol security efforts. This document discusses issues of routing protocol security efforts. This document discusses issues
and begins to consider development of these models. and begins to consider development of these models.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 October 8, 2011. This Internet-Draft will expire on April 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
3. Breakdown of KARP configuration . . . . . . . . . . . . . . . 5 3. Breakdown of KARP configuration . . . . . . . . . . . . . . . 5
3.1. Integrity of the Key Table . . . . . . . . . . . . . . . . 6 3.1. Integrity of the Key Table . . . . . . . . . . . . . . . . 6
3.2. Management of Key Table . . . . . . . . . . . . . . . . . 6 3.2. Management of Key Table . . . . . . . . . . . . . . . . . 6
3.3. Protocol Limitations from the Key Table . . . . . . . . . 7 3.3. Protocol Limitations from the Key Table . . . . . . . . . 7
3.4. VRFs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. VRFs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Credentials and Authorization . . . . . . . . . . . . . . . . 8 4. Credentials and Authorization . . . . . . . . . . . . . . . . 9
4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 11 4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 12
4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 11 4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 12
4.4. The role of Central Servers . . . . . . . . . . . . . . . 12 4.4. The role of Central Servers . . . . . . . . . . . . . . . 13
5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 13 5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 14
6. Administrator Involvement . . . . . . . . . . . . . . . . . . 15 6. Administrator Involvement . . . . . . . . . . . . . . . . . . 16
6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 15 6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 16
7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 17 7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 18
8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
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 36 skipping to change at page 5, line 36
configured per-link, they can get out of sync. In order to support configured per-link, they can get out of sync. In order to support
generality of configuration and common operational situations, it generality of configuration and common operational situations, it
would be desirable to have some sort of inheritance where default would be desirable to have some sort of inheritance where default
configurations are made per-area unless overridden per-interface. configurations are made per-area unless overridden per-interface.
As described in [I-D.housley-saag-crypto-key-table], the As described in [I-D.housley-saag-crypto-key-table], the
cryptographic keys are separated from the interface configuration cryptographic keys are separated from the interface configuration
into their own configuration store. This document should specify how into their own configuration store. This document should specify how
key selection interacts with the key table. One possible approach key selection interacts with the key table. One possible approach
would be to assume that all keys that permit use on a given interface would be to assume that all keys that permit use on a given interface
would be used on that interface. This model would need to be would be used on that interface with no additional configuration
expanded in cases where keys are configured per-area or per-domain. steps. If this model is adopted then the key table draft should be
It's not clear why "all" is permitted as an interface specification expanded to permit specification of domains and areas as well. It's
in this model; it seems unlikely that it would be desirable to use not clear why "all" is permitted as an interface specification in
the same set of keys for two different instances of an IGP or across this model; it seems unlikely that it would be desirable to use the
same set of keys for two different instances of an IGP or across
autonomous system boundaries. autonomous system boundaries.
Another model is that the interface specification in the key table is Another model is that the interface specification in the key table is
a restriction. Then a set of keys from the key table is attached to a restriction that limits keys on top of other configuration enabling
an interface, area or routing domain using an additional them. Then a set of keys from the key table is attached to an
configuration step. This avoids the previous problems at the expense interface, area or routing domain using an additional configuration
of significant complexity of configuration. step. This avoids the previous problems at the expense of
significant complexity of configuration.
Operational Requirements: KARP MUST support configuration of keys at Operational Requirements: KARP MUST support configuration of keys at
the most general scope for the underlying protocol; protocols the most general scope for the underlying protocol; protocols
supporting per-peer keys MUST permit configuration of per-peer keys, supporting per-peer keys MUST permit configuration of per-peer keys,
protocols supporting per-interface keys MUST support configuration of protocols supporting per-interface keys MUST support configuration of
per-interface keys, and so on. KARP MUST NOT permit configuration of per-interface keys, and so on. KARP MUST NOT permit configuration of
an inappropriate key scope. For example, configuration of separate an inappropriate key scope. For example, configuration of separate
keys per interface MUST NOT be supported for a protocol requiring keys per interface MUST NOT be supported for a protocol requiring
per-area keys. per-area keys.
skipping to change at page 7, line 40 skipping to change at page 7, line 43
globally scoped identifier. There is nothing wrong with this globally scoped identifier. There is nothing wrong with this
restriction, but it does need to be noted when assigning key IDs for restriction, but it does need to be noted when assigning key IDs for
a domain. a domain.
Consideration is required for how an automated key management Consideration is required for how an automated key management
protocol will assign key IDs for group keys. All members of the protocol will assign key IDs for group keys. All members of the
group may need to use the same key ID. This requires careful group may need to use the same key ID. This requires careful
coordination of global key IDs. Interactions with the peer key ID coordination of global key IDs. Interactions with the peer key ID
field may make this easier; this requires additional study. field may make this easier; this requires additional study.
Automated key management protocols also assign keys for single peers.
If the key ID is global and needs to be coordinated between the
receiver and transmitter, then there is complexity in key management
protocols.
3.4. VRFs 3.4. VRFs
Many core and enterprise routers support multiple routing instances. Many core and enterprise routers support multiple routing instances.
For example a router serving multiple VPNs is likely to have a For example a router serving multiple VPNs is likely to have a
forwarding/routing instance for each of these VPNs. We need to forwarding/routing instance for each of these VPNs. We need to
decide how the key table and other configuration information for KARP decide how the key table and other configuration information for KARP
interacts with this. The obvious first-order answer is that each interacts with this. The obvious first-order answer is that each
routing instance gets its own key table. However, we need to routing instance gets its own key table. However, we need to
consider how these instances interact with each other and confirm consider how these instances interact with each other and confirm
this makes sense. this makes sense.
skipping to change at page 9, line 15 skipping to change at page 10, line 15
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 one peer. This is an interesting security property: it is just oneother peer. This is an interesting security property: unlike
impossible to identify the peer sending a message cryptographically; with digitally signed messages or protocols where symmetric keys are
it is only possible to identify a group of peers using cryptographic known only to two parties, it is impossible to identify the peer
means. Within the routing threat model the peer sending a message sending a message cryptographically. However, it is possible to show
can be identified only because peers are trusted and thus can be that the sender of a message is one of the parties who knows the
assumed to correctly label the packets they send. This contrasts 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 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.
However, for the process of authorization, it would be more Doing an additional check for authorization based on the identity
complicated to identify peers this way and would not gain a security included in the packet would provide little value: an attacker who
benefit in most deployments. 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 function similarly to manual Preshared keys used with key derivation function similarly to manual
preshared keys. However to form the actual traffic keys, session or preshared keys. However to form the actual traffic keys, session or
peer specific information is combined with the key. From an peer specific information is combined with the key. From an
authorization standpoint, the derivation key works the same as a authorization standpoint, the derivation key works the same as a
manual key. An additional routing protocol step or transport step manual key. An additional routing protocol step or transport step
forms the key that is actually used. forms the key that is actually used.
Preshared keys that are used via automatic key management have not Preshared keys that are used via automatic key management have not
been specified. Their naming and authorization may differ. In been specified for KARP. 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. particular, such keys may end up being known only by two peers.
Alternatively they may also be known by a group of peers. Alternatively they may also be known by a group of peers.
Authorization could potentially be based on peer identity, although Authorization could potentially be based on peer identity, although
it is likely that knowing the right key will be sufficient. There it is likely that knowing the right key will be sufficient. There
does not appear to be a compelling reason to decouple the does not appear to be a compelling reason to decouple the
authorization of a key for some purpose from authorization of peers authorization of a key for some purpose from authorization of peers
holding that key to perform the authorized function. holding that key to perform the authorized function.
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 distinguish a router on for two interfaces: it becomes impossible to cryptographically
one interface from a router on another interface. So, a router that distinguish a router on one interface from a router on another
is trusted to participate in a routing protocol on one interface interface. So, a router that is trusted to participate in a routing
becomes implicitly trusted for the other interfaces that share the protocol on one interface becomes implicitly trusted for the other
key. For many cases, such as link-state routers in the same routing interfaces that share the key. For many cases, such as link-state
area, there is no significant advantage that an attacker could gain routers in the same routing area, there is no significant advantage
from this trust within the KARP threat model. However, distance- that an attacker could gain from this trust within the KARP threat
vector protocols, such as BGP and RIP, permit routes to be filtered model. However, distance-vector protocols, such as BGP and RIP,
across a trust boundary. For these protocols, participation in one permit routes to be filtered across a trust boundary. For these
interface might be more advantageous than another. Operationally, protocols, participation in one interface might be more advantageous
when this trust distinction is important to a deployment, different than another. Operationally, when this trust distinction is
keys need to be used on each side of the trust boundary. Key important to a deployment, different keys need to be used on each
derivation can help prevent this problem in cases of accidental side of the trust boundary. Key derivation can help prevent this
misconfiguration. However, key derivation cannot protect against a problem in cases of accidental misconfiguration. However, key
situation where a system was incorrectly trusted to have the key used derivation cannot protect against a situation where a system was
to perform the derivation. To the extent that there are multiple incorrectly trusted to have the key used to perform the derivation.
zones of trust and a routing protocol is determining whether a To the extent that there are multiple zones of trust and a routing
particular router is within a certain zone, the question of untrusted protocol is determining whether a particular router is within a
actors is within the scope of the routing threat model. certain zone, the question of untrusted actors is within the scope of
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. Provider 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
are used, the scope of a compromise may be more limited. are used, the scope of a compromise may be more limited.
More subtle problems with key separation can appear in protocol More subtle problems with key separation can appear in protocol
design. Two protocols that use the same traffic keys may work design. Two protocols that use the same traffic keys may work
together in unintended ways permitting one protocol to be used to together in unintended ways permitting one protocol to be used to
skipping to change at page 21, line 23 skipping to change at page 22, line 23
October 2010. October 2010.
[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.
11.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-02 (work in progress), draft-ietf-karp-design-guide-07 (work in progress),
March 2011. October 2011.
[I-D.liu-ospfv3-automated-keying-req] [I-D.liu-ospfv3-automated-keying-req]
Liu, Y., "OSPFv3 Automated Group Keying Requirements", Liu, Y., "OSPFv3 Automated Group Keying Requirements",
draft-liu-ospfv3-automated-keying-req-01 (work in draft-liu-ospfv3-automated-keying-req-01 (work in
progress), July 2007. progress), July 2007.
[I-D.polk-saag-rtg-auth-keytable] [I-D.polk-saag-rtg-auth-keytable]
Polk, T. and R. Housley, "Routing Authentication Using A Polk, T. and R. Housley, "Routing Authentication Using A
Database of Long-Lived Cryptographic Keys", Database of Long-Lived Cryptographic Keys",
draft-polk-saag-rtg-auth-keytable-05 (work in progress), draft-polk-saag-rtg-auth-keytable-05 (work in progress),
 End of changes. 13 change blocks. 
62 lines changed or deleted 76 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/