Internet Engineering Task Force                          C. Castelluccia
INTERNET DRAFT                                             G. Montenegro
                                                           February 2001
                Securing Group Management in IPv6 with
                 Cryptographically Generated Addresses

Status of This Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC 2026.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups.  Note that other groups may also
   distribute working documents as Internet-Drafts.

   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.''

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   Currently, group membership management in IP Multicast and
   Anycast can be abused in order to launch denial-of-service (DoS)
   attacks.  The root of the problem is that routers cannot
   determine if a given host is authorized to join a group
   (sometimes referred to as the "Proof-of-Membership Problem"
   [ECUMN00]). We propose a solution for IPv6 based on Group
   Cryptographically Generated Addresses (G-CGA).

   These addresses have characteristics of statistical uniqueness
   and cryptographic verifiability that lend themselves to severely
   limiting certain classes of DoS attacks. Our scheme is fully
   distributed and does not require any trusted third party or
   pre-established security association between the routers and the
   hosts.  This is not only a huge gain in terms of scalability,
   reliability and overhead, but also in terms of privacy.

Expires January 20, 2001                                        [Page 1]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

Table of Contents

1.0 Introduction ..................................................    3
2.0 Multicast and Anycast Groups ..................................    3
   2.1 IP Multicast ...............................................    3
   2.2 IP Anycast .................................................    3
   2.3 Group Membership Management via MLD ........................    3
      2.3.1 MLD for Multicast Listeners ...........................    3
      2.3.2 MLD for Multicast Routers .............................    3
3.0 Motivations ...................................................    6
   3.1 MLD-Specific Attacks .......................................    6
   3.2 Problem Statement ..........................................    7
4.0 Related Work ..................................................    8
5.0 Proposal Overview .............................................   10
   5.1 Review of CGA IPv6 address .................................   10
   5.2 Group CGA Addresses (G-CGA) ................................   12
      5.2.1 Multicast CGA Addresses (M-CGA) .......................   12
      5.2.2 Anycast CGA Addresses (A-CGA) .........................   13
   5.3 Protocol Overview ..........................................   14
      5.3.1 Basic Scheme ..........................................   14
      5.3.2 Certificate-based scheme ..............................   15
6.0 Security Analysis .............................................   17
   6.1 Hash ID Size Considerations ................................   17
   6.2 Denial-of-Service Attacks ..................................   18
   6.3 Replay Attacks .............................................   19
   6.4 Unauthorized Group CGA Address .............................   19
7.0 Privacy Considerations ........................................   20
   7.1 Group Structure Privacy ....................................   20
   7.2 Traffic Privacy ............................................   21
8.0 Conclusion ....................................................   23
Acknowledgements ..................................................   24
A. SPKI MLD Certificate ...........................................   24
   A.1 SPKI Review ................................................   24
   A.2 MLD SPKI certificate .......................................   25
   A.3 Chain of Certificates ......................................   27
References ........................................................   29
Authors' addresses ................................................   31

Expires January 20, 2001                                        [Page 2]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

1.0 Introduction

   Group membership management in IP Multicast and Anycast suffers
   from potential Denial of Service (DoS) attacks.  With Multicast,
   a malicious host that joins a group can overflow the network
   by adding branches to the group delivery tree.  In contrast, a
   malicious host that joins an Anycast group will not be able to
   flood a network but can redirect the traffic and prevent other
   legitimate hosts from seeing it. The source of the problem
   is that currently routers cannot verify whether a particular
   host is authorized to join a particular group.  The problem is
   sometimes referred as the Proof-of-Membership Problem [ECUMN00].

   We propose a solution to this problem for IPv6, based on Group
   Cryptographically Generated Addresses (G-CGA), which are an
   extension of CGA (Cryptographically Generated Addresses) for
   Group addresses (Multicast and Anycast groups).  In particular,
   we define two types of G-CGA addresses:  M-CGA for multicast
   and A-CGA for anycast.  We use these addresses to severely
   limit certain classes of DoS attacks.  Our proposal is fully
   distributed. It does not require any trusted third party or
   pre-established security association between the routers and the
   hosts.  This is not only a huge gain in terms of scalability,
   reliability and overhead, but also in terms of privacy.

   This note is structured as follows: Section 2 is an overview
   of Multicast and Anycast in IPv6, as well as of MLD, the
   protocol used for group management.  Section 3 deals with our
   motivations:  it describes the security liabilities in MLD,
   and includes our problem statement. Section 4 talks about
   related work. Section 5 details our proposal by reviewing
   the concept of CGA addresses, and explaining both a basic
   scheme and a certificate-based scheme to handle multicast and
   anycast addresses.  Section 6 presents a security analysis of
   our proposal. Section 7 discusses how this proposal benefits
   privacy considerations.  Section 8 concludes and the appendix
   explains the certificate format we propose for use with MLD
   in our certificate-based scheme.

2.0 Multicast and Anycast Groups

   The Internet Protocol (IP) defines two types of groups:
   Multicast and Anycast groups.

Expires January 20, 2001                                        [Page 3]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

2.1 IP Multicast

   Internet Protocol (IP) Multicast  [RFC1112] defines network
   support that allows IP traffic to be sent from one or multiple
   sources and delivered to multiple destinations without sending
   individual packets to each destination.  A single packet is sent
   by the source to a Multicast group, which is identified by a
   single IP address. The network is then responsible for
   duplicating the packet and delivering it to each member of the
   group.  IP Multicast distinguishes between multicast
   routers and multicast address listeners. Nodes
   register dynamically with a group by sending either IGMP
   (Internet Group Membership Protocol) messages [RFC2236,
   IGMPv3] (if using IPv4) or MLDv2 (Multicast Listener Discovery)
   [RFC2710, MLDv2] messages (if using IPv6).

   Since our solution is specific to IPv6, in the subsequent
   discussion we will assume this process is carried out via
   MLDv2. Unless otherwise noted, in this note MLD refers
   to MLDv2.  Nevertheless, IGMPv3 and MLDv2 are essentially
   identical except for the size of the addresses carried and
   the fact that the latter uses ICMPv6 message types instead
   of IGMP. The differences are largely immaterial.  Given the
   dearth of equivalent material for MLDv2, this document refers
   to previous work on securing IGMPv3.  Routers use MLD messages
   to discover which groups on their directly attached links
   have active multicast listeners. Conversely, nodes use MLD to
   express interest in certain multicast groups and thus become
   multicast listeners.  Notice that multicast routers may also
   be multicast address listeners in which case the corresponding
   protocol behavior as multicast address listeners applies as
   well.  Routers coordinate multicast routing for the different
   groups by using one or more protocols such as DVMRP [DVMRP],
   PIM [RFC2362] or SSM [SSM].

2.2 IP Anycast

   An IPv6 Anycast address is an address that is assigned to more
   than one interface. Thus an IPv6 Anycast address defines a group
   but as opposed to multicast group a packet sent to an Anycast
   address is not routed to all members of the group but only
   to the source's ``nearest'' one [IPV6ADDR].  All interfaces
   belonging to an Anycast address usually resides within a
   topological region defined by an address prefix. Within this
   region, each member must be advertised as a separate ``host
   route'' entry in the routing system. A router that is member
   of an Anycast group will advertise its membership using the

