One document matched: draft-hartman-karp-ops-model-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY design-guide PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-karp-design-guide.xml'>
    <!ENTITY ospf-auto PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.liu-ospfv3-automated-keying-req.xml'>

    <!ENTITY RFC4552 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4552.xml'>
    <!ENTITY RFC2328 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml'>
    <!ENTITY RFC2154 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2154.xml'>
 <!ENTITY RFC5709 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5709.xml'>
]>


<rfc category="info" ipr="trust200902" docName="draft-hartman-karp-ops-model-00.txt">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

    <front>
    <title>Operations Model for Router Keying</title>
    <author initials="S." surname="Hartman" fullname="Sam Hartman">
      <organization>Painless Security</organization>
      <address>
	<email>hartmans-ietf@mit.edu</email>
      </address>
    </author>
    <author initials="D." surname="Zhang" fullname="Dacheng Zhang">
      <organization>Huawei</organization>
      <address>
	<email>zhangdacheng@huawei.com</email>
      </address>
    </author>
        <date/>
    <abstract>
      <t>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.</t>
    </abstract>
    </front>

    <middle>
    <section title="Introduction">
      <t>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.</t>
      <t>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.</t>
    </section>
        <section title="Requirements notation">
            <t>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 <xref target="RFC2119"/>.</t>
        </section>
    <section title="Breakdown of KARP configuration">
      <t>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.</t>
      <t>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 <xref target="PRESHARED"/>, key separation is an important concern when the same key is used in multiple contexts.</t>
      <t>Which of these approaches seems best may depend on the types
      of authentication being used. The following section discusses this.</t>
    </section>
    <section title="Credentials and Authorization">
      <t>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.</t>
      <t>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.</t>
      <t>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.</t>
      <t>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.</t>
      <t>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.</t>
      <section anchor="PRESHARED" title="Preshared Keys">
	<t>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.</t>
	<t>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 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.</t>
	<t>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.</t>
	<t>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.</t>
	<t>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 to be analyzed to understand the scope of potential attacks. </t>
	<t>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.</t>
      </section>
      <section title="Public Keys">
	<t>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.</t>
	<t>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.</t>
	<t>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.</t>
      </section>
      <section title="Public Key Infrastructure">
	<t>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. </t>
	<t>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 continue functioning even though the key
	has never been seen before. </t>
	<t>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.</t>
	<t>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.</t>
      </section>
      <section title="The role of Central Servers">
	<t>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. </t>
	<t>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.</t>
	<t>Another area where central servers may play a role is for group key agreement. As an example, <xref target="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.</t>
      </section>
    </section>
    <section title="Grouping Peers Together">
      <t>Discuss abstractions to manage interfaces, ASes, etc that
      have similar authorization sets.</t>
    </section>
    <section title="Administrator Involvement">
      <t>One key operational question is what areas will administrator
      involvement be required. Likely areas where involvement may be
      useful includes enrollment of new peers.</t>
    </section>
    <section title="Upgrade Considerations">
      <t>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.</t>
    </section>
    <section title="Related Work">
      <t>Discuss draft-housley-saag-*, draft-polk-saag-*, the discussions in the KARP framework, etc.</t>
    </section>
    <section title="Security Considerations">
      <t>This document does not define a protocol. It does discuss the operational and management implications of several security technologies.</t>
    </section>
    <section title="Acknowledgments">
      <t>Funding for Sam Hartman's work on this memo is provided by Huawei.</t>
    </section>
    </middle>

    <back>
    <references title="Normative References">
      &rfc2119;
    </references>
    <references title="Informative References">
&ospf-auto;
      &design-guide;
      &RFC2328;
    </references>
    </back>

</rfc>