DIME                                                  H. Tschofenig, Ed.
Internet-Draft                                    Nokia Siemens Networks
Intended status:  Standards Track                            J. Korhonen
Expires:  August 22, 2013                                 Renesas Mobile
                                                                 G. Zorn
                                                             Network Zen
                                                       February 18, 2013


        Diameter AVP Level Security: Requirements and Scenarios
                draft-tschofenig-dime-e2e-sec-req-00.txt

Abstract

   This specification discusses requirements for providing Diameter
   security at the level of individual Attribute Value Pairs.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on August 22, 2013.

Copyright Notice

   Copyright (c) 2013 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
   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 Simplified BSD License.



Tschofenig, et al.       Expires August 22, 2013                [Page 1]


Internet-Draft         Diameter AVP Level Security         February 2013


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11






































Tschofenig, et al.       Expires August 22, 2013                [Page 2]


Internet-Draft         Diameter AVP Level Security         February 2013


1.  Introduction

   The Diameter Base specification [1] 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.

   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) [3].  Due to lack of deployment
   interest at that time (and the complexity of the developed solution)
   the specification was, however, never completed.

   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 [3] was discontinued) the Internet community had
   seen advances in cryptographic algorithms (for example, authenticated
   encryption algorithms were developed) and new requirements emerged.

   This document collects requirements for developing a solution to
   protect Diameter AVPs.























Tschofenig, et al.       Expires August 22, 2013                [Page 3]


Internet-Draft         Diameter AVP Level Security         February 2013


2.  Terminology

   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 [2].

   This document re-uses terminology from the Diameter base
   specification [1].











































Tschofenig, et al.       Expires August 22, 2013                [Page 4]


Internet-Draft         Diameter AVP Level Security         February 2013


3.  Use Case

   Consider the following use case shown in Figure 1.  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.


   ****************************
                              *
      Realm: Example.com      *
   +--------+      +--------+ *      +--------+        +--------+
   |Diameter|      |Diameter| *      |Diameter|        |Diameter|
   |Client  +------+Proxy A +-*------+Proxy B +--------+Server  |
   +--------+      +--------+ *      +--------+        +--------+
       ^                      *                             ^
       .           End-to-End * Security Protection         .
       +......................*.............................+
                              *
   ****************************


               Figure 1: Example Diameter Deployment Setup.

   The Diameter AVPs are protected end-to-end, from the Diameter client
   to the Diameter server, as shown in Figure 1 with the dotted line.

   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.

      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?















Tschofenig, et al.       Expires August 22, 2013                [Page 5]


Internet-Draft         Diameter AVP Level Security         February 2013


4.  Requirements

   Requirement #1:  Solutions MUST support an extensible set of
      cryptographic algorithms.

         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.

   Requirement #2:  Solutions MUST support confidentiality, integrity,
      and data-origin authentication.

         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?

   Requirement #3:  Solutions MUST support replay protection.

         QUESTION:  Should replay protection be based on timestamps
         (i.e., assume synchronized clocks in Diameter networks)?

   Requirement #4:  Solutions MUST be able to selectively apply their
      cryptographic protection to certain Diameter AVPs.

   Requirement #5:  Solutions MUST recommend a mandatory-to-implement
      cryptographic algorithm.

   Requirement #6:  QUESTION:  Should we support symmetric keys and / or
      also asymmetric keys?

   Requirement #7:  QUESTION:  Should requirements for dynamic key
      management be included in this document as well?

   Requirement #8:  QUESTION:  Should statically provisioned keys be
      supported?

   Requirement #9:  QUESTION:  Should solutions allow the provisioning
      of long-term shared symmetric credentials via a command-line
      interface / text file?









Tschofenig, et al.       Expires August 22, 2013                [Page 6]


Internet-Draft         Diameter AVP Level Security         February 2013


5.  Security Considerations

   This entire document focused on the discussion of new functionality
   for securing Diameter AVPs end-to-end.















































Tschofenig, et al.       Expires August 22, 2013                [Page 7]


Internet-Draft         Diameter AVP Level Security         February 2013


6.  IANA Considerations

   This document does not require actions by IANA.
















































Tschofenig, et al.       Expires August 22, 2013                [Page 8]


Internet-Draft         Diameter AVP Level Security         February 2013


7.  Acknowledgments

   We would like to thank Guenther Horn for his review comments.
















































Tschofenig, et al.       Expires August 22, 2013                [Page 9]


Internet-Draft         Diameter AVP Level Security         February 2013


8.  References

8.1.  Normative References

   [1]  Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter
        Base Protocol", RFC 6733, October 2012.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References

   [3]  Calhoun, P., Farrell, S., and W. Bulley, "Diameter CMS Security
        Application", draft-ietf-aaa-diameter-cms-sec-04 (work in
        progress), March 2002.




































Tschofenig, et al.       Expires August 22, 2013               [Page 10]


Internet-Draft         Diameter AVP Level Security         February 2013


Authors' Addresses

   Hannes Tschofenig (editor)
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Phone:  +358 (50) 4871445
   Email:  Hannes.Tschofenig@gmx.net
   URI:    http://www.tschofenig.priv.at


   Jouni Korhonen
   Renesas Mobile
   Porkkalankatu 24
   Helsinki  00180
   Finland

   Email:  jouni.nospam@gmail.com


   Glen Zorn
   Network Zen
   227/358 Thanon Sanphawut
   Bang Na  Bangkok 10260
   Thailand

   Email:  glenzorn@gmail.com






















Tschofenig, et al.       Expires August 22, 2013               [Page 11]