Expires January 20, 2001                                        [Page 4]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

   routing protocol (RIP, OSPF, BGP, etc).  A host that wants
   to join an Anycast group will have to use a group membership
   protocol, such as MLD  [Haber], to register with the local
   router(s) that will then propagate this registration to the
   region using the routing protocol.

2.3 Group Membership Management via MLD

   This section gives some details of MLD, in particular, version
   2 [MLDv2]. This description is just enough to understand
   our contribution. The MLD protocol is asymmetric, that is,
   it specifies different behavior for multicast routers and
   for multicast address listeners.  Furthermore, MLD does not
   apply to the link-local all-nodes multicast group (FF02::1)
   as all multicast-capable nodes are members automatically.

2.3.1 MLD for Multicast Listeners

   Multicast (or Anycast) address listeners use MLD to report
   interest in Multicast groups on each of their interfaces. These
   reports may be triggered by (1) applications expressing
   interest in certain groups, or (2) by Query messages sent by
   the Multicast routers. Whereas in the former case, listeners
   send out the reports immediately, in the latter case reports
   are delayed according to certain timers to avoid an implosion
   of a large number of reports.  Multicast routers send any of
   three types of Queries on their attached links:

   1. General: To learn which Multicast groups have listeners.

   2. Multicast Address Specific: To learn if specific Multicast
      addresses have listeners.

   3. Multicast Address and Source Specific: To learn if any of
      several possible sources have listeners for the given
      Multicast addresses.

   A Multicast listener sends Listener Reports to inform
   neighboring routers about which Multicast addresses it is
   interested in, or if there was any change in that list. These
   reports include Multicast Address Records of different types:

   1. Current State: Sent in response to a Query to report
      listening state.

   2. Filter Mode Change: To notify of changes in the filtering

Expires January 20, 2001                                        [Page 5]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

      (INCLUDE or EXCLUDE) of existing Multicast addresses.

   3. Source List Change: To notify of changes in the list of
      addresses being accepted (INCLUDE) or filtered out

   Reports that include either items 2 or 3 above are typically
   referred to as State Change Report messages.

2.3.2 MLD for Multicast Routers

   At any given time only one Multicast router in a given link is
   the Querier. This is the router with the lowest IPv6 address.
   In fact, a router issuing a Query inhibits all other routers
   with higher IPv6 addresses on the same link from sending a Query
   of their own. All higher addressed routers remain in this
   Non-Querier state for a time known as the Other Querier Present
   Timeout.  Once this timer expires they start issuing Queries

3.0 Motivations

3.1 MLD-Specific Attacks

   As described in [RFC2710, MLDv2] and [ECUMN00],
   MLD is prone to the following attacks.

   Query messages:

      A forged Query message from a machine with a lower IP address
      than the current Querier will cause Querier duties to be
      assigned to the forger. If the forger then ignores Listener
      Report Messages, traffic might flow to groups with no

      A forged Query message sent to a group with members will
      cause the hosts which are members of the group to report
      their memberships.  This causes a small amount of extra
      traffic on the LAN, but causes no protocol problems.

   Report messages:

      A forged Report message to join a group may cause routers to
      assume there are members of a group on a link where, in fact,

Expires January 20, 2001                                        [Page 6]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

      none exist.  The fake Report messages are only harmful if
      there are no other hosts in the LAN interested in the
      Multicast group. The effects of such fake reports are:

      - The local router will create state for the group reported
        in the fake report message. This might be the source of a
        DoS attack: an attacker could send numerous report messages
        for different groups just for the sake of creating state
        at the local queriers.

      - If the group address is fake (i.e. there is no source),
        a fake report may generate signaling traffic in the network.

      - If the group address is valid (i.e. there is at least one
        active source), the local router will send routing messages
        into the network infrastructure. This will have different
        effects according to whether the group is a Multicast
        or an Anycast group. If the group is a Multicast one,
        the routing messages will create states in the Multicast
        router infrastructure, and add branches to the Multicast
        tree resulting in additional traffic. A malicious host
        could use this attack to overflow a network. If the group
        is an Anycast group, the routing message will also create
        additional states in the network infrastructure, that will
        possibly redirect all the Anycast traffic to the malicious
        host, leading to a Denial-of Service attack (DoS).

      In addition to the above, a forged State Change Report
      message to leave a group will cause the Querier to send out
      Group-Specific Queries for the group in question.  This
      causes extra processing on each router and on each member of
      the group, but cannot cause loss of desired traffic.
      [RFC2710, MLDv2] present some defences against such
      externally forged messages. Local forged State Change Report
      messages are more difficult to prevent.

   Routers that receive MLD messages must verify that the source
   address is a link-local address. This requirement defends
   routers from forged MLD messages originated off-link. The
   attacks described previously are therefore only possible by
   local hosts.

3.2 Problem Statement

   The goals of our work is to propose a solution to the security
   problems related to the Report messages presented previously.
   These problems are exacerbated in mobile environments, as in

Expires January 20, 2001                                        [Page 7]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

   such constantly varying environments, routers do not necessarily
   know the Multicast listeners.  It is therefore difficult to
   authenticate them.  This problem is referred in  [ECUMN00] as
   the Proof-of-Membership problem, i.e.: a router will process a
   Report message from a host for a specific group, only if this
   host can prove that it is a legitimate member of the group. The
   proposed solution must satisfy the following objectives:

   - The solution should be ``light'', i.e. should not be too
     expensive in terms of computation, memory or bandwidth.

   - The solution should be scalable, i.e. able to support a very
     large number of members per group and a large numbers
     of groups.

   - The solution should support mobile hosts efficiently. It
     should therefore provide fast group registration and should
     not assume any pre-established contexts in the routers.

   - Avoid reliance on a global infrastructure such as a public Key
     Infrastructure (PKI) as much as possible.

   - Avoid reliance on a Trusted Third Party (TTP) as much as

   As far as the two security issues with forged Query messages
   are concerned, we believe that the problem related to Querier
   selection is solvable. For example, all routers of a link
   could share a secret key. It would then be enough for routers
   to verify the authenticity of the Query messages.  The problem
   related to fake routers causing extraneous traffic by sending
   fake Query messages is much harder to solve.  This problem,
   known as the fake bank teller problem, is not specific to
   group communication. This issue of validating routers or,
   in general, nodes that offer services remains an unsolved
   authorization problem in the Internet at large.

4.0 Related Work

   The IETF MSec working group [MSecWG] is developing protocols
   for securing groups over the Internet. They propose to solve the
   Proof-of-Membership problem described previously by encrypting
   the Multicast flows and by revealing the encrypting keys only
   to the authorized members. As a result only the authorized
   members of a group will be able to decrypt and use the
   Multicast traffic.  This solution has the following drawbacks:

