Internet DRAFT - draft-tschofenig-dime-keying-database
draft-tschofenig-dime-keying-database
DIME H. Tschofenig, Ed.
Internet-Draft Nokia Siemens Networks
Intended status: Standards Track February 18, 2013
Expires: August 22, 2013
A Keying Database for Diameter End-to-End Security
draft-tschofenig-dime-keying-database-00.txt
Abstract
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.
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.
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.
Tschofenig Expires August 22, 2013 [Page 1]
Internet-Draft Diameter Keying Database February 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conceptual Keying Database . . . . . . . . . . . . . . . . . . 5
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Tschofenig Expires August 22, 2013 [Page 2]
Internet-Draft Diameter Keying Database February 2013
1. Introduction
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.
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].
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 [RFC4301] and inspired by the routing protocol security key
table [I-D.ietf-karp-crypto-key-table].
Tschofenig Expires August 22, 2013 [Page 3]
Internet-Draft Diameter Keying Database 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 [RFC2119].
Tschofenig Expires August 22, 2013 [Page 4]
Internet-Draft Diameter Keying Database February 2013
3. Conceptual Keying Database
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.
We describe the keying database in a conceptual way as a table, where
each row represents a single symmetric or asymmetric key.
The columns that the table consists of are listed as follows:
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.
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.
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.
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.
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.
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
[I-D.ietf-karp-crypto-key-table]. The protocol indicates what (if
any) KDFs are valid. For asymmetric algorithm the KDF is left
Tschofenig Expires August 22, 2013 [Page 5]
Internet-Draft Diameter Keying Database February 2013
empty.
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.
KeyType: The KeyType provides information about the type of key
found in the Key field. Two values are possible: "SymmetricKey"
and "AsymmetricKey".
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
[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.
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.
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.
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
Tschofenig Expires August 22, 2013 [Page 6]
Internet-Draft Diameter Keying Database February 2013
outbound traffic then this field is ignored.
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.
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.
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.
Tschofenig Expires August 22, 2013 [Page 7]
Internet-Draft Diameter Keying Database February 2013
4. Examples
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.
+----------------+ +----------------+
| | +----------+ | |
| Diameter | | | | Diameter |
| Client | | Diameter | | Server |
| |---------->| Proxy |--------->| |
| | | | | |
+----------------+ +----------+ +----------------+
client.example.com proxy.example.com server.example.com
Figure 1: Example Diameter Deployment Setup.
The first example illustrates an entry in the key table at a Diameter
client.
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:
The second example illustrates the entries of the key database for an
asymmetric key as stored at the Diameter client.
Tschofenig Expires August 22, 2013 [Page 8]
Internet-Draft Diameter Keying Database February 2013
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:
Tschofenig Expires August 22, 2013 [Page 9]
Internet-Draft Diameter Keying Database February 2013
5. Security Considerations
This document focuses on the description of a keying database for
usage with Diameter to protect AVPs end-to-end.
It has been recognized in [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.
Designers should recognize the warning provided in [RFC4107]:
"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."
Tschofenig Expires August 22, 2013 [Page 10]
Internet-Draft Diameter Keying Database February 2013
6. IANA Considerations
[Editor's Note: An IANA consideration section will be provided in a
future version of this document.]
Tschofenig Expires August 22, 2013 [Page 11]
Internet-Draft Diameter Keying Database February 2013
7. Acknowledgments
I would like to thank the authors of [I-D.ietf-karp-crypto-key-table]
for their work. This document is inspired by their writeup.
Tschofenig Expires August 22, 2013 [Page 12]
Internet-Draft Diameter Keying Database February 2013
8. References
8.1. Normative References
[I-D.farrell-decade-ni]
Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keraenen, A., and P. Hallam-Baker, "Naming Things with
Hashes", draft-farrell-decade-ni-10 (work in progress),
August 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012.
8.2. Informative References
[I-D.ietf-karp-crypto-key-table]
Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys",
draft-ietf-karp-crypto-key-table-05 (work in progress),
February 2013.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
Tschofenig Expires August 22, 2013 [Page 13]
Internet-Draft Diameter Keying Database February 2013
Author's Address
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
Tschofenig Expires August 22, 2013 [Page 14]
