<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.ietf-karp-crypto-key-table PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-karp-crypto-key-table.xml">
<!ENTITY I-D.farrell-decade-ni PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.farrell-decade-ni.xml">
<!ENTITY RFC6733 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6733.xml">
<!ENTITY RFC4107 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4107.xml">
<!ENTITY RFC4301 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
]>

<?rfc inline="yes"?>
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?> 
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>


<rfc category='std' ipr='trust200902' docName='draft-tschofenig-dime-keying-database-00.txt'>


  <front>
    <title abbrev="Diameter Keying Database">A Keying Database for Diameter End-to-End Security</title>

    <author role="editor" initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization>Nokia Siemens Networks</organization>
      <address>
        <postal>
          <street>Linnoitustie 6</street>
          <city>Espoo</city>
          <code>02600</code>
          <country>Finland</country>
        </postal>
        <phone>+358 (50) 4871445</phone>
        <email>Hannes.Tschofenig@gmx.net</email>
        <uri>http://www.tschofenig.priv.at</uri>
      </address>
    </author>
 
    <date year='2013'/>
    <area>OPS</area>
    <workgroup>DIME</workgroup>
    <keyword>I-D</keyword>
    <keyword>Internet-Draft</keyword>
    <keyword>Diameter</keyword>
    <keyword>End-to-End Security</keyword>


    <abstract>
   
<t>The Diameter Base specification offers security protection between neighboring Diameter peers using TLS, DTLS, and IPsec. The development of a solution to protect Diameter Attribute Value Pairs between non-neighboring nodes is currently work in progress.</t>

<t>Diameter nodes maintain different types of databases, depending on their functions. Examples include the peer table and the realm-based routing table. This document describes a conceptual model for a keying database as it would be used by a Diameter node to determine what AVPs to protect, and what keys / algorithms to use. On the receiving side it allows the receiving node to select the appropriate security association for verifying the protected AVPs. The design is similar to IPsec and inspired by the routing protocol security key table. </t>
  </abstract>
  </front>
  <middle>
    
    <section title='Introduction'>
    
	<t>The Diameter Base specification <xref target="RFC6733"/> offers security protection between neighboring Diameter peers and mandates that either TLS (for TCP), DTLS (for SCTP), or IPsec is used. These security protocols offer a wide range of security properties, including entity authentication, data-origin authentication, integrity, confidentiality protection and replay protection. They also support a large number of cryptographic algorithms, algorithm negotiation, and different types of credentials.</t>

<t>In the meanwhile Diameter had received a lot of deployment interest and the need for protecting Diameter AVPs between non-neighboring nodes has been created. The requirements for Diameter end-to-end security at the level of individual AVPs is provided in [I-D.tschofenig-dime-e2e-sec-req]. <!-- <xref target="I-D.tschofenig-dime-e2e-sec-req"/>. --> </t>

<t>This document describes a conceptual model for a keying database as it would be used by a Diameter node to determine what AVPs to protect, what keys and algorithms to use. On the receiving side it allows the receiving node to select the appropriate security association for verifying the protected AVPs. The design is similar to IPsec <xref target="RFC4301"/> and inspired by the routing protocol security key table <xref target="I-D.ietf-karp-crypto-key-table"/>. </t>

	  </section>
	  
      <section title='Terminology'>
        <t>
          The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD',
          'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this specification are to be
          interpreted as described in <xref target='RFC2119' />.
        </t>
      </section>


	  	<section title="Conceptual Keying Database">

<t>Diameter nodes maintain different types of databases, depending on their functions. Examples include the peer table and the realm-based routing table. The usage of the end-to-end security mechanisms described in this document adds another database to those nodes supporting this functionality.</t>

<t>We describe the keying database in a conceptual way as a table, where each row represents a single symmetric or asymmetric key.</t>

<t>The columns that the table consists of are listed as follows:

<list style="hanging">
<t hangText="KeyName:"> The KeyName is a string identifying the key. On the sender-side it provides information about what key to use for applying integrity and/or confidentiality protection. On the receiver-side this value provides information about the key to use for verification. <!-- For an asymmetric key the LocalKeyName is a NI URI <xref target="I-D.farrell-decade-ni"/>.--> </t>