Expires January 20, 2001                                        [Page 8]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

   - An unauthorized host is still able to join a Multicast group
     and receive packets from this group. He will not be able
     to decrypt the packets but will be able to generate extra
     traffic on the network. A malicious host could use this
     protocol's feature to launch a DoS attack.

   - This solution requires that the Multicast flows be encrypted.
     We believe that this is a valid requirement to (1) protect the
     Multicast content, but is not as applicable if the objective
     is to (2) protect the routing infrastructure. Whereas the
     MSec efforts are aimed primarily at (1), our work places
     emphasis on (2).

   MLDv2 [MLDv2] suggests that IPsec in Authentication Header mode
   [RFC2402] may be used to protect against remote attacks by
   ensuring that MLDv2 messages come from a system on the LAN (or,
   more specifically, a system with the proper key).  When using
   IPsec, the messages sent to the all-systems Multicast group and
   the all-router Multicast group should be authenticated using AH.
   When keying, there are two possibilities:

   1. Use a symmetric signature algorithm with a single key that is
      shared by the routers and the hosts of the LAN (or a key
      for each group).  This allows validation that a packet was
      sent by a system with the key.  This has the limitation
      that any host with the key can forge a message even if its
      moves out of the current LAN;

   2. When appropriate key management standards have been
      developed, use an asymmetric signature algorithm.  All hosts
      need to know the public key of all routers, and all routers
      need to know the public key of all hosts in the LAN.
      This requires a large amount of key management but has the
      advantage that senders can be authenticated individually
      so, for instance, a host cannot forge a message that only
      routers should be allowed to send.

   These proposals solve the remote attacks problem but do not
   consider the proof-of-membership. These are two different
   problems.  In fact with the previous solutions a router is
   able to authenticate a host or a set of hosts but it is unable
   to verify whether this host or set of hosts are authorized to
   receive packets from the Multicast group they subscribe to.

   [ECUMN00] proposes a solution to the IGMP proof-of-membership
   problem that uses a Key server. The proof consists of a
   symmetric-key, IGMP-key that is used by the receiver and the
   Multicast router to protect the IGMP message.  The IGMP-key

Expires January 20, 2001                                        [Page 9]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

   is enclosed within an access-token that is signed by the
   issuing-authority and stored in the Key server. Key server
   then sends the token to the Multicast routers and authorized
   hosts. When a router receives an IGMP message from a host it
   verifies if it has a valid token (and therefore a secret key)
   for this host before processing it.  This solution seems to
   work for Multicast group within a domain only.  It is not
   clear how a group that has members in different domains could
   use this proposal. Similarly, this proposal does not support
   mobile hosts that visit a foreign domain (since they do not have
   tokens in this domain).  Furthermore, the scalability property
   of this solution is questionable.  A domain key server must
   have tokens for each potential member of each Multicast group
   of the domain.  Additionally each router must have tokens for
   each potential member of each Multicast group of its links.

   There is not much work that concentrates on Anycast security.
   Nevertheless, [AnycastSec] identifies several issues although
   it does not propose any solutions.  Today the group membership
   verification problem in IP Anycast is basically handled by
   1) restricting which boxes are trusted to participate in
   the routing protocol and 2) the ability to filter routes at
   boundaries.  In fact, as mentioned in [Haber], it is expected
   that routers will employ some filtering mechanism when receiving
   a Report message containing an Anycast address.  For example,
   one policy might be to deny all Anycast joins except those that
   match a configured list of (source address, Anycast address)
   pairs.  This list-based filtering is definitely not scalable
   and not adapted to dynamic and mobile environments. It requires
   updating the access lists each time a new host moves or leaves
   a network.

5.0 Proposal Overview

5.1 Review of CGA IPv6 address

   [SUCV, CAM] present the concept Cryptographically Generated
   IPv6 addresses.  CGA addresses were proposed to solve the IPv6
   address ownership problem [ADDROWN], and are generally useful to
   secure redirect operations in numerous protocols. For example,
   in Mobile IPv6 [MIPv6], a node starts using its home address,
   and, each time it moves to a different link, it issues a
   Binding Update that specifies its current address.  The issue
   is in handling these Binding Updates securely. Why should the
   correspondent node believe the mobile node when it claims that

Expires January 20, 2001                                       [Page 10]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

   it does, in fact, own the home address contained in the binding
   update?  The risk is that this mobile node could be issuing a
   redirect for another node's home address in order to redirect
   its packets.  Ignoring this address ownership problem can lead
   to denial-of-service (DoS) and unauthorized redirect attacks.

   [SUCV,CAM] associate to each host a public-private key pair
   and derive CGA addresses from it. A CGA IPv6 is a valid IPv6
   address.  The top 64 bits are the host's routing prefix as in
   [RFC3041].  The bottom 64 bits, the Cryptographically Generated
   Host Identifier (CGHID) [SUCV], are derived from the host's
   public key as follows:

      CGHID = hmac64(sha1(imprint), sha1(PK))

   Where imprint is a 64-bit field and PK is the public key
   associated with the host.

   Note that according to  [IPV6ADDR], bit 6 of the CGHID (the
   universal/local) has to be set to zero to indicate that the
   CGHID is not guaranteed to be globally unique.

   The generated CGHID must be compared against a list of
   well-known Anycast addresses [RFC2526] and the value 0. If there
   is a conflict, the host can retry using a different counter,
   or, alternatively, start from the beginning by generating a
   new public-private key pair.

   Usually, IPv6 refers to the bottom 64 bits of an address as the
   ``interface identifier''. In contrast, the CGHID is a ``host
   identifier''.  If the host has more than one address (because it
   is multihomed or has several interfaces), it could use the same
   CGHID for its addresses or generate different addresses by using
   different counter values. In any case, the same public-private
   key pair is used. In general, the CGHID identifies a host,
   an IP stack and not just any particular interface.

   When a host wants to prove to its correspondent node
   that it owns its CGA address, it reveals its public key,
   the counter and signs its message(s) with its private key.
   The correspondent node then verifies that (1) the interface
   identifier was derived from the public key and the counter and,
   (2) that the signature is correct, and therefore that the host
   knows the private key component.  As a result, this address
   belongs to the host because no other hosts could have used
   a public-private key pair that hashes to the same CGHID.
   In fact, as detailed in Section 6.1, CGA address collisions
   are very unlikely and CGA addresses are therefore statistically

Expires January 20, 2001                                       [Page 11]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

   unique. For further details on CGA, please refer to [SUCV,CAM].

5.2 Group CGA Addresses (G-CGA)

   In this note, we propose to extend the CGA concept to group
   addresses in order to solve the proof-of-membership problem
   in group management. We defined two new types of addresses,
   namely the Anycast CGA Address (A-CGA) and the Multicast CGA
   Address (M-CGA).

