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]