<t hangText="DestinationRealm:">The DestinationRealm provides information for the sending host to decide what messages to protect. This selector field contains information about the designation realm. The format of a DiameterIdentity. This field may be empty.</t>

<t hangText="DestinationHost:">The DestinationHost provides information for the sending host to decide what messages to protect. This selector field contains information about the destination host. The format of a DiameterIdentity. This field may be empty.</t>

<t hangText="ApplicationID:">The ApplicationID provides information for the sending host to decide what messages to protect. This field contains a list of comma separated application id values. This field may be empty. The value "*" refers to all application ids that match the DestinationRealm and/or DestinationHost field.</t>

<t hangText="AVPCodeList:">The AVPCodeList provides information for the sending host to decide what AVPs need to experience integrity, and optionally confidentiality protection. This selector field contains a list of AVP codes. The value "*" indicates that the protection covers all AVP fields included in the message.</t>

<t hangText="KDF:">The KDF field indicates which key derivation function is used to generate short-lived keys from a long-lived symmetric key in the Key field. For symmetric keys, when the long-lived shared key is intended for direct use, the KDF field is set to "none".  This document re-used the KDF algorithm registry established in <xref target="I-D.ietf-karp-crypto-key-table"/>. The protocol indicates what (if any) KDFs are valid. For asymmetric algorithm the KDF is left empty.</t>

<t hangText="AlgID:">The AlgID field indicates the cryptographic algorithm used with the security protocol. The algorithm may be an encryption algorithm and mode (such as AES-128-CBC), an authentication algorithm (such as HMAC-SHA1-96 or AES-128-CMAC), or an algorithm applicable to asymmetric cryptography (such as RS256 indicating RSA with SHA-256). If the KDF field contains "none", then a long-lived shared secret key is used directly with this algorithm, otherwise the derived short-lived symmetric key is used with this algorithm. When the long-lived key is used to generate a set of short-lived keys for use with the security protocol, the AlgID field identifies a ciphersuite rather than a single cryptographic algorithm. </t>

<t hangText="KeyType:">The KeyType provides information about the type of key found in the Key field. Two values are possible: "SymmetricKey" and "AsymmetricKey".</t>

<t hangText="Key:">The Key field contains a symmetric or an asymmetric key. A lower-case hexadecimal string is used for representing a symmetric key. For asymmetric keys the NI URI format <xref target="I-D.farrell-decade-ni"/> is used. The size of the Key field depends on the type of key, the selected KDF, and the AlgID.  For instance, a KDF=none and AlgID=AES128 requires a 128-bit symmetric key, which is represented by 32 hexadecimal digits.</t>

<t hangText="Direction:"> The Direction field indicates whether this key may be used for inbound traffic, outbound traffic, both, or whether the key has been disabled and may not currently be used at all. The supported values are "in", "out", "both", and "disabled",
respectively.</t>

<t hangText="SendNotBefore:">The NotBefore field specifies the earliest date and time in Universal Coordinated Time (UTC) at which this key should be considered for use.  The format is YYYYMMDDHHSSZ, where four digits specify the year, two digits specify the month, two digits specify the day, two digits specify the hour,  two digits specify the minute, and two digits specify the second.  The "Z" is included as a clear indication that the time is in UTC. This field is empty if the key is for immediate use. If the Direction field indicates that the key is used not used for outbound traffic then this field is ignored.</t>

<t hangText="SendNotAfter:">The SendNotAfter field specifies the latest date and time at which this key should be considered for use when sending messages. The format is the same as the SendNotBefore field.  If the Direction field indicates that the key is used not used for outbound traffic then this field is ignored.</t>

<t hangText="RcvNotBefore:">The RcvNotBefore field specifies the earliest date and time in Universal Coordinated Time (UTC) at which this key should be considered for use when processing received messages.  The format is YYYYMMDDHHSSZ, where four digits specify the year, two digits specify the month, two digits specify the day, two digits specify the hour, two digits specify the minute, and two digits specify the second.  The "Z" is included as a clear indication that the time is in UTC. This field is empty if there is no restriction regarding the use of the key when processing received messages. If the Direction field indicates that the key is used not used for inbound traffic then this field is ignored.</t>