5.2.1 Multicast CGA Addresses (M-CGA)

   An IPv6 Multicast address is an identifier for a group of
   interfaces (typically on different nodes).  An interface may
   belong to any number of Multicast groups.  Multicast addresses
   have the following format  [IPV6ADDR]:

        |   8    |  4 |  4 |      112 bits     |
        +------ -+----+----+-------------------+
        |11111111|flgs|scop|     group ID      |


   - binary 11111111 at the start of the address identifies the
     address as being a Multicast address.

   - flgs is a set of 4 flags. The high-order 3 flags are reserved,
     and must be initialized to 0. The last bit, T, is set
     to to indicate a permanently-assigned (``well-known'')
     Multicast address, assigned by the Internet Assigned Number
     Authority (IANA). T = 1 indicates a non-permanently-assigned
     (``transient'') Multicast address.

   - scop is a 4-bit Multicast scope value used to limit the
     scope of the Multicast group.

   - group ID identifies the Multicast group, either permanent or
     transient, within the given scope.

   We propose to associate to each group a public-private group
   key pair.  The Multicast-CGA (M-CGA) address of this group is
   then an IPv6 Multicast address whose group ID is an 112-bits
   long CGI  (Cryptographically Generated Identifier) i.e.

Expires January 20, 2001                                       [Page 12]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

      GroupID = hash-112(PK)

   Recent work [UniMcast] introduces Multicast addresses derived
   from unicast prefixes.  The format of a unicast-prefix based
   Multicast address is defined as follows:

   |   8    |  4 |  4 |   8   |    8   |     64      |    32    |
   |11111111|flgs|scop|reser. |  plen  | net. prefix | group ID |

   Where network prefix identifies the network prefix of the
   unicast subnet owning the Multicast address. Such addresses
   solve the Multicast address collision problem and simplifies
   dynamic Multicast address allocation by obviating the need
   for the Multicast Address Allocation Protocol [AAP] and the
   Multicast Address-Set Claim (MASC) protocol [MASC]. M-CGA
   addresses also achieve this simplification and solve the
   Multicast address collision problem by virtue of their
   statistical uniqueness.  In fact, as shown in Section 6.1,
   M-CGA provides very low probability of address collision and
   it is therefore almost impossible that two groups will generate
   the same CGA address.

   Note that unicast-prefix based multicast address proposal
   also tries to avoid collisions for L2 addresses when the L2
   Multicast address is formed from the low-order 32 bit of the
   IPv6 Multicast address. A M-CGA, being a hash of a public key,
   has good randomness properties in any sets of bits in the
   hash. Thus it solves this problem as well.

   Nevertheless, we must distinguish between M-CGA addresses
   and the others, so we define a new bit in the flag field,
   the S bit. If the S bit is set, then the address is a M-CGA
   address. Note that [UniMcast] defines the P bit in the flgs
   field to distinguish unicast-prefix based multicast addresses
   from those defined in [IPV6ADDR].

5.2.2 Anycast CGA Addresses (A-CGA)

   Similarly to the Multicast case, we define IPv6 A-CGA (Anycast
   Cryptographically Generated) addresses.  Anycast addresses
   are allocated from the unicast address space.  Thus, Anycast
   addresses are syntactically indistinguishable from unicast
   addresses [IPV6ADDR]. An Anycast CGA address is then generated

Expires January 20, 2001                                       [Page 13]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

   as described in Section 5.1.

5.3 Protocol Overview

   Our proposal relies on Group CGA address to solve the
   proof-of-membership problem. We actually propose two schemes:
   a basic scheme and certificate-based scheme. This section
   describes these two schemes and their respective benefits.

5.3.1 Basic Scheme

   The main steps of this scheme are:

   1. The group controller generates the group's Public-private
      key pair and derives from it the G-CGA as described in
      Section 5.2

   2. The private key, the public key and the G-CGA
      are distributed to the (authorized) group members. Note that
      private key requires confidentiality because it only has
      to be known to the authorized group members.  The public
      key and the G-CGA can be sent in clear but require integrity.

   3. A host that wants to join or leave the group must
      include the group public key when it joins or leaves the
      group, and signs the resulting messages with the group
      private key.

   4. A router that receives a Report message for a
      Group CGA address  must verify the host's proof-of-membership
      to the group by verifying that: (1) G-CGA was generated from
      the public key and (2) the signature is valid. Only a host
      that was authorized to join the group would know the private
      key associated to the group and therefore would be able to
      sign the messages. If the proof-of-membership is correct,
      then the router processes the report message normally,
      otherwise it rejects it.

   This proposal does not rely on a global infrastructure such as
   a PKI or TTP. The secret used to prove the group membership
   is directly sent to the host members. This information
   is sent once for the whole duration of the group session.
   The routers do not have to contact a Trusted Third Party
   (TTP) as in [ECUMN00] to verify the proof-of-membership of
   a host to a group each time it receives an Report message
   from a new host.  All necessary information is included in

Expires January 20, 2001                                       [Page 14]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

   the Report messages and can be processed immediately. As a
   result, joining a group is faster and less bandwidth consuming
   (no extra messages are sent). Furthermore the routers do not
   have to be statistically pre-configured with symmetric keys
   for each of potential hosts that could send Report messages.
   These two properties make our solution very suitable to mobile
   environments where fast handoff is an issue [Seamoby].

   However this basic scheme has the following

   1. It does not provide Membership expiration. This
      scheme makes the assumption that once a member is accepted in
      a group it will remain so for the duration of the group. This
      assumption might not hold for all applications.

   2. It requires a secure channel between the group
      controller and the group members for the private key

   3. It suffers from the private key disclosure problem.
      The basic scheme makes the assumption that the members
      of a group are trusted hosts and that they won't disclose
      (intentionally or not) the group private key to anybody.
      This assumption is clearly not valid for open groups.

   As a result of the following limitations, the basic scheme is
   mainly suited to closed groups (for example within a company)
   whose members are trustworthy.

   For the open groups, we propose another scheme, the
   certificate-based scheme, that is also end-to-end but solves
   all the problems described previously. This scheme supports
   permanent and transient group, support membership expiration and
   does not suffer from the private key disclosure problem. This
   scheme does not require that the members share a secure
   channel with the group controller. However it requires that
   each member have a (unicast) CGA address, defined as described
   in Section 5.1.

5.3.2 Certificate-based scheme

   This scheme uses authorization certificates (for example SPKI
   [RFC2693] or Keynote [RFC2704] certificates). It assumes that
   (1) the group address is a G-CGA address (as in the basic
   scheme) and that additionally (2) each member of the group

