|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## MSECwg
##
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: May 12, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## MSECwg
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## MSECwg
##
##
##
|
|
|
|
|
|
| The charter of the MSEC working group
is reported below.
|
|
|
|
The purpose of the MSEC WG is to standardize protocols for securing
group communication over internets, and in particular over the global
Internet. Initial efforts will focus on scalable solutions for groups
with a single source and a very large number of recipients. Additional
emphasis will be put on groups where the data is transmitted via
IP-layer multicast routing protocols (with or without guaranteed
reliability). The developed standard will assume that each group has a
single trusted entity (the Group Controller) that sets the security
policy and controls the group membership. The standard will strive
to provide at least the following basic security guarantees:
|
|
| - |
Only legitimate group members will have access to current group
communication. This includes groups with highly dynamic membership.
|
| - |
Legitimate group members will be able to authenticate the source
and contents of the group communication. This includes cases where
group members do not trust each other.
|
|
An additional goal of the standard will be to protect against
denial-of-service attacks, whenever possible.
Due to the large number of one-to-many multicast applications and the
sometimes conflicting requirements these applications exhibit, it is
believed that a single protocol will be unable to meet the requirements
of all applications. Therefore, the WG will first specify a general
Reference Framework that includes a number of functional building
blocks. Each such building block will be instantiated by one or more
protocols that will be interchanable. The Reference Framework will not
only describe one-to-many multicast, but also many-to-many multicast.
In addition, as a secondary goal the MSEC WG will also focus on
distributed architectures for group key management and group policy
management, where for scalability purposes multiple trusted entities
(such as Key Distributors) are deployed in a distributed fashion. For
this purpose, the Reference Framework will not only describe
one-to-many multicast, but also many-to-many multicast.
MSEC will generate at least the following documents, which could be
considered as base documents:
|
|
| 1. |
An RFC describing the security requirements of multicast security
and
an RFC describing the MSEC Architecture.
|
| 2. |
An RFC describing the Group Key Management Architecture and an RFC
describing Group Policy Management Architecture in MSEC.
|
| 3. |
Several RFCs describing specifications for protocols that implement
source authentication, group key management and group policy
management.
|
|
As multicast security covers a broad range of issues, and therefore
touches other Working Groups in the IETF, the MSEC WG will work closely
with othersecurity-related Working Groups (e.g. IPsec, IPSP), as well
as other Working Groups which maybe considered a 'consumer' of the
technologies produced in the MSEC WG (e.g. AVT, MMUSIC) or which may
have a multicast focus (e.g. PIM, RMT, IDRM, MAGMA).
With this in mind, the MSEC WG is open to receiving new work items,
whenever it is considered appropriate to be homed in the MSEC WG. Such
drafts will be matured in conjunction with the MSEC base documents.
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## MSECwg
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
RFC3547
07/2003
(48 p.)
[html]
[pdf(2)] |
M. Baugher
B. Weis
T. Hardjono
H. Harney |
|
The Group Domain of Interpretation |
|
This document presents an ISAMKP Domain of Interpretation (DOI) for
group key management to support secure group communications. The
GDOI manages group security associations, which are used by IPSEC and
potentially other data security protocols running at the IP or
application layers. These security associations protect one or more
key-encrypting keys, traffic-encrypting keys, or data shared by group
members.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3740
03/2004
(26 p.)
[html]
[pdf(2)] |
T. Hardjono
B. Weis |
|
The Multicast Group Security Architecture |
|
This document provides an overview and rationale of the multicast
security architecture used to secure data packets of large multicast
groups. The document begins by introducing a Multicast Security
Reference Framework, and proceeds to identify the security services
that may be part of a secure multicast solution.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3830
08/2004
(66 p.)
[html]
[pdf(2)] |
J. Arkko
E. Carrara
F. Lindholm
M. Naslund
K. Norrman |
|
MIKEY: Multimedia Internet KEYing |
This document describes a key management scheme that can be used for
real-time applications (both for peer-to-peer communication and group
communication). In particular, its use to support the Secure Real-
time Transport Protocol is described in detail.
Security protocols for real-time multimedia applications have started
to appear. This has brought forward the need for a key management
solution to support these protocols.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4046
04/2005
(38 p.)
[html]
[pdf(2)] |
M. Baugher
R. Canetti
L. Dondeti
F. Lindholm |
|
Multicast Security (MSEC) Group Key Management Architecture |
|
This document defines the common architecture for Multicast Security
(MSEC) key management protocols to support a variety of application,
transport, and network layer security protocols. It also defines the
group security association (GSA), and describes the key management
protocols that help establish a GSA. The framework and guidelines
described in this document permit a modular and flexible design of
group key management protocols for a variety of different settings
that are specialized to applications needs. MSEC key management
protocols may be used to facilitate secure one-to-many, many-to-many,
or one-to-one communication.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4082
06/2005
(22 p.)
[html]
[pdf(2)] |
A. Perrig
D. Song
R. Canetti
J. D. Tygar
B. Briscoe |
|
Timed Efficient Stream Loss-Tolerant Authentication (TESLA):
Multicast Source Authentication Transform Introduction |
This document introduces Timed Efficient Stream Loss-tolerant
Authentication (TESLA). TESLA allows all receivers to check the
integrity and authenticate the source of each packet in multicast or
broadcast data streams. TESLA requires no trust between receivers,
uses low-cost operations per packet at both sender and receiver, can
tolerate any level of loss without retransmissions, and requires no
per-receiver state at the sender. TESLA can protect receivers
against denial of service attacks in certain circumstances. Each
receiver must be loosely time-synchronized with the source in order
to verify messages, but otherwise receivers do not have to send any
messages. TESLA alone cannot support non-repudiation of the data
source to third parties.
This informational document is intended to assist in writing
standardizable and secure specifications for protocols based on TESLA
in different contexts.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4359
01/2006
(12 p.)
[html]
[pdf(2)] |
B. Weis |
|
The Use of RSA/SHA-1 Signatures within
Encapsulating Security Payload (ESP) and Authentication Header (AH) |
|
This memo describes the use of the RSA digital signature algorithm as
an authentication algorithm within the revised IP Encapsulating
Security Payload (ESP) as described in RFC 4303 and the revised IP
Authentication Header (AH) as described in RFC 4302. The use of a
digital signature algorithm, such as RSA, provides data origin
authentication in applications when a secret key method (e.g., HMAC)
does not provide this property. One example is the use of ESP and AH
to authenticate the sender of an IP multicast packet.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4442
03/2006
(18 p.)
[html]
[pdf(2)] |
S. Fries
H. Tschofenig |
|
Bootstrapping
Timed Efficient Stream Loss-Tolerant Authentication (TESLA) |
TESLA, the Timed Efficient Stream Loss-tolerant Authentication
protocol, provides source authentication in multicast scenarios.
TESLA is an efficient protocol with low communication and computation
overhead that scales to large numbers of receivers and also tolerates
packet loss. TESLA is based on loose time synchronization between
the sender and the receivers. Source authentication is realized in
TESLA by using Message Authentication Code (MAC) chaining. The use
of TESLA within the Secure Real-time Transport Protocol (SRTP) has
been published, targeting multicast authentication in scenarios where
SRTP is applied to protect the multimedia data. This solution
assumes that TESLA parameters are made available by out-of-band
mechanisms.
This document specifies payloads for the Multimedia Internet Keying
(MIKEY) protocol for bootstrapping TESLA for source authentication of
secure group communications using SRTP. TESLA may be bootstrapped
using one of the MIKEY key management approaches, e.g., by using a
digitally signed MIKEY message sent via unicast, multicast, or
broadcast.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4534
06/2006
(33 p.)
[html]
[pdf(2)] |
A. Colegrove
H. Harney |
|
Group Security Policy Token v1 |
|
The Group Security Policy Token is a structure used to specify the
security policy and configurable parameters for a cryptographic
group, such as a secure multicast group. Because the security of a
group is composed of the totality of multiple security services,
mechanisms, and attributes throughout the communications
infrastructure, an authenticatable representation of the features
that must be supported throughout the system is needed to ensure
consistent security. This document specifies the structure of such a
token.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4535
06/2006
(106 p.)
[html]
[pdf(2)] |
H. Harney
U. Meth
A. Colegrove
G. Gross |
|
GSAKMP: Group Secure Association Key Management Protocol |
|
This document specifies the Group Secure Association Key Management
Protocol (GSAKMP). The GSAKMP provides a security framework for
creating and managing cryptographic groups on a network. It provides
mechanisms to disseminate group policy and authenticate users, rules
to perform access control decisions during group establishment and
recovery, capabilities to recover from the compromise of group
members, delegation of group security functions, and capabilities to
destroy the group. It also generates group keys.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4650
09/2006
(27 p.)
[html]
[pdf(2)] |
M. Euchner |
|
HMAC-Authenticated Diffie-Hellman
for Multimedia Internet KEYing (MIKEY) |
|
This document describes a lightweight point-to-point key management
protocol variant for the multimedia Internet keying (MIKEY) protocol
MIKEY, as defined in RFC 3830. In particular, this variant deploys
the classic Diffie-Hellman key agreement protocol for key
establishment featuring perfect forward secrecy in conjunction with a
keyed hash message authentication code for achieving mutual
authentication and message integrity of the key management messages
exchanged. This protocol addresses the security and performance
constraints of multimedia key management in MIKEY.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4738
11/2006
(19 p.)
[html]
[pdf(2)] |
D. Ignjatic
L. Dondeti
F. Audet
P. Lin |
|
MIKEY-RSA-R: An Additional Mode of Key Distribution
in Multimedia Internet KEYing (MIKEY) |
|
The Multimedia Internet Keying (MIKEY) specification describes
several modes of key distribution solution that address multimedia
scenarios (e.g., SIP calls and Real Time Streaming Protocol (RTSP)
sessions) using pre-shared keys, public keys, and optionally a
Diffie-Hellman key exchange. In the public-key mode, the Initiator
encrypts a random key with the Responder's public key and sends it to
the Responder. In many communication scenarios, the Initiator may
not know the Responder's public key, or in some cases the Responder's
ID (e.g., call forwarding) in advance. We propose a new MIKEY mode
that works well in such scenarios. This mode also enhances the group
key management support in MIKEY; it supports member-initiated group
key download (in contrast to group manager pushing the group keys to
all members). This document updates RFC 3830 with the RSA-R mode.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## MSECwg
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## MSECwg
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
msec-mikey-
applicability-09
IESG Evaluation::
AD Followup
Mar 31, 2008
(39 p.)
[pdf(2)]
[html]
|
S. Fries
D. Ignjatic |
|
On the applicability of various MIKEY modes and extensions |
Multimedia Internet Keying - MIKEY - is a key management protocol
that can be used for real-time applications. In particular, it has
been defined focusing on the support of the Secure Real-time
Transport Protocol. MIKEY itself is standardized within RFC 3830 and
defines four key distribution methods. Moreover, it is defined to
allow extensions of the protocol. As MIKEY becomes more and more
accepted, extensions to the base protocol arose, especially in terms
of additional key distribution methods, but also in terms of payload
enhancements.
This document provides an overview about the MIKEY base document in
general as well as the existing extensions for MIKEY, which have been
defined or are in the process of definition. It is intended as
additional source of information for developers or architects to
provide more insight in use case scenarios and motivations as well as
advantages and disadvantages for the different key distribution
schemes. The use cases discussed in this document are strongly
related to dedicated SIP call scenarios providing challenges for key
management in general among them media before SDP answer, forking,
and shared key conferencing.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## MSECwg
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
msec-gdoi-srtp-01
ID Exists
Dec 3, 2007
(24 p.)
[pdf(2)]
[html]
|
M. Baugher
A. Rueegsegger
S. Rowles |
|
GDOI Key Establishment for the SRTP Data Security Protocol |
|
The Secure Real-time Transport Protocol (SRTP) protects unicast and
multicast RTP packets. Multicast receivers of SRTP session data
therefore share an SRTP master key for message authentication and
decryption. This document describes how to establish a shared,
"group key" for an SRTP session using RFC 3547, the Group Domain of
Interpretation (GDOI) and RFC 2408, the Internet Security Association
and Key Management Protocol. This document extends GDOI for SRTP
group key establishment.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
msec-tesla-for-
alc-norm-04
ID Exists
Feb 18, 2008
(59 p.)
[pdf(2)]
[html]
|
V. Roca
A. Francillon
S. Faurite |
|
Use of TESLA in the ALC and NORM Protocols |
|
This document details the TESLA packet source authentication and
packet integrity verification protocol and its integration within the
ALC and NORM content delivery protocols. This document only
considers the authentication/integrity verification of the packets
generated by the session's sender. Adding authentication/integrity
verification to the packets sent by receivers, if any, is out of the
scope of this document.
|
|
|
| |
| Up List |
Intended Status: | Experimental |
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
##
##
##
##
##
## MSECwg
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
