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


   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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
   ( 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",
   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

   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

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

   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

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

              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.

              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


   Dacheng Zhang


Hartman & Zhang          Expires January 6, 2011               [Page 17]