Expires January 20, 2001                                       [Page 15]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

   has a (unicast) CGA address (this was not required in the
   basic scheme).

   The main steps of this scheme are:

   1. The group controller generates the group's Public-private
      key pair and derives from it the Group CGA as described in
      Section 5.2.

   2. The group controller generates for each authorized member
      a certificate (see the Appendix for details about the SPKI
      certificate we use) that states that the host, defined by
      its CGA address, is authorized to join the group defined by
      the G-CGA address. This cerficate is signed with the private
      key whose public key was used to generate the G-CGA address.
      It contains the group public key that was used to generate
      the G-CGA address, a validity period, the group controller
      address and the member CGA address.

   3. A host that wants to join or leave the group must include
      the certificate, its public key (the one used to generate
      its CGA address), and signs the resulting messages with
      the private key whose public key was used to generate its
      unicast CGA address.

   4. A router that receives a Report message for a
      Group CGA address must verify the host's proof-of-membership
      to the group by verifying that: (1) the certificate is valid,
      i.e. that its signature is correct, that the validity period
      is still valid and that the group address was generated
      from the group public key.  (2) the MLD message is valid,
      i.e. that the member's CGA address was generated from
      the public included in the message, that the member's
      CGA address is the same than the one contained in the
      certificate and that the signature is valid (i.e. the host
      owns the CGA address).

      After these two steps the router has the assurance that the
      member (1) the authorization certificate is valid and (2)
      it is used by the legitimate member (it has not be stolen).

      If the proof-of-membership is correct, then the router
      processes the report message normally, otherwise it
      rejects it.

   Note that the authorization certificate contains all the
   necessary information and that the routers that receive
   such as certificate do not have to contact any server nor

Expires January 20, 2001                                       [Page 16]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

   to have some pre-establised states (keys,etc). As a result,
   this scheme is very scalable and well adapted to mobile
   environment. Additionally, it solves all the problems of the
   basic scheme.  In fact, the certificate-based scheme:

   1. provides membership expiration. Each certificate has
      a validity field. When the validity of a certificate expires,
      the member needs to get a new certificate. The group
      controller can then refuse to re-issue the certificate,
      in effect, excluding the member if necessary. This use of
      short-term certificates avoids the need for a revocation

   2. does not require a secure channel between the
      group controller and the group members for the private
      key distribution.

   3. does not have the private key disclosure problem
      because the private key is not revealed by the group

   The format of the SPKI certificate that is used by this scheme
   is described in Appendix A.

6.0 Security Analysis

6.1 Hash ID Size Considerations

   In Multicast CGA addresses (M-CGA), the GroupID is 112 bits-long
   (63 bits-long for Anycast CGA), and is generated from the
   hash of the group public key.  In this section we evaluate the
   probability of intentional or unintentional collisions (i.e. the
   probability that 2 public keys generate the same GroupID).

   Suppose the hash function produces an n-bit long output. If we
   try to find some input which produces some target output value
   y, then since each output is equally likely we expect to have
   to try 2^(n-1) possible input values on average.  On the other
   hand, if we are worried about naturally occurring CGA address
   duplications, then by the birthday paradox we would expect that
   after trying 1.2 X 2^(n/2) possible input values we would have
   a 50% probability of collision [HandBook].  So if n=112 (n=63
   for anycast), you need a population of 1.2 X 2^(56) i.e. 8.64
   X 10^(16) Multicast addresses (1.2 X 2^(31.5) i.e. 3.64 X
   10^9 for anycast) on average before any two produce duplicate

Expires January 20, 2001                                       [Page 17]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

   addresses.  So unintentional collisions are very unlikely.
   If an attacker wishes to impersonate a given CGA Multicast
   address, it must attempt 2^(111) (2^(62) for anycast), i.e.
   approximately 2.59 X 10^(33) (4.8 X 10^(18) for anycast),
   tries to find a public key that hashes to this CGA address.
   If the attacker can perform 1 million hashes per second it
   will need 8.23 X 10^(19) (142,235 for anycast) years.

   Note that the previous analysis only considers the cost
   of computing the hash of the public key. Additionally, an
   attacker must also generate a valid public-private key pair.
   This is a significantly more expensive operation.

6.2 Denial-of-Service Attacks

   Denial-of-service (DoS) attacks that exhaust host resources
   (memory and processing resources) is a major security threat
   on the Internet. With our approach, the routers have to verify
   the signatures on the Report messages before processing them.
   Signature verification is an expensive operation and an
   attacker could attempt a DoS attack by sending numerous fake
   MLD messages to a router. The router will then spend most
   of its time verifying (wrong) signatures. However note that
   in order to attempt this type of attacks, the attacker must
   be attached to the same link as the router. This limits the
   risks considerably. There exists at least two solutions to
   this threat:

   - The routers may use some puzzle mechanisms as the one
     described in  [PUZZLES]. If a router believes that it is
     under attack it will reply to a MLD message with a puzzle
     request and will accept to process it only if it receives
     a valid puzzle reply.

   - For hosts that are not mobile or that are well known,
     a router might actually derive a shared key for each of
     them using sucvP [SUCV]. The MLD messages from these nodes
     will then be authenticated using a HMAC function instead of
     being signed. if a router believes that it is under attack it
     might then decide to process HMAC authenticated MLD messages
     before signed ones.

   - As an alternative to the previous scheme, hash chains could
     be used to derive a security association between certain hosts
     and the routers. The "proof-of-membership" phase could at the
     same time communicate a signed initial value for the hash
     chain. Each subsequent MLD message (up to a certain limit)

Expires January 20, 2001                                       [Page 18]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

     would use corresponding values taken from the hash chain. At
     the cost of keeping some state (the previous value for the
     hash) for each host, routers would carry out an initial
     signature verification.  Subsequent MLD messages would be
     verified by calculating a hash. This would allow routers to
     give preferential treatment to MLD messages authenticated
     via hash-chains.

6.3 Replay Attacks

   A malicious host might replay a valid Report message. Since
   the signature is valid, the router will accept the message.
   Replaying a valid Report message to join a group can be
   quite harmful because the router will re-join the group and
   packets will start flowing again. The effect of replaying
   a valid Report message to leave a group is less obvious.
   When a router receives such a message from a host, it sends
   a query message to the relevant group to check whether there
   are other hosts interested in it. Interested hosts will then
   reply with a report message. As a result, this attack will
   only generate extra load on the network but will not prevent
   legitimate members to receive the packets.

   A solution to this replay problem is to use a nonce which the
   querier must include in each of its query messages. A host
   that wants to join or leave a group must include the last nonce
   in its messages.  A router will accept an MLD message only if
   it has a valid nonce.  This solution is not optimal when fast
   registration is needed, as is the case with a mobile Multicast
   listener, because it would need to wait for the next Query
   message in order to learn the nonce. An optimization is for the
   mobile listener to actively solicit the nonce from the Querier,
   in preparation for or in response to moving into a new link.

   In the certificate-based scheme, it is possible to limit the
   window of exposure to replay attacks by issuing short-lived
   certificates. Of course, in order to avoid expired certificates
   from being used in replay attacks, it is necessary to have some
   time synchronization between the issuers of the certificates
   and the routers. Coarse time synchronization is probably
   enough, though.