<t hangText="RcvNotAfter:">The RcvNotAfter field specifies the latest date and time at which this key should be considered for use when processing received traffic.  The format of this field is identical to the format of NotBefore. If the Direction field indicates that the key is used not used for inbound traffic then this field is ignored.</t>

<t hangText="KeyManagement:">Specifies whether a entry was statically configured or dynamically discovered. This field may help to create a new key when the existing key is expired. An empty field indicates a statically configured key. Values are reserved for automated key management protocols.</t>
</list> 
</t>

</section> 
	  
	  <section title='Examples'>
	    <t>This section gives a few examples. For editorial reasons (i.e., the per-line character limit of Internet drafts) a list representation is used instead of a table.</t>
		<t>
		<figure title="Example Diameter Deployment Setup." anchor="example">
            <artwork>
              <![CDATA[
 +----------------+                                 +----------------+
 |                |           +----------+          |                |
 |   Diameter     |           |          |          |   Diameter     |
 |   Client       |           | Diameter |          |   Server       |
 |                |---------->| Proxy    |--------->|                |
 |                |           |          |          |                |
 +----------------+           +----------+          +----------------+

 client.example.com        proxy.example.com        server.example.com
]]>
            </artwork>
          </figure>
          </t>
		  
<t>The first example illustrates an entry in the key table at a Diameter client.
		<figure>
            <artwork>
              <![CDATA[
KeyName: abc123
DestinationRealm: 
DestinationHost: server.example.com
ApplicationID: *
AVPCodeList: *
KDF: none
AlgID: HMAC-SHA1-96
KeyType: SymmetricKey
Key: 617CAA833BEF64D88E45
Direction: out
SendNotBefore: 
SendNotAfter: 201302142000Z
RcvNotBefore: 
RcvNotAfter : 
KeyManagement: 
]]>
            </artwork>
          </figure>
          </t>
		  
<t>The second example illustrates the entries of the key database for an asymmetric key as stored at the Diameter client.
		<figure>
            <artwork>
              <![CDATA[
KeyName: abc123
DestinationRealm: 
DestinationHost: server.example.com
ApplicationID: *
AVPCodeList: *
KDF: none
AlgID: RS256
KeyType: AsymmetricKey
Key: ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q
Direction: both
SendNotBefore: 
SendNotAfter: 201302142000Z
RcvNotBefore: 
RcvNotAfter : 201302142000Z
KeyManagement: 
]]>
            </artwork>
          </figure>
          </t>
	  </section> 
	  
    <section title='Security Considerations' anchor='Security'>
  <t>This document focuses on the description of a keying database for usage with Diameter to protect AVPs end-to-end.</t> 
  
  <t>It has been recognized in <xref target="RFC4107"/> that automated key management is not viable in multiple scenarios. The conceptual database specified in this document is designed to accommodate both manual key management and automated key management. A future specification to automatically populate rows in the database is envisioned. </t>
    
  <t>Designers should recognize the warning provided in <xref target="RFC4107"/>:
  
  <list style="empty">
    <t>"Automated key management and manual key management provide very
different features. In particular, the protocol associated with
an automated key management technique will confirm the liveness of
the peer, protect against replay, authenticate the source of the
short-term session key, associate protocol state information with
the short-term session key, and ensure that a fresh short-term
session key is generated. Moreover, an automated key management
protocol can improve the interoperability by including negotiation
mechanisms for cryptographic algorithms. These valuable features
are impossible or extremely cumbersome to accomplish with manual
key management."</t>
</list> 
</t>
    </section>

    <section title='IANA Considerations' anchor='IANA'>
	 <t>[Editor's Note: An IANA consideration section will be provided in a future version of this document.]</t>
    </section>

    <section title='Acknowledgments'>
	     <t>I would like to thank the authors of <xref target="I-D.ietf-karp-crypto-key-table"/> for their work. This document is inspired by their writeup.</t>
    </section>

  </middle>

  <back>

    <references title='Normative References'>
   &RFC2119; 
   &I-D.farrell-decade-ni; 
   &RFC6733;
   
    </references>

    <references title='Informative References'>
         &I-D.ietf-karp-crypto-key-table;  
		 &RFC4107; 

		 &RFC4301; 
    </references>
  </back>

</rfc>
