2.7.10 Multicast Security (msec)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-03

Chair(s):

Ran Canetti <canetti@watson.ibm.com>
Lakshminath Dondeti <ldondeti@qualcomm.com>

Security Area Director(s):

Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Russ Housley <housley@vigilsec.com>

Mailing Lists:

General Discussion: msec@securemulticast.org
To Subscribe: msec-request@securemulticast.org
In Body: subscribe
Archive: http://six.pairlist.net/pipermail/msec/

Description of Working Group:

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.

Goals and Milestones:

Done  Working Group Last Call on GDOI Protocol
Done  Working Group Last Call on MIKEY Protocol
Done  WG Last Call on MSEC Architecture draft
Done  WG Last Call on Group Key Management Architecture
Done  WG Last Call on DHHMAC for MIKEY
Dec 2003  WG Last Call on IP Multicast issues with IPsec
Done  WG Last Call on MSEC Security Requirements draft
Done  WG Last Call on GSAKMP
Done  WG Last Call on MSEC Policy Token
Mar 2004  WG Last Call on MESP Framework (Data Security Architecture) draft
Mar 2004  WG Last call on TESLA-Spec draft
Done  WG Last call on TESLA-Intro draft
Jul 2004  WG re-charter for other work items (or disband)

Internet-Drafts:

  • draft-ietf-msec-gsakmp-sec-10.txt
  • draft-ietf-msec-mikey-dhhmac-11.txt
  • draft-ietf-msec-ipsec-signatures-06.txt
  • draft-ietf-msec-srtp-tesla-05.txt
  • draft-ietf-msec-policy-token-sec-04.txt
  • draft-ietf-msec-newtype-keyid-02.txt
  • draft-ietf-msec-bootstrapping-tesla-02.txt
  • draft-ietf-msec-mikey-ecc-00.txt
  • draft-ietf-msec-mikey-rsa-r-01.txt
  • draft-ietf-msec-ipsec-extensions-00.txt
  • draft-ietf-msec-gkdp-00.txt

    Request For Comments:

    RFCStatusTitle
    RFC3547 PS The Group Domain of Interpretation
    RFC3740 I The Multicast Security Architecture
    RFC3830 Standard MIKEY: Multimedia Internet KEYing
    RFC4046 I Multicast Security (MSEC) Group Key Management Architecture
    RFC4082 I Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction

    Current Meeting Report

    MSEC minutes, Steffen Fries, edited by Lakshminath Dondeti
    ldondeti@qualcomm.com
    
    
    **Update on milestones & Recent progress in MSEC (Lakshminath)
            o  Bootstrapping TESLA to IETF last call
            o  Policy token in review
            o  Newtype key id waiting for 3GPP feedback ' until then stalled
            o  SRTP TESLA now in RFC Editors queue  
    
    **Action items from Paris:
            o IPsec extensions work for scoping review from IPSEC list, 
                 >> Revision 1 will be made and send to IPsec list, 
            o Discussion on MIKEY, roadmaps
            o MIKEY RSA-R to be sent to MMUSIC group
            o Milestone have been updated
    
    **Update on Bootstrapping TESLA (Steffen Fries)
    
            o  Comments received from AD review
            o  Mostly editorial changes
            o  Clarified and described relations to other existing RFCs and IDs
            (MIKEY, SRTP, SRTP-TESLA) 
            o  Clarified description of TESLA parameter
            o  Reworked some attacks in the security consideration section
            o  Current document in state: In Last Call 
    
    **  Update on GDKP (Lakshminath)
            o  Next version will be posted in January
            o [After the meeting] we have a new volunteer to work on this:
            srowles@cisco.com (Sheela Rowles) 
    
    **  Discussion on MIKEY modes
            o  MIKEY-ECC  (Lakshminath provided a brief update)
              No progress made, one comment from Steffen, which needs to
              be incorporated 
              Russ asked for IPR statement on MQV
            Russ thought it is already in place. But Brian Minard from Certicom
            noted that the IPR statements have not yet been submitted.
    
            o  MIKEY-RSA-R  (Dragan)
              Current version 1
              Concept of multiple TGKs introduced (section 4) 
              Motivation: media lines for Multicast and Unicast in the same
                      payload, to have single MIKEY line in SDP) 
              Two TGKs used 
              *Outstanding issue: mapping of TGKs to media streams
    
    <>
    <>
    
    
    o  MIKEY-DH based mode  (New proposal)
      SAML assistend Diffie Hellman Mikey (R.Moskowitz)
      Based from discussion in VoiP SA consortium's list
    
    **   Requirements:
            o  Mutual authentication
            o  Both parties involved in key generation
            o  PFS
            o  Support distribution of group keys
              Observations
            o  Diffie Hellman solves some requirements (2+3)
            o  1 can be done with SAML
            o  second roundtrip can be used for item 4,5 und 6
              Scenarios
            o  Peer-to-peer
            o  Simple one to many
            o  Small sized groups
              Trusted UA credentials
    
       Notes:
            o  Parties should have trusted credentials containing UA Identity, DH
            Public key, proof of trust, time range of trusting the credential 
            o  Low latency and computational overhead
            o  MIKEY before talking, but after pickup
            o  Credential validation as hidden latency
            o  If UA receives SAML certificate from its domains SIP server
            o  It trusts the cert implicitly
            o  Removes hidden latency
            o  Common use of DH key in keyed hash over nonce and other data
            o  Consider DH key size
            o  Recommendation to use 4096 bit DH to equal to 128 bit AES
            o  Too expensive
            o  Use ECC DH?
    
    ** What next
            o  Generate interest
            o  Finish first draft
            o  Legal intercept
            o  If both parties are registered to the same SIP domain, SIP server
            can lie and generate 2 SAML certs to place himself in MiTM 
            o  Different domains: SIP server can collude, both generating
            2 SAML certs 
    
    **   Discussion
            o  SIP currently does not handle SAML certs, main load is on the
            server, not on the client  (d/ Brian Weis)
    
       Rich Graveman: Question about long vs. short DH keys
            o  different p and q for short key vs. long key
            o  phones could get new prime periodically
            o  second roundtrip optional, if clocks are totally out of sync, will
              be determined during first roundtrip 
    
    
     Steffen Fries: How does the 4 message version fit with the SIP
    offer/answer model?
    
      RM: It is optional; and remember that this offers an answer to the
    problem of clock sync requirements
    
    David McGrew: Optional round-trip: Does it precede or follow the mandatory
    exchange?
      RM: It follows.
      DM: FYI: Pre-conditions work in the MMUSIC WG has issues with
    an exchange preceding the key establishment exchange.
    
            
      DM:      o  problem with early media 
                Media gets back before the key exchange is finished.
      SF:  This is the same problem with the other DH exchanges in MIKEY
      
      RM: If MIKEY lags behind media, there is no solution.
    
    **   asking for support to produce a draft 
    
    <>
    
    **  Update on the IPsec Extensions work (Brian Weis)
            o  draft-ietf-msec-ipsec-extensions-00.txt
            o  anti replay protection for multi-sender SAs is NOT in scope
            o  single sender can use RFC2401 anti reply counter
            o  multi-sender IPsec SAs are problematic
            o for a small number of senders, it might be ok to just have
              as many IPsec SAs as there are senders.
    
    o  issue 1: goal of this document
            o  option 1 defines a group wide GSA architecture resulting in complete
            interoperability between heterogeneous devices 
            o  IPsec SA
            o  GKM
            o  option 2 defines a group wide IPsec SA architecture, resulting in
            IPsec interoperability between heterogeneous devices 
            o  IPsec SA
    Russ: 2401bis gets through the entire architecture without touching
    IKE.  Why do you think you can't do the same thing.
            o  Guidance: As far as rfc2401bis goes
    
    o  Issue 2: GCKS Deployments
            o  Should the document mandate multiple GCKS device be defined in this
            architecture? 
    
    Russ: That sounds like interesting work, but not for this document.
    
    o  Issue 3: Composite cryptographic groups
            o  Motivation: can not easily upgrade a large scale group
            o  Packet replication (one sends only a packet to one receiver, who
            promotes the packet to the composite group ..) 
            o  Composite transport mode
    
      o  Option 1: Replication happens at the host 
            o  E2e security
      o  Option 2: Replication in network
    
            o  Question? Necessary for this document to support all modes
            o  Comes down to replication, requires an RFC2401bis compliant
            implementation to provide replication 
    
    Lakshminath: Can we not define the simple case and extensions will
    just reuse that building block?
    <>
    <>
    
    o  Issue 4: GKMS/IPsec interface
            o  Question: should all GKMPs use the same namespace as a common
            interface to IPsec? 
    
            o  Would simplify the interface, but what is the interface?
            o  Policy Token
            o  IPsec SA Attributes
            o  API
    
    PF_KEY was mentioned as a potential here.  (Editor's note: PF_KEY has had
    its ups and downs in the IETF.  We want to tread that carefully to
    make sure we don't get into a rathole).
    
    o  Next steps
            o  Resolve scope issues
            o  Issue 01 before IETF65
            o  Discussion on the list
            o  Discussion
    
            o  Multi senders - sender ID in multicast ESP not considered so far ' 
            not backwards compatible 
    
    Some general discussion:
        What are the implications of using CTR mode and combined modes
    like GCM in this document?
        Q: Are we talking about IV space management between sender?
        
       Russ: It would be in scope in so far as deciding where these fit
    in the IPsec databases.
    
    *** We ran out of time to start a discussion on the MIKEY mode
    explosion.  Will start a discussion on the list.
    
    
    

    Slides

    MSEC Status at IETF-64
    Update on Bootstrapping TESLA
    MIKEY RSA-R
    MIKEY SAML assisted D-H mode (new proposal)
    MSEC IPsec extensions