6.4 Unauthorized Group CGA Address

   With our proposal nothing prevents a malicious host from
   generating an unauthorized Group CGA address (from a valid

Expires January 20, 2001                                       [Page 19]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

   public key) and then sending messages to join this group.
   Routers will accept those messages since the address is
   verifiable and the signature is valid.  This attack is not very
   harmful to the network itself because no active source is
   associated to this address and therefore no packet will be sent
   over the network. However this can be the source of a DoS attack
   on the infrastructure routers because joining groups creates
   entries for the corresponding addresses in the routers. Some
   solutions to this problem are presented in Section 6.2.  This
   attack can become much more harmful if several malicious hosts
   register this address with different routers distributed over
   the network and if some of them actually send packets to this
   address.  This DDoS attack can generate a lot of traffic on the
   network especially if there is a large number hosts that are
   malicious or merely have been broken into.

   This problem is difficult to solve. We believe that the solution
   space includes an access control mechanism that will forward
   packets to a group address only if the source is authorized to
   do so. This problem which can be referred as a source
   authorization problem is not an MLD problem, and is therefore
   outside the scope of this note. Here, we only consider the
   receiver authorization problem.

   Nevertheless, it may be possible to leverage the
   certificate-based solution presented here to limit this problem
   as well. Suppose the routing infrastructure is itself a group,
   and that it is defined by a Group CGA address (G-CGA). The
   routing infrastructure would then be able to explicitly
   authorize certain groups to exist.  In addition to the
   requirements spelled out in section 5.3.2 on the
   certificate-based scheme, a router verifying a host's
   proof-of-membership in a group would need the certificate in
   which the the routing infrastructure authorizes the relevant
   group to exist. This certificate would be issued by the routing
   infrastructure, so it would need to be signed with the
   corresponding private key.

7.0 Privacy Considerations

7.1 Group Structure Privacy

   By solving the ``group membership problem'' via group CGA
   addresses (either in M-CGA  or A-CGA format), it is possible
   (and quite natural) to not disclose to the  routers any

Expires January 20, 2001                                       [Page 20]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

   information beyond what is absolutely necessary for them. In
   particular, other proposals [ECUMN00] require at least that
   the group controllers or key issuers reveal their identity
   to the routers as part of distributing the tickets. Group
   CGA addresses obviate the need for such contact between the
   routers and any third parties or group controllers. This is
   not only a huge gain in terms of reliability and overhead,
   but also in terms of privacy.

   In fact, a  MLD report message only reveals the CGA address
   of the group and the current address of the subscribing
   member. This group CGA address is basically an identifier and
   does not provide any information about the group, the group
   controller or the members identities. For further privacy
   guarantees, the subscribing member's current address should be
   configured using the IPv6 address privacy extensions defined in
   [RFC3041] in order to hide the subscribing member's identity. As
   a result, a  router that receives an MLD message will know
   only that a group that uses a group CGA address exists and
   that there is at least one member on its links.

7.2 Traffic Privacy

   For certain groups, traffic confidentiality is a requirement.
   The certificate-based proposal could be leveraged to provide
   this as well.  For example, a group controller(s) could create
   a shared secret to be used for traffic encryption. But how
   would it communicate this shared secret to each and every one
   of the group members?

   As part of joining a group, a host obtains an authorization
   certificate either from the group controller or from a node
   authorized by it (section 5.3.2). In this "induction" step
   each host is explicitly addressed by the group.  At this
   very useful moment of induction, the group can, in addition
   to issuing the authorization certificate, communicate to the
   receiving host the shared secret.  The shared secret would
   be encrypted using the public key of the target host, so only
   the intended recipient would be able to decrypt and use it.

   Notice that this does not add any new communication
   requirements. The existing induction step is leveraged to
   provide one more service to the inductee: enabling it to
   participate in encrypted group communications.

   This is a very useful service, but there are some limitations in
   this simple scheme. For example, it is not a good idea to use

Expires January 20, 2001                                       [Page 21]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

   the same shared encryption key during the entire lifetime of the
   group. But how to change the keys? Assuming short-lived
   certificates, the often-repeating induction step could be used
   to communicate new keys. It may be necessary to use windows of
   synchronization between group memberships durations (as
   specified in the per-host authorization certificates issued by
   the group controller) and the shared keys used.  In other words,
   it may be simpler to follow the approach taken with the
   authorization certificates, in which their duration is used to
   impose membership expiration, instead of providing for explicit
   membership revocation. In similar manner, it may be easier to
   provide for shared encryption key expiration by specifying a
   limited lifetime for the keys (in terms of a time after which
   the key is valid, and a time beyond which it must not be used).
   This constitutes the activation period for the keys.

   If a hosts waits for the key to expire, it may be unable to
   decrypt traffic for some duration of time. This may be avoided
   if the induction step is treated as a registration. The host
   would need to re-register with the group periodically in order
   to obtain the required membership authorization certificate as
   well as the corresponding encryption key(s) (which may not
   become active until some time in the future).  Assuming some
   numbering on the generation of the key used, it may be possible
   for all member hosts to switch to new keys without very fine
   grained time synchronization.

   This could be done along the following lines:

   1. The group controller creates some keys in advance, for
      example, K1 [t1;t2], K2 [t2;t3], K3 [t3;t4], K4
      [t4;t5]...Kj[tj;tj+1], where Kj is the key, its activation
      period is defined by start and end times tj and tj+1, and j
      is the key index.  Notice that it is possible to create keys
      during the lifetime of the group.  Of course, the group
      controller must endeavor to create the keys and begin
      distributing them in advance of their activation period (that
      is, before they are used to encrypt traffic).

   2. When a host registers, it obtains an authorization
      certificate and a list of keys that covers the  duration of
      the certificate's validity.  For example, if a member's
      certificate is valid between [T0, T1], and:

         tj + e <= T0     <  t(j+1)
         tk     <  T1 + e <= t(k+1)

      (where, k > j and e is a time skew to account for imperfect

Expires January 20, 2001                                       [Page 22]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

      synchronization), the induction step must include keys Kj,

   3. At this point, the host is enabled to participate in a
      confidential group.  It has the required keys to decrypt
      during the duration of its authorized membership period. When
      performing encryption with key Kj, it must include the index
      j in plain text, so receivers know which key they must use
      for decryption. This is very important if encryption or
      decryption happens close to key activation or expiration
      times, or if keys have overlapping activation periods.

   4. When the certificate expires (at T1), the host needs to
      request a new certificate. An even better strategy is for the
      host to request a certificate renewal before its current
      certificate expires.  If at this  point the group controller
      decides to renew the certificate it also discloses the
      required keys as per step 1 above.

   If it is on a subnet where there are other authorized members,
   an expired member can potentially listen to the traffic between
   [tj;T0] and [T1;tk+1]. Depending on the duration of the key
   activation time slots and the nature of the group's traffic,
   this may be acceptable.

   This scheme is not yet completely specified, and further details
   are subject for future work.

8.0 Conclusion

   Handling group membership safely is a thorny problem which if
   ignored can lead to denial of service attacks. At the root of
   the problem is a node's being able to prove that it has the
   authorization to be a member of any given group. We propose a
   certain type of group addresses for both Multicast and Anycast
   groups. These addresses allow a fully distributed solution. When
   a routers receives an MLDv2 report from a multicast listener,
   it can verify that this listener is an authorized member of
   the group or groups. In order to do this the router does not
   need to contact any trusted third party, nor does it need any
   pre-established security association with the listeners. This
   is not only a huge gain in terms of scalability, reliability
   and overhead, but also in terms of privacy.

