NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Ran Canetti <canetti@watson.ibm.com>
Thomas Hardjono <thardjono@verisign.com>
Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>
Marcus Leech <mleech@nortelnetworks.com>
General Discussion:msec@securemulticast.org
To Subscribe: msec-request@securemulticast.org
In Body: subscribe
Archive: http://www.pairlist.net/mailman/listinfo/msec
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 framework that includes a number of "functional building blocks". Each such building block will be instantiated by one or more protocols that will be interchangable. The functional building blocks and protocols developed at the SMUG Rsearch Group of the IRTF will be used as the starting point for the work of MSEC. Specifically, the following functional building-blocks will be the basis of the standard:
(BB1) Data security transforms functional building block. This building block provide for group and source authentication and group secrecy, assuming that the parties hold the necessary cryptographic keys. This BB will support both IP-layer and transport/application layer security services.
(BB2) Group key management and group security association (GSA) functional building block. This building block makes sure that the group members have the cryptographic keys needed for BB1. This includes secure generation, distribution, and update of the cryptographic keys.
(BB3) Group policy management functional building block. This building block provides means for determination and disemination of group security policy, that governs the behavior of BB1 and BB2. (It is stressed that MSEC will not address general policy management issues, and will concentrate on mechanisms required for BB1 and BB2.)
MSEC will work closely with the Secure Multicast (SMUG) and Reliable Multicast (RMRG), IRTF research groups, and with the Multicast Transport (RMT), IP Security (IPsec) and Policy (Policy Framework and IPSP) WGs of the IETF.
DELIVERABLES
MSEC will generate the at least the following documents:
1 An informational RFC describing the security requirements and problem-space for group and multicast security for one-to-many communications.
This RFC will be based on draft-irtf-smug-taxonomy-01.txt.
2 An informational RFC that specifies the overall framework for the solution. This includes specifying the general functionality of the building blocks and their inter-relations.
This RFC will be based on draft-irtf-smug-framework-01.txt.
3 RFCs detailing the structure and functionality of each building block.
These RFCs will be based on:
draft-irtf-smug-data-transforms-00.txt
draft-irtf-smug-gkmbb-gsadef-01.txt
draft-irtf-smug-mcast-policy-01.txt
4 Standards-track RFCs describing specific protocols that instantiate each one of the functional building blocks. At least one protocol for instantiating each building block will be standardized.
Some of these RFCs will be based on:
draft-irtf-smug-gdoi-00.txt
draft-harney-sparta-gsakmp-sec-02.txt
draft-irtf-smug-tesla-00.txt
Apr 01 |
|
Initial Drafts on requirements and problems space, and framework (items 1 and 2 above) |
Jun 01 |
|
Submit requirements and problems space, and framework drafts for publication as Informational RFC. |
Jul 01 |
|
Initial drafts on the functional building blocks (item 3 above). |
Aug 01 |
|
IETF-51: Review building-block drafts |
Nov 01 |
|
Initial Drafts on protocols for instantiating the functional building blocks (item 4 above). |
Dec 01 |
|
IETF-52: Presentation of protocol drafts. |
Feb 02 |
|
Complete building-block drafts WG Last-Call and submit as Proposed Standard. |
Mar 02 |
|
Second Review of protocol drafts. |
Jul 02 |
|
Third review of protocol drafts. |
Jul 02 |
|
Third review of protocol drafts. |
Dec 02 |
|
Final review of protocol drafts. |
Dec 02 |
|
Complete protocol drafts WG Last-Call and submit as Proposed Standard. |
Dec 02 |
|
Final review of protocol drafts. |
Dec 02 |
|
WG disband or re-charter for other work items. |
Minutes of the August 8, 2001 MSEC meeting
IETF 51
3:30-5:30 pm
Thomas Hardjono and Ran Canetti, chairs
Copies of all of the presentations are on www.securemulticast.org
GKM Architecture presentation by Mark Baugher:
Presented where GKM arch fits into big picture of docs and architecture
Comments:
Hugh Harney:
external policy interface necessary for static policy issues. Policy that insures that the key being passed around is secure should be included within the GKM. This can be dynamic (within a group) and is required to make/keep group secure.
Re-key protocol presented by Lakshminath Dondeti
(No I-D posted yet)
Comments:
Thomas Hardjono:
- rekey protocol needs to deal with policy changes during rekey, e.g. changing from DES to 3DES when key changes.
- Keep Cat 1 SA's up in place of backchannel
Pete Dinsmore
- need backchannel for "I need to be resynched"
- don't use backchannel for group management, i.e., de-registration
- don't include support for subgroup communication/keying; too complicated
Hugh Harney:
- don't confuse KEK's with TEK's. i.e., don't use tree keys for subgroup communication
Ken Calvert:
- what is motivation for subgroup communication? It seems too complicated for now.
???:
- will backchannel have implosion problem?
Ran Canetti
- separate de-registration from key mgmt backchannel (for resynch)
- subgroup is too complicated for now
- Suggest piggybacking key messages on data
- Will the rekey protocol be stateless? What happens if a message is missed?
GSAKMP Lite presentation by Hugh Harney:
(no I-D posted yet)
Purpose of work is to simplify GSAKMP and provide easier implementation, easier analysis, and faster setup
Cut out optional payloads, initial infrastructure search, first unicast SA.
Kept full GSAKMP functionality for distribution of policy, key mgmt,
Defined security suite for initial setup of group
Comments:
Thomas Hardjono:
- is cat 1 over secure channel? Hugh: Intent is to be secure without unicast SA Haven't specified yet which parameters are kept after exchange (state created by exchange)
- Where does member ID come from? Hugh - it's a 32 bit number.
Lakshminath Dondeti:
- will key node number updates be part of key update?
Key Mgmt for Multimedia Sessions ( and SRTP) presentation by Fredrik Linkholm
(drafts published as individual I-D)
This work originates from securing SRTP in AVT WG
Mark Baugher:
- is there a home for this work here?
- It does not seem this is doing authenticated key exchanges (can it be done in less than 3 messages?)
Hugh Harney:
- What is the class of applications? Who owns the data shared on the group? The issue is that "how do group members trust that group is secure enough to share my data?
Thomas Hardjono:
- Does this work belong in MSEC? It is common with our work because it is group security.
Brian Weis:
- Isn't SRTP going forward as a unicast protocol? Therefore, this work might not belong in MSEC.
??
- Mmusic will be discussing the unicast/multicast aspects of SRTP. The group security aspects are covered better in MSEC
Mark Baugher:
- feels GKM arch is modular and should be able to handle this.
Ran Canetti:
- agrees this would be good for MSEC.
Mark Baugher:
- MSEC should define key messages, regardless of how they are transmitted (specified probably in Mmusic)
Straw poll taken by Ran was that this work should be included in MSEC (about 30 said yes, 0 said no)
Group Domain of Interpretation by Brian Weis
Brian first explained that GDOI uses IKE phase 1 unchanged, and does not use IKE phase 2 at all. It replaces IKE phase 2 with GDOI, under its own Domain number, and most likely running on its own port. He then presented updates on GDOI since the last IETF.
Questions/Comments
???
- Does it make sense to just redo the IKE phase 1 exchange to refresh the DH material, instead of having the KE payloads optional in phase 2?
Steve Kent
- Feasible just to use public key certs with narrow scopes of use in place of attribute certs.
- Warning: defering this (Alternative C) may end up requiring an arbitrary number of exchanges, as opposed to the current 2. Protocol will need to be more generic to account for this if the doc follows this alternative.
Rekey protocol
Key Management for Multimedia Sessions (and SRTP)