Network Working Group S. Hartman
Internet-Draft Painless Security
Intended status: Informational D. Zhang
Expires: January 6, 2011 Huawei
July 5, 2010
Operations Model for Router Keying
draft-hartman-karp-ops-model-00.txt
Abstract
Developing an operational and management model for routing protocol
security that works across protocols will be critical to the success
of routing protocol security efforts. This document discusses issues
and begins to consider development of these models.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 6, 2011.
Copyright Notice
Copyright (c) 2010 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
Hartman & Zhang Expires January 6, 2011 [Page 1]
Internet-Draft Operations Model for Router Keying July 2010
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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
3. Breakdown of KARP configuration . . . . . . . . . . . . . . . 5
4. Credentials and Authorization . . . . . . . . . . . . . . . . 6
4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 8
4.4. The role of Central Servers . . . . . . . . . . . . . . . 9
5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 10
6. Administrator Involvement . . . . . . . . . . . . . . . . . . 11
7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 12
8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Hartman & Zhang Expires January 6, 2011 [Page 2]
Internet-Draft Operations Model for Router Keying July 2010
1. Introduction
The KARP working group is designing improvements to the cryptographic
authentication of IETF routing protocols. These improvements include
improvements to how integrity functions are handled within each
protocol as well as designing an automated key management solution.
This document discusses issues to consider when thinking about the
operational and management model for KARP. Each implementation will
take its own approach to management; this is one area for vendor
differentiation. However, it is desirable to have a common baseline
for the management objects allowing administrators, security
architects and protocol designers to understand what management
capabilities they can depend on in heterogeneous environments.
Similarly, designing and deploying the protocol will be easier with
thought paid to a common operational model. This will also help with
the design of NetConf schemas or MIBs later.
Hartman & Zhang Expires January 6, 2011 [Page 3]
Internet-Draft Operations Model for Router Keying July 2010
2. 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 [RFC2119].
Hartman & Zhang Expires January 6, 2011 [Page 4]
Internet-Draft Operations Model for Router Keying July 2010
3. Breakdown of KARP configuration
There are multiple ways of structuring configuration information.
For example consider OSPF [RFC2328]. Each 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. One approach
would be to configure each key as a property of the link. Another
approach would be to notice that it is common to use the same
authentication information across an area and configure the keys as a
property of the area. Doing so makes configuration easier in a
common case at the expense of generality. If keys are configured
per-area then the system may not support configuring different keys
for links in the same area. Another option would be to have some
sort of inheritance where default configurations are made per-area
unless overridden per-interface.
An implementation could directly store the information about a given
key in its configuration scope. That is, if the key was configured
on an interface, then the parameters of that key would be stored with
the interface. Alternatively, some abstract key object could be
associated with multiple interfaces. This approach might be more
complicated but would make it easier to update a key if the same key
were used for multiple protocols or in multiple configuration scopes.
As discussed in Section 4.1, key separation is an important concern
when the same key is used in multiple contexts.
Which of these approaches seems best may depend on the types of
authentication being used. The following section discusses this.
Hartman & Zhang Expires January 6, 2011 [Page 5]
Internet-Draft Operations Model for Router Keying July 2010
4. Credentials and Authorization
Several methods for authentication have been proposed for KARP. The
simplest is preshared keys used directly as traffic keys. In this
mode, the traffic integrity keys are directly configured. This is
the mode supported by today's routing protocols.
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.
Public keys can be used for authentication. The design guide
[I-D.ietf-karp-design-guide] 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 that
peer 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. 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 is 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.
4.1. Preshared Keys
In the protocol, manual preshared keys are either unnamed or named by
a small integer key ID. Implementations that support multiple keys
for protocols that have no names for keys need to try all possible
keys before deciding a packet cannot be validated. Typically key IDs
are names valid only in the scope of one interface or peer.
Manual preshared keys are often known by a group of peers not just
one peer. This is an interesting security property: it is impossible
to identify the peer sending a message cryptographically; it is only
Hartman & Zhang Expires January 6, 2011 [Page 6]
Internet-Draft Operations Model for Router Keying July 2010
possible to identify a group of peers using cryptographic means. 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. However, for the process of authorization, it would
be more complicated to identify peers this way and would not gain a
security benefit in most deployments.
Preshared keys that are used via automatic key management have not
been specified. Their naming and authorization may differ. 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 authorization of peers
holding that key to perform the authorized function.
Care needs to be taken when symmetric keys are used for multiple
purposes. Consider the implications of using the same preshared key
for two interfaces: it becomes impossible to distinguish a router on
one interface from a router on another interface. So, a router that
is trusted to participate in a routing protocol on one interface
becomes implicitly trusted for the other interfaces that share the
key. For many cases, such as OSPF routers in the same area, there is
no significant advantage that an attacker could gain from this trust
within the KARP threat model. However, other protocols, such as RIP,
permit routes from a particular interface to be filtered. For these
protocols, participation in one interface might be more advantageous
than another.
More subtle problems with key separation can appear in protocol
design. Two protocols that use the same traffic keys may work
together in unintended ways permitting one protocol to be used to
attack the other. Consider two hypothetical protocols. Protocol A
starts its messages with a set of extensions that are ignored if not
understood. Protocol B has a fixed header at the beginning of its
messages but ends messages with extension information. It may be
that the same message is valid both as part of protocol A and
protocol B. An attacker may be able to gain an advantage by getting a
router to generate this message with one protocol under situations
where the other protocol would not generate the message. This
hypothetical example is overly simplistic; real-world attacks
exploiting key separation weaknesses tend to be complicated and
involve specific properties of the cryptographic functions involved.
The key point is that whenever the same key is used in multiple
protocols, attacks may be possible. All the involved protocols need
Hartman & Zhang Expires January 6, 2011 [Page 7]
Internet-Draft Operations Model for Router Keying July 2010
to be analyzed to understand the scope of potential attacks.
Key separation attacks interact with the KARP operational model in a
number of ways. Administrators need to be aware of situations where
using the same manual traffic key with two different protocols (or
the same protocol in different contexts) creates attack
opportunities. Design teams should consider how their protocol might
interact with other routing protocols and describe any attacks
discovered so that administrators can understand the operational
implications. When designing automated key management or new
cryptographic authentication within routing protocols, we need to be
aware that administrators expect to be able to use the same preshared
keys in multiple contexts. As a result, we should use appropriate
key derivation functions so that different cryptographic keys are
used even when the same initial input key is used.
4.2. Public Keys
Outside of a PKI, public keys are expected to be known by the hash of
a key or (potentially self-signed) certificate. The Session
Description Protocol provides a standardized mechanism for naming
keys (in that case certificates) based on hashes. 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.
4.3. Public Key Infrastructure
When a PKI is used, certificates are used. The certificate binds a
key to a name of a peer. The key management protocol is responsible
for exchanging certificates and validating them to a trust anchor.
Authorization needs to be done in terms of peer identities not in
terms of keys. One reason for this is that when a peer changes its
key, the new certificate needs to be sufficient for authentication to
Hartman & Zhang Expires January 6, 2011 [Page 8]
Internet-Draft Operations Model for Router Keying July 2010
continue functioning even though the key has never been seen before.
Potentially authorization could be performed in terms of groups of
peers rather than single peers. An advantage of this is that it may
be possible to add a new router with no authentication related
configuration of the peers of that router.
Assuming that potentially self-signed certificates are used by
routers that wish to use public keys but that do not need a PKI, then
PKI and the infrastructureless mode of public-key operation described
in the previous section can work well together. One router could
identify its peers based on names and use certificate validation.
Another router could use hashes of certificates. This could be very
useful for border routers between two organizations. Smaller
organizations could use public keys and larger organizations could
use PKI.
4.4. The role of Central Servers
An area to explore is the role of central servers like RADIUS or
directories. As discussed in the design-guide, a system where keys
are pushed by a central management system is undesirable as an end
result for KARP. However central servers may play a role in
authorization and key rollover. For example a node could send a hash
of a public key to a RADIUS server.
If central servers do play a role it will be critical to make sure
that they are not required during routine operation or a cold-start
of a network. They are more likely to play a role in enrollment of
new peers or key migration/compromise.
Another area where central servers may play a role is for group key
agreement. As an example, [I-D.liu-ospfv3-automated-keying-req]
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.
Hartman & Zhang Expires January 6, 2011 [Page 9]
Internet-Draft Operations Model for Router Keying July 2010
5. Grouping Peers Together
Discuss abstractions to manage interfaces, ASes, etc that have
similar authorization sets.
Hartman & Zhang Expires January 6, 2011 [Page 10]
Internet-Draft Operations Model for Router Keying July 2010
6. Administrator Involvement
One key operational question is what areas will administrator
involvement be required. Likely areas where involvement may be
useful includes enrollment of new peers.
Hartman & Zhang Expires January 6, 2011 [Page 11]
Internet-Draft Operations Model for Router Keying July 2010
7. Upgrade Considerations
It needs to be possible to deploy automated key management in an
organization without either having to disable existing security or
disrupting routing. As a result, it needs to be possible to perform
a phased upgrade from manual keying to automated key management.
Hartman & Zhang Expires January 6, 2011 [Page 12]
Internet-Draft Operations Model for Router Keying July 2010
8. Related Work
Discuss draft-housley-saag-*, draft-polk-saag-*, the discussions in
the KARP framework, etc.
Hartman & Zhang Expires January 6, 2011 [Page 13]
Internet-Draft Operations Model for Router Keying July 2010
9. Security Considerations
This document does not define a protocol. It does discuss the
operational and management implications of several security
technologies.
Hartman & Zhang Expires January 6, 2011 [Page 14]
Internet-Draft Operations Model for Router Keying July 2010
10. Acknowledgments
Funding for Sam Hartman's work on this memo is provided by Huawei.
Hartman & Zhang Expires January 6, 2011 [Page 15]
Internet-Draft Operations Model for Router Keying July 2010
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[I-D.ietf-karp-design-guide]
Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines",
draft-ietf-karp-design-guide-00 (work in progress),
February 2010.
[I-D.liu-ospfv3-automated-keying-req]
Liu, Y., "OSPFv3 Automated Group Keying Requirements",
draft-liu-ospfv3-automated-keying-req-01 (work in
progress), July 2007.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
Hartman & Zhang Expires January 6, 2011 [Page 16]
Internet-Draft Operations Model for Router Keying July 2010
Authors' Addresses
Sam Hartman
Painless Security
Email: hartmans-ietf@mit.edu
Dacheng Zhang
Huawei
Email: zhangdacheng@huawei.com
Hartman & Zhang Expires January 6, 2011 [Page 17]