Expires January 20, 2001                                       [Page 23]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001


   We would like to thank Erik Nordmark for many helpful
   comments and discussions and Pekka Nikander who suggested the
   "certificate-based" approach described in Section 5.3.2. Their
   suggestions have improved our proposal significantly.

A. SPKI MLD Certificate

   This section describes the SPKI certificate that is used by
   the certificate-based scheme. Note that any authorization
   schemes such as Keynote [RFC2704] could also be used.

A.1 SPKI Review

   The IETF SPKI Working Group has developed a standard form for
   digital certificates whose main purpose is authorization rather
   than authentication.  SPKI main principles can be summarized
   as follows:

   - A certificate has 5 fields: (1) issuer (who is vouching), (2)
     subject (who is acquiring the permission, (3) delegation
     (set if the subject can delegate the permission), (4)
     authorization (specifies the permission being communicated)
     and (5) validity.

   - SPKI is key-oriented. No (name, key) binding , and
     therefore no CA, is necessary. The entities possesing,
     delegating and receiving access rights are cryptographic
     key pairs. A certificate can in short be written as:  Sk(K'
     has the right R., t) (K gives the right R to K' and the
     validity period is t), where K and K' are 2 public key.

   - A certificate has a validity period.

   - Delegation certificates differ from traditional access control
     schemes in that any key may issue certificates. There is no
     central or trusted authority.

   - A key may delegate rights to services it controls, it may also
     redelegate rights it received by delegation from other keys.
     When a key delegates to another key and this key in turn
     redelegates to a third one, and so on, the delegation
     certificates form a chain. The rights and the validity
     obtained by a chain of certificates are the intersections
     of the rights and validity of each certificate.  When a key

Expires January 20, 2001                                       [Page 24]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

     requests a service and it has obtained the access rights
     through a chain of certificates, it attaches the entire
     chain to its request.  Certificate chains can be reduced
     through certificate reduction.

     Sk1(K2 has R1, t1) and Sk2 (K3 has R2, t2) => Sk1(K2 has
     intersection(R1,R2), intersection(t1,t2))

     Certificate reduction is the main technique of certificate
     management in SPKI.

A.2 MLD SPKI certificate

   A full authorization certificate as used in our proposal
   is composed of a sequence of three objects  [SPKIE]:  the
   public-key object that contains the issuer public key,
   the certificate object that defines the authorization and a
   signature object that contains the signature.

       (public-key object)
       (cert object)
       (signature object)

   The public-key and signature objects are generic and
   defined in [RFC2693].  The cert. object is specific to
   each application. The MLD certificate object that is used
   to authorize hosts to join a group in our proposal has the
   following format:

        (issuer  (addr <gcga_addr>)
        (subject (addr <cga_addr>)
        (tag (mldjoin <gcga_addr> [<sourceaddr1>
        (not-before <date1>)
        (not-after  <date2>)

   This certificate is issued by the group controller.
   It authorizes the host that has the CGA address defined in

Expires January 20, 2001                                       [Page 25]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

   the subject field to join the group (potentially a Source
   Specific Multicast group) group defined in the tag field.
   The subject can propagate this authorization (this is optional).
   This certificate is only valid after the date1 and before date2.

        (issuer  (addr
        (subject (addr
        (tag (mldjoin
           FF5E:45CF:4AB2:12CF:6745:23B1:FE82:9678 *)
        (not-before ``2002-02-02_00:00:00'')
        (not-after  ``2002-03-02_00:00:00'')

      For example, the above certificate authorizes
      the host, H1, that has the CGA address,
      2001:660:1002:2000:7E45:F543:9C74:BA76, to join
      the Multicast group defined by the M-CGA address,
      FF5E:45CF:4AB2:12CF:6745:23B1:FE82:9678.  The <sourceaddr>
      field it set to ``*''. This means that the host can receive
      packets from any source of that group.  This certificate is
      only valid between the 2nd of february 2002 and the 2nd of
      march 2002.  This certicate has to be signed by the group
      private key.  The host H1 is allowed to propagate this
      authorization.  For example it could issue the following
      certificate to authorize the host H2 defined by the CGA
      address, 2001:660:1002:2000:45BE:CF12:3AF2:7843:ABDE,
      to join the same group by issuing the following certificate:

        (issuer  (addr
        (subject (addr
        (tag (mldjoin
           FF5E:45CF:4AB2:12CF:6745:23B1:FE82:9678 *)
        (not-before ``2002-02-05_00:00:00'') (not-after

   This certificate has to be signed by H1's private key (the one

Expires January 20, 2001                                       [Page 26]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

   whose public key was used to generate its CGA address).  When H2
   joins the group it has to include the two certificates in its
   message. Note that the chain of certificates can be reduced
   by the group controller.  In fact, as described in [RFC2693],

      Two SPKI certificates:
         <I1,S1,D1,A1,V1> + <I2,S2,D2,A2,V2>
      provided the two intersections succeed,
         S1 = I2
         D1 = TRUE

   Therefore the two previous certificates can be reduced as

        (issuer  (addr
        (subject (addr
        (tag (mldjoin
           FF5E:45CF:4AB2:12CF:6745:23B1:FE82:9678 *)
        (not-before ``2002-02-05_00:00:00'')
        (not-after  ``2002-02-20_00:00:00'')

A.3 Chain of Certificates

   Chains of certificates can be very useful to improve the
   scalability and manageability of our scheme.  For example,
   instead of managing the membership authorization of each group
   member (i.e. verifying that the member is allowed to join and
   generating the appropriate SPKI  certificate), the group
   controller can, instead, generate a SPKI certificate to a server
   in each domain, referred in this document as a local group
   controller, that is in charged of delegating this authorization
   to the members or to a sub-domain server (and so on). This
   delegation of membership authorization make our approach much
   more manageable for large-scale networks.

   Let's take the example of a content distribution application

Expires January 20, 2001                                       [Page 27]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

   that uses IP Multicast to deliver its data to its members
   worldwide.  If no delegation is used, the group controller must
   manage the membership authorization request of each member of
   the group. This approach does not perform if the number of
   members is large and if the members are far from the group

   It is obviously more practical and efficient if the group
   controller (that is for example in the US) delegates the
   right to join the group to several local group controllers
   (for example one per country) that are themselves in charge
   of authorizing local members.  The (global) group controller
   will typically issue a certificate to the local group
   controllers whose validity is much larger than the validity
   of the certificates issued by the local group controllers to
   the final members (for example one year versus one month).
   A host that wants to join a group will then ask to its local
   group controller a certificate. The local group controller will
   issue it upon reception of the host's credential (for example
   its fees).  The host will then join the group by including
   the chain of certificates in its MLD join message.

   This approach is much more scalable because the members'
   certificates are issued locally. It is also much more manageable
   because (1) the authorization credential can be defined locally
   (for example the registration price can then differ from one
   provider to another) and (2) a member can be excluded by the
   local group controller (by not reissuing the certificate)
   transparently to the global group controller.

   Certificate reduction is very useful to reduce the certificate
   verifying processing at the routers however it slightly
   breaks this hierarchical model because the reduction has
   to be performed by the group controller (or any host that
   knows the group private key). However even with reduction this
   hierarchical model is still attractive because the authorization
   management (i.e. the verification that a host is allowed to
   join a group) is still performed locally. In fact typically the
   local controller will (1) verify that the member is allowed
   to join the group, (2) generate a certificate stating that
   the member's credential has been verified and that the member
   is authorized to join the group, (3) send this certificate
   to the group controller that will reduce it and send it back
   to the local controller, (4) send the reduced certificate to
   the member.  Even though the group controller still has to
   reduce the certificate, the credential verification (step 1)
   is performed locally.

Expires January 20, 2001                                       [Page 28]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001


[AAP] M. Handley and S. Hanna, "Multicast Address Allocation Protocol
(AAP)," Work In Progress.

[ADDROWN] P. Nikander, "An Address Ownership Problem in IPv6," draft-
nikander-ipng-address-ownership-00.txt, February 2001.  Work in pro-

[AnycastSec] L. Dondeti, T. Hardjono, B. Haberman, "Security Require-
ments of IPv6 Anycast," draft-dondeti-ipv6-anycast-security-00.txt, June
2001.  Work in progress.

[CAM] Greg O'Shea and Michael Roe, "Child-proof Authentication for MIPv6
(CAM)", ACM Computer Communications Review, April 2001.

[DVMRP] T. Pusateri, "Distance Vector Multicast Routing Protocol,"
draft-ietf-idmr-dvmrp-v3-10.txt, August 2000.  Work in progress.

[ECUMN00] T. Hardjono and B. Cain, "Key Establishment for IGMP Authenti-
cation in IP Multicast," ECUMN, October 2000, Colmar, France.

[GKMarch] M. Baugher, R. Canetti and L. Dondeti, "Group Key Management
Architecture," draft-ietf-msec-gkmarch-01.txt, October 2001. Work in

[Haber] B. Haberman and D. Thaler, "Host-based Anycast using MLD,"
draft-haberman-ipngwg-host-anycast-00.txt, February 2001.

[HandBook] A.J. Menezes, P.C. van Oorschot and S.A. Vanstone.  Handbook
of applied cryptography. CRC Press, 1997.

[IGMPv3] B. Cain et al., "Internet Group Management Protocol, Version
3," draft-ietf-idmr-igmp-v3-07.txt, March 2001.  Work in progress.

[IGMPv3AndRouting] B. Haberman and J. Martin, "IGMPv3 and Multicast
Routing Protocol Interaction," draft-ietf-idmr-igmpv3-and-routing-
01.txt, July 2001. Work in progress.

[IPV6ADDR] B. Hinden and S. Deering, "IP Version6 Addressing Architec-
ture," RFC2373, July 1998.

[LKH] H. Harney, "Logical Key Hierarchical Protocol," draft-harney-
sparta-lkhp-sec-00.txt, March 1999.

[MASC] P. Radoslavov, et al, "The Multicast Address-Set Claim (MASC)
Protocol," RFC 2909, September 2000.

Expires January 20, 2001                                       [Page 29]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

[MIPv6] D. Johnson, C. Perkins, "Mobile IP for IPv6," draft-ietf-
mobileip-ipv6-14.txt. Work in progress.

[MLDv2] R. Vida, et al, "Multicast Listener Discovery Version 2 (MLDv2)
for IPv6," draft-vida-mld-v2-01.txt, July 2001. Work in progress.

[MSecWG] IETF Multicast Security (msec) Working Group.

[PUZZLES] T. Aura, P. Nikander and J. Leiwo. DOS-resistant Authentica-
tion with Client Puzzles.

[RFC1112] S. Deering, "Host Extensions for IP Multicasting," RFC 1112,
August 1989.

[RFC2093] H. Harney, C. Muckenhirn, "Group Key Management Protocol
(GKMP) Specification," RFC2093, July 1997.

[RFC2236] W. Fenner, "Internet Group Management Protocol, Version 2,"
RFC 2236, November 1997.

[RFC2362] D. Estrin and al., "Protocol Independent Multicast-Sparse Mode
(PIM-SM)," RFC 2362, June 1998.

[RFC2402] S. Kent and R. Athkinson, "IP Authentication Header," RFC
2402, November 1998.

[RFC2526] D. Johnson, S. Deering, "Reserved IPv6 Subnet Anycast
Addresses," RFC2526, March 1999.

[RFC2627] D. Wallner, E. Harder and R. Agee, "Key Management for Multi-
cast: Issues and Architectures," RFC2627, June 1999.

[RFC2693] C. Ellison et al., "SPKI Certificate Theory," RFC2693, Sep-
tember 1999.

[RFC2704] M. Blaze, J. Feigenbaum,  J. Ioannidis and A. Keromytis, "The
KeyNote Trust-Management System Version 2," RFC 2704, September 1999.

[RFC2710] S. Deering, W. Fenner, and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6," RFC 2710, November 1999.

[RFC3041] T. Narten, R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6," RFC 3041.

[Seamoby] IETF Seamoby Working Group.

Expires January 20, 2001                                       [Page 30]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

[SPKIE] Carl M. Ellison et al., "SPKI Examples", Internet Draft, March
1998.  Available at cme/examples.txt.

[SSM] H. Holbrook and B. Cain, "Source-Specific Multicast for IP."  Work
in Progress.

[SUCV] G. Montenegro and C. Castelluccia, "Statistically Unique and
Cryptographically Verifiable (SUCV) Identifiers and Addresses," NDSS
2002, February 2002.

[UniMcast] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 Multicast
Addresses," October 2001. Work in progress.

Authors' addresses

   Questions about this document may be directed to:

          Claude Castelluccia
          INRIA Rhone-Alpes
          655 avenue de l'Europe
          38330 Montbonnot Saint-Martin
          phone: +33 4 76 61 52 15
          fax:   +33 4 76 61 52 52

          Gabriel Montenegro
          Sun Microsystems Laboratories, Europe
          29, chemin du Vieux Chene
          38240 Meylan, FRANCE

          Voice:  +33 476 18 80 45

Copyright (c) The Internet Society (2001). All Rights Reserved.

   This document and translations of it may be copied and furnished
   to others, and derivative works that comment on or otherwise
   explain it or assist in its implementation may be prepared,
   copied, published and distributed, in whole or in part,
   without restriction of any kind, provided that the above
   copyright notice and this paragraph are included on all such
   copies and derivative works. However, this document itself may
   not be modified in any way, such as by removing the copyright
   notice or references to the Internet Society or other Internet
   organizations, except as needed for the purpose of developing

Expires January 20, 2001                                       [Page 31]

INTERNET DRAFT     Securing Group Management in IPv6       November 2001

   Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or
   as required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will not
   be revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided

Expires January 20, 2001                                       [Page 32]