| DIME | H. Tschofenig, Ed. |
| Internet-Draft | Nokia Siemens Networks |
| Intended status: Standards Track | J. Korhonen |
| Expires: October 13, 2013 | Renesas Mobile |
| G. Zorn | |
| Network Zen | |
| April 11, 2013 |
Diameter AVP Level Security: Requirements and Scenarios
draft-tschofenig-dime-e2e-sec-req-00.txt
This specification discusses requirements for providing Diameter security at the level of individual Attribute Value Pairs.
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 October 13, 2013.
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.
The Diameter Base specification [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.
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) [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.
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 [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.
This document collects requirements for developing a solution to protect Diameter AVPs.
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 [RFC2119].
This document re-uses terminology from the Diameter base specification [RFC6733].
****************************
*
Realm: Example.com *
+--------+ +--------+ * +--------+ +--------+
|Diameter| |Diameter| * |Diameter| |Diameter|
|Client +------+Proxy A +-*------+Proxy B +--------+Server |
+--------+ +--------+ * +--------+ +--------+
^ * ^
. End-to-End * Security Protection .
+......................*.............................+
*
****************************
Figure 1: Example Diameter Deployment Setup.
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.
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.
This entire document focused on the discussion of new functionality for securing Diameter AVPs end-to-end.
This document does not require actions by IANA.
We would like to thank Guenther Horn for his review comments.
| [1] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [2] | Fajardo, V., Arkko, J., Loughney, J. and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012. |
| [1] | Calhoun, P., Farrell, S. and W. Bulley, "Diameter CMS Security Application", Internet-Draft draft-ietf-aaa-diameter-cms-sec-04, March 2002. |