One document matched: draft-tschofenig-dime-e2e-sec-req-00.xml

<?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-aaa-diameter-cms-sec PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-aaa-diameter-cms-sec.xml">
<!ENTITY RFC6733 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6733.xml">
]>

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


<rfc category='std' ipr='trust200902' docName='draft-tschofenig-dime-e2e-sec-req-00.txt'>


  <front>
    <title abbrev="Diameter AVP Level Security">Diameter AVP Level Security: Requirements and Scenarios</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>
 
   <author initials='J.' surname="Korhonen" fullname='Jouni Korhonen'>
           <organization>Renesas Mobile</organization>
            <address>
                <postal>
                    <street> Porkkalankatu 24</street>
					<city>Helsinki</city>
                    <code>00180</code>
                    <country>Finland</country>
                </postal>
                <email>jouni.nospam@gmail.com</email>
             </address>
        </author>
		
		  <author initials='G.' surname="Zorn" fullname='Glen Zorn'>
           <organization abbrev="Network Zen">Network Zen</organization>
            <address>
                <postal>
                    <street>227/358 Thanon Sanphawut</street>
					<city> Bang Na</city>
                    <code>Bangkok 10260</code>
                    <country>Thailand</country>
                </postal>
                <email>glenzorn@gmail.com</email>
             </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>This specification discusses requirements for providing Diameter security at the level of individual Attribute Value Pairs.</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>The need to also offer additional security protection of AVPs between non-neighboring Diameter nodes was recognized very early in the work on Diameter. This lead to work on Diameter security using the Cryptographic Message Syntax (CMS) <xref target="I-D.ietf-aaa-diameter-cms-sec"/>. Due to lack of deployment interest at that time (and the complexity of the developed solution) the specification was, however, never completed.</t>

<t>In the meanwhile Diameter had received a lot of deployment interest from the cellular operator community and because of the sophistication of those deployments the need for protecting Diameter AVPs between non-neighboring nodes re-surfaced. Since early 2000 (when the work on <xref target="I-D.ietf-aaa-diameter-cms-sec"/> was discontinued) the Internet community had seen advances in cryptographic algorithms (for example, authenticated encryption algorithms were developed) and new requirements emerged.</t>

<t>This document collects requirements for developing a solution to protect Diameter AVPs.</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>
		<t>This document re-uses terminology from the Diameter base specification <xref target="RFC6733"/>.</t>
      </section>

	  
	  <section title="Use Case"> 

	  <t>Consider the following use case shown in <xref target="example"/>. A Diameter client interacts with a Diameter server through two Diameter proxies. The Diameter client and the Diameter Proxy A belong to the same realm, example.com.

<figure title="Example Diameter Deployment Setup." anchor="example">
            <artwork>
              <![CDATA[
****************************
                           *
   Realm: Example.com      *
+--------+      +--------+ *      +--------+        +--------+
|Diameter|      |Diameter| *      |Diameter|        |Diameter|
|Client  +------+Proxy A +-*------+Proxy B +--------+Server  |
+--------+      +--------+ *      +--------+        +--------+
    ^                      *                             ^
    .           End-to-End * Security Protection         .
    +......................*.............................+
                           *
****************************
]]>
            </artwork>
          </figure>
          </t>
		  
		  <t>The Diameter AVPs are protected end-to-end, from the Diameter client to the Diameter server, as shown in <xref target="example"/> with the dotted line.</t>

<t>Other use cases are possible as well. For example, Diameter Proxy A could act on behalf of the Diameter clients in the example.com realm. In a general case, however, encryption of AVPs between arbitrary Diameter nodes can be challenging since it is upfront not know what Diameter nodes a message will traverse.</t>

<t><list style="empty">
<t>QUESTION: Which scenarios should be supported? Should the focus be on the protection of selected Diameter AVPs between the Diameter client to the Diameter server only?</t>
</list>
</t>

	  </section> 
	  
      <section title='Requirements'>
	 
	 <t><list style="hanging"> 
<t hangText="Requirement #1:">Solutions MUST support an extensible set of cryptographic algorithms.
<list style="empty">
<t>Motivation: Crypto-agility is the ability of a protocol to adapt to evolving cryptographic algorithms and security requirements. This may include the provision of a modular mechanism to allow cryptographic algorithms to be updated without substantial disruption to deployed implementations.</t>
</list>
</t>


<t  hangText="Requirement #2:">Solutions MUST support confidentiality, integrity, and data-origin authentication.
<list style="empty">
<t>QUESTION: Should solutions for integrity protection work in a backwards-compatible way with existing Diameter applications? Should the list of integrity protected AVP be indicated in the protected payload itself?</t>
</list>
</t>


<t  hangText="Requirement #3:">Solutions MUST support replay protection.<list style="empty">
<t>QUESTION: Should replay protection be based on timestamps (i.e., assume synchronized clocks in Diameter networks)?</t>
</list>
</t>

<t  hangText="Requirement #4:">Solutions MUST be able to selectively apply their cryptographic protection to certain Diameter AVPs.</t>

<t hangText="Requirement #5:">Solutions MUST recommend a mandatory-to-implement cryptographic algorithm. </t>

<t hangText="Requirement #6:"> QUESTION: Should we support symmetric keys and / or also asymmetric keys?</t>

<t hangText="Requirement #7:"> QUESTION: Should requirements for dynamic key management be included in this document as well?</t>

<t hangText="Requirement #8:"> QUESTION: Should statically provisioned keys be supported?</t>

<t hangText="Requirement #9:"> QUESTION: Should solutions allow the provisioning of long-term shared symmetric credentials via a command-line interface / text file?</t>
 
 </list> 
 </t>
 
    </section>



    <section title='Security Considerations' anchor='Security'>
  <t>This entire document focused on the discussion of new functionality for securing Diameter AVPs end-to-end.</t> 
    </section>

    <section title='IANA Considerations' anchor='IANA'>
	 <t>This document does not require actions by IANA.</t>
    </section>

    <section title='Acknowledgments'>
	     <t>We would like to thank Guenther Horn for his review comments.</t>
    </section>

  </middle>

  <back>

    <references title='Normative References'>
   &RFC2119; 
   
   &RFC6733;
   
    </references>

    <references title='Informative References'>
   &I-D.ietf-aaa-diameter-cms-sec;  
    </references>
  </back>

</rfc>