tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4535

 
 
 

GSAKMP: Group Secure Association Key Management Protocol

Part 2 of 4, p. 15 to 45
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 15 
4.  Architecture

   This architecture presents a trust model for GSAKMP and a concept of
   operations for establishing a trusted distributed infrastructure for
   group key and policy distribution.

   GSAKMP conforms to the IETF MSEC architectural concepts as specified
   in the MSEC Architecture document [RFC3740].  GSAKMP uses the MSEC
   components to create a trust model for operations that implement the
   security principles of mutual suspicion and trusted policy creation
   authorities.

4.1.  Trust Model

4.1.1.  Components

   The trust model contains four key components:

   -  Group Owner (GO),

   -  Group Controller Key Server (GC/KS),

   -  Subordinate GC/KS (S-GC/KS), and

   -  Group Member (GM).

   The goal of the GSAKMP trust model is to derive trust from a common
   trusted policy creation authority for a group.  All security-relevant
   decisions and actions implemented by GSAKMP are based on information
   that ultimately is traceable to and verified by the trusted policy
   creation authority.  There are two trusted policy creation
   authorities for GSAKMP: the GO (policy creation authority) and the
   PKI root that allows us to verify the GO.

Top      Up      ToC       Page 16 
4.1.2.  GO

   The GO is the policy creation authority for the group.  The GO has a
   well-defined identity that is relevant to the group.  That identity
   can be of a person or of a group-trusted component.  All potential
   entities in the group have to recognize the GO as the individual with
   authority to specify policy for the group.

   The policy reflects the protection requirements of the data in a
   group.  Ultimately, the data and the application environment drives
   the security policy for the group.

   The GO has to determine the security rules and mechanisms that are
   appropriate for the data being protected by the group keys.  All this
   information is captured in a policy token (PT).  The GO creates the
   PT and signs it.

4.1.3.  GC/KS

   The GC/KS is authorized to perform several functions: key creation,
   key distribution, rekey, and group membership management.

   As the key creation authority, the GC/KS will create the set of keys
   for the group.  These keys include the Group Traffic Protection Keys
   (GTPKs) and first-tier rekey keys.  There may be second-tier rekey
   trees if a distributed rekey management structure is required for the
   group.

   As the key distribution (registration) authority, it has to notify
   the group of its location for registration services.  The GC/KS will
   have to enforce key access control as part of the key distribution
   and registration processes.

   As the group rekey authority, it performs rekey in order to change
   the group's GTPK.  Change of the GTPK limits the exposure of data
   encrypted with any single GTPK.

   Finally, as the group membership management authority, the GC/KS can
   manage the group membership (registration, eviction, de-registration,
   etc.).  This may be done in part by using a key tree approach, such
   as Logical Key Hierarchies (LKH), as an optional approach.

Top      Up      ToC       Page 17 
4.1.4.  Subordinate GC/KS

   A subordinate GC/KS is used to distribute the GC/KS functionality
   across multiple entities.  The S-GC/KS will have all the authorities
   of the GC/KS except one: it will not create the GTPK.  It is assumed
   here that the group will transmit data with a single GTPK at any one
   time.  This GTPK comes from the GC/KS.

   Note that relative to the GC/KS, the S-GC/KS is responsible for an
   additional security check: the S-GC/KS must register as a member with
   the GC/KS, and during that process it has to verify the authority of
   the GC/KS.

4.1.5.  GM

   The GM has two jobs: to make sure all security-relevant actions are
   authorized and to use the group keys properly.  During the
   registration process, the GM will verify that the PT is signed by a
   recognized GO.  In addition, it will verify that the GC/KS or S-GC/KS
   engaged in the registration process is authorized, as specified in
   the PT.  If rekey and new PTs are distributed to the group, the GM
   will verify that they are proper and all actions are authorized.

   The GM is granted access to group data through receipt of the group
   keys This carries along with it a responsibility to protect the key
   from unauthorized disclosure.

   GSAKMP does not offer any enforcement mechanisms to control which GMs
   are multicast speakers at a given moment.  This policy and its
   enforcement depend on the multicast application and its protocols.
   However, GSAKMP does allow a group to have one of three Group
   Security Association multicast speaker configurations:

   -  There is a single GM authorized to be the group's speaker.  There
      is one multicast application SA allocated by the GO in support of
      that speaker.  The PT initializes this multicast application SA
      and identifies the GM that has been authorized to be speaker.  All
      GMs share a single TPK with that GM speaker.  Sequence number
      checking for anti-replay protection is feasible and enabled by
      default.  This is the default group configuration.  GSAKMP
      implementations MUST support this configuration.

   -  The GO authorizes all of the GMs to be group speakers.  The GO
      allocates one multicast application SA in support of these
      speakers.  The PT initializes this multicast application SA and
      indicates that any GM can be a speaker.  All of the GMs share a
      single GTPK and other SA state information.  Consequently, some SA
      security features such as sequence number checking for anti-replay

Top      Up      ToC       Page 18 
      protection cannot be supported by this configuration.  GSAKMP
      implementations MUST support this group configuration.

   -  The GO authorizes a subset of the GMs to be group speakers (which
      may be the subset composed of all GMs).  The GO allocates a
      distinct multicast application SA for each of these speakers.  The
      PT identifies the authorized speakers and initializes each of
      their multicast application Security Associations.  The speakers
      still share a common TPK across their SA, but each speaker has a
      separate SA state information instance at every peer GM.
      Consequently, this configuration supports SA security features,
      such as sequence number checking for anti-replay protection, or
      source authentication mechanisms that require per-speaker state at
      the receiver.  The drawback of this configuration is that it does
      not scale to a large number of speakers.  GSAKMP implementations
      MAY support this group configuration.

4.1.6.  Assumptions

   The assumptions for this trust model are that:

   -  the GCKS is never compromised,

   -  the GO is never compromised,

   -  the PKI, subject to certificate validation, is trustworthy,

   -  The GO is capable of creating a security policy to meet the
      demands of the group,

   -  the compromises of a group member will be detectable and reported
      to the GO in a trusted manner,

   -  the subsequent recovery from a compromise will deny inappropriate
      access to protected data to the compromised member,

   -  no security-relevant actions depend on a precise network time,

   -  there are confidentiality, integrity, multicast source
      authentication, and anti-replay protection mechanisms for all
      GSAKMP control messages.

4.2.  Rule-Based Security Policy

   The trust model for GSAKMP revolves around the definition and
   enforcement of the security policy.  In fact, the use of the key is
   only relevant, in a security sense, if it represents the successful
   enforcement of the group security policy.

Top      Up      ToC       Page 19 
   Group operations lend themselves to rule-based security policy.  The
   need for distribution of data to many endpoints often leads to the
   defining of those authorized endpoints based on rules.  For example,
   all IETF attendees at a given conference could be defined as a single
   group.

   If the security policy rules are to be relevant, they must be coupled
   with validation mechanisms.  The core principle here is that the
   level of trust one can afford a security policy is exactly equal to
   the level of trust one has in the validation mechanism used to prove
   that policy.  For example, if all IETF attendees are allowed in, then
   they could register their identity from their certificate upon
   check-in to the meetings.  That certificate is issued by a trusted
   policy creation authority (PKI root) that is authorized to identify
   someone as an IETF attendee.  The GO could make admittance rules to
   the IETF group based on the identity certificates issued from trusted
   PKIs.

   In GSAKMP, every security policy rule is coupled with an explicit
   validation mechanism.  For interoperability considerations, GSAKMP
   requires that its supporting PKI implementations MUST be compliant to
   RFC 3280.

   If a GM's public key certificate is revoked, then the entity that
   issues that revocation SHOULD signal the GO, so that the GO can expel
   that GM.  The method that signals this event to the GO is not
   standardized by this specification.

   A direct mapping of rule to validation mechanism allows the use of
   multiple rules and PKIs to create groups.  This allows a GO to define
   a group security policy that spans multiple PKI domains, each with
   its own Certificate Authority public key certificate.

4.2.1.  Access Control

   The access control policy for the group keys is equivalent to the
   access control policy for the multicast application data the keys are
   protecting.

   In a group, each data source is responsible for ensuring that the
   access to the source's data is appropriate.  This implies that every
   data source should have knowledge of the access control policy for
   the group keys.

   In the general case, GSAKMP offers a suite of security services to
   its applications and does not prescribe how they use those services.

Top      Up      ToC       Page 20 
   GSAKMP supports the creation of GSAs with multiple data sources.  It
   also supports architectures where the GC/KS is not itself a data
   source.  In the multiple data source architectures GSAKMP requires
   that the access control policy is precisely defined and distributed
   to each data source.  The reference for this data structure is the
   GSAKMP Policy Token [RFC4534].

4.2.2.  Authorizations for Security-Relevant Actions

   A critical aspect of the GSAKMP trust model is the authorization of
   security-relevant actions.  These include download of group key,
   rekey, and PT creation and updates.  These actions could be used to
   disrupt the secure group, and all entities in the group must verify
   that they were instigated by authorized entities within the group.

4.3.  Distributed Operation

   Scalability is a core feature of GSAKMP.  GSAKMP's approach to
   scalable operations is the establishment of S-GC/KSes.  This allows
   the GSAKMP systems to distribute the workload of setting up and
   managing very large groups.

   Another aspect of distributed S-GC/KS operations is the enabling of
   local management authorities.  In very large groups, subordinate
   enclaves may be best suited to provide local management of the
   enclaves' group membership, due to a direct knowledge of the group
   members.

   One of the critical issues involved with distributed operation is the
   discovery of the security infrastructure location and security suite.
   Many group applications that have dynamic interactions must "find"
   each other to operate.  The discovery of the security infrastructure
   is just another piece of information that has to be known by the
   group in order to operate securely.

   There are several methods for infrastructure discovery:

   -  Announcements

   -  Anycast

   -  Rendezvous points / Registration

   One method for distributing the security infrastructure location is
   to use announcements.  The SAP is commonly used to announce the
   existence of a new multicast application or service.  If an

Top      Up      ToC       Page 21 
   application uses SAP [RFC2974] to announce the existence of a service
   on a multicast channel, that service could be extended to include the
   security infrastructure location for a particular group.

   Announcements can also be used by GSAKMP in one of two modes:
   expanding ring searches (ERSes) of security infrastructure and ERSes
   for infrastructure discovery.  In either case, the GSAKMP would use a
   multicast broadcast that would slowly increase in its range by
   incremental multicast hops.  The multicast source controls the
   packet's multicast range by explicitly setting its Time To Live
   count.

   An expanding ring announcement operates by the GC/KS announcing its
   existence for a particular group.  The number of hops this
   announcement would travel would be a locally configured number.  The
   GMs would listen on a well-known multicast address for GC/KSes that
   provide service for groups of interest.  If multiple GC/KSes are
   found that provide service, then the GM would pick the closest one
   (in terms of multicast hops).  The GM would then send a GSAKMP
   Request to Join message (RTJ) to the announced GC/KS.  If the
   announcement is found to be spurious, then that is reported to the
   appropriate management authorities.  The ERA concept is slightly
   different from SAP in that it could occur over the data channel
   multicast address, instead of a special multicast address dedicated
   for the SAP service.

   An expanding ring search operates in the reverse order of the ERA.
   In this case, the GM is the announcing entity.  The (S-)GC/KSes
   listen for the requests for service, specifically the RTJ.  The
   (S-)GC/KS responds to the RTJ.  If the GM receives more than one
   response, it would either ignore the responses or send NACKs based on
   local configuration.

   Anycast is a service that is very similar to ERS.  It also can be
   used to provide connection to the security infrastructure.  In this
   case, the GM would send the RTJ to a well-known service request
   address.  This anycast service would route the RTJ to an appropriate
   GC/KS.  The anycast service would have security infrastructure and
   network connectivity knowledge to facilitate this connection.

   Registration points can be used to distribute many group-relevant
   data, including security infrastructure.  Many group applications
   rely on well-known registration points to advertise the availability
   of groups.  There is no reason that GSAKMP could not use the same
   approach for advertising the existence and location of the security
   infrastructure.  This is a simple process if the application being
   supported already supports registration.  The GSAKMP infrastructure
   can always provide a registration site if the existence of this

Top      Up      ToC       Page 22 
   security infrastructure discovery hub is needed.  The registration of
   S-GC/KSes at this site could be an efficient way to allow GM
   registration.

   GSAKMP infrastructure discovery can use whatever mechanism suits a
   particular multicast application's requirements, including mechanisms
   that have not been discussed by this architecture.  However, GSAKMP
   infrastructure discovery is not standardized by this version of the
   GSAKMP specification.

4.4.  Concept of Operation

   This concept of operation shows how the different roles in GSAKMP
   interact to set up a secure group.  This particular concept of
   operation focuses on a secure group that utilizes the distributed key
   dissemination services of the S-GC/KS.

4.4.1.  Assumptions

   The most basic assumption here is that there is one or more
   trustworthy PKIs for the group.  That trusted PKI will be used to
   create and verify security policy rules.

   There is a GO that all GMs recognize as having group policy creation
   authority.  All GM must be securely pre-configured to know the GO
   public key.

   All GMs have access to the GO PKI information, both the trusted
   anchor public keys and the certificate path validation rules.

   There is sufficient connectivity between the GSAKMP entities.

   -  The registration SA requires that GM can connect to the GC/KS or
      S-GC/KS using either TCP or UDP.

   -  The Rekey SA requires that the data-layer multicast communication
      service be available.  This can be multicast IP, overlay networks
      using TCP, or NAT tunnels.

   -  GSAKMP can support many different data-layer secure applications,
      each with unique connectivity requirements.

4.4.2.  Creation of a Policy Token

   The GO creates and signs the policy token for a group.  The policy
   token contains the rules for access control and authorizations for a
   particular group.

Top      Up      ToC       Page 23 
   The PT consists of the following information:

   -  Identification: This allows an unambiguous identification of the
      PT and the group.

   -  Access Control Rules: These rules specify who can have access to
      the group keys.

   -  Authorization Rules: These rules specify who can be a S-GC/KS.

   -  Mechanisms: These rules specify the security mechanisms that will
      be used by the group.  This is necessary to ensure there is no
      weak link in the group security profile.  For example, for IPsec,
      this could include SPD/SAD configuration data.

   -  Source authentication of the PT to the GO: The PT is a CMS signed
      object, and this allows all GMs to verify the PT.

4.4.3.  Creation of a Group

   The PT is sent to a potential GC/KS.  This can occur in several ways,
   and the method of transmittal is outside the scope of GSAKMP.  The
   potential GC/KS will verify the GO signature on the PT to ensure that
   it comes from a trusted GO.  Next, the GC/KS will verify that it is
   authorized to become the GC/KS, based on the authorization rules in
   the PT.  Assuming that the GC/KS trusts the PT, is authorized to be a
   GC/KS, and is locally configured to become a GC/KS for a given group
   and the GO, then the GC/KS will create the keys necessary to start
   the group.  The GC/KS will take whatever action is necessary (if any)
   to advertise its ability to distribute key for the group.  The GC/KS
   will then listen for RTJs.

   The PT has a sequence number.  Every time a PT is distributed to the
   group, the group members verify that the sequence number on the PT is
   increasing.  The PT lifetime is not limited to a particular time
   interval, other than by the lifetimes imposed by some of its
   attributes (e.g., signature key lifetime).  The current PT sequence
   number is downloaded to the GM in the "Key Download" message.  Also,
   to avoid replay attacks, this sequence number is never reset to a
   lower value (i.e., rollover to zero) as long as the group identifier
   remains valid and in use.  The GO MUST preserve this sequence number
   across re-boots.

Top      Up      ToC       Page 24 
4.4.4.  Discovery of GC/KS

   Potential GMs will receive notice of the new group via some
   mechanism: announcement, Anycast, or registration look-up.  The GM
   will send an RTJ to the GC/KS.

4.4.5.  GC/KS Registration Policy Enforcement

   The GC/KS may or may not require cookies, depending on the DoS
   environment and the local configuration.

   Once the RTJ has been received, the GC/KS will verify that the GM is
   allowed to have access to the group keys.  The GC/KS will then verify
   the signature on the RTJ to ensure it was sent by the claimed
   identity.  If the checks succeed, the GC/KS will ready a Key Download
   message for the GM.  If not, the GC/KS can notify the GM of a non-
   security-relevant problem.

4.4.6.  GM Registration Policy Enforcement

   Upon receipt of the Key Download message, the GM will verify the
   signature on the message.  Then the GM will retrieve the PT from the
   Key Download message and verify that the GO created and signed the
   PT.  Once the PT is verified as valid, the GM will verify that the
   GC/KS is authorized to distribute key for this group.  Then the GM
   will verify that the mechanisms used in the group are available and
   acceptable for protection of the GMs data (assuming the GM is a data
   source).  The GM will then accept membership in this group.

   The GM will then check to see if it is allowed to be a S-GC/KS for
   this group.  If the GM is allowed to be a S-GC/KS AND the local GM
   configuration allows the GM to act as a S-GC/KS for this group, then
   the GM changes its operating state to S-GC/KS.  The GO needs to
   assign the authority to become a S-GC/KS in a manner that supports
   the overall group integrity and operations.

4.4.7.  Autonomous Distributed GSAKMP Operations

   In autonomous mode, each S-GC/KS operates a largely self-contained
   sub-group for which the Primary-GC/KS delegates the sub-group's
   membership management responsibility to the S-GC/KS.  In general, the
   S-GC/KS locally handles each Group Member's registration and
   de-registration without any interaction with the Primary-GC/KS.
   Periodically, the Primary-GC/KS multicasts a Rekey Event message
   addressed only to its one or more S-GC/KS.

   After a S-GC/KS successfully processes a Rekey Event message from the
   Primary-GC/KS, the S-GC/KS transmits to its sub-group its own Rekey

Top      Up      ToC       Page 25 
   Event message containing a copy of the group's new GTPK and policy
   token.  The S-GC/KS encrypts its Rekey Event message's sub-group key
   management information using Logical Key Hierarchy or a comparable
   rekey protocol.  The S-GC/KS uses the rekey protocol to realize
   forward and backward secrecy, such that only the authorized sub-group
   members can decrypt and acquire access to the new GTPK and policy
   token.  The frequency at which the Primary-GC/KS transmits a Rekey
   Event message is a policy token parameter.

   For the special case of a S-GC/KS detecting an expelled or
   compromised group member, a mechanism is defined to trigger an
   immediate group rekey rather than wait for the group's rekey period
   to elapse.  See below for details.

   Each S-GC/KS will be registered by the GC/KS as a management node
   with responsibility for GTPK distribution, access control policy
   enforcement, LKH tree creation, and distribution of LKH key arrays.
   The S-GC/KS will be registered into the primary LKH tree as an
   endpoint.  Each S-GC/KS will hold an entire LKH key array for the
   GC's LKH key tree.

   For the purpose of clarity, the process of creating a distributed
   GSAKMP group will be explained in chronological order.

   First, the Group Owner will create a policy token that authorizes a
   subset of the group's membership to assume the role of S-GC/KS.

   The GO needs to ensure that the S-GC/KS rules in the policy token
   will be stringent enough to ensure trust in the S-GC/KSes.  This
   policy token is handed off to the primary GC.

   The GC will create the GTPK and initial LKH key tree.  The GC will
   then wait for a potential S-GC/KS to send a Request to Join (RTJ)
   message.

   A potential S-GC/KS will eventually send an RTJ.  The GC will enforce
   the access control policy as defined in the policy token.  The
   S-GC/KS will accept the role of S-GC/KS and create its own LKH key
   tree for its sub-group membership.

   The S-GC/KS will then offer registration services for the group.
   There are local management decisions that are optional to control the
   scope of group members that can be served by a S-GC/KS.  These are
   truly local management issues that allow the administrators of an
   S-GC/KS to restrict service to potential GMs.  These local controls
   do not affect the overall group security policy, as defined in the
   policy token.

Top      Up      ToC       Page 26 
   A potential Group Member will send an RTJ to the S-GC/KS.  The
   S-GC/KS will enforce the entire access control policy as defined in
   the PT.  The GM will receive an LKH key array that corresponds to the
   LKH tree of the S-GC/KS.  The key tree generated by the S-GC/KS is
   independent of the key tree generated by the GC/KS; they share no
   common keys.

   The GM then has the keys it needs to receive group traffic and be
   subject to rekey from the S-GC/KS.  For the sake of this discussion,
   let's assume the GM is to be expelled from the group membership.

   The S-GC/KS will receive notification that the GM is to be expelled.
   This mechanism is outside the scope of this protocol.

   Upon notification that a GM that holds a key array within its LKH
   tree is to be expelled, the S-GC/KS does two things.  First, the
   S-GC/KS initiates a de-registration exchange with the GC/KS
   identifying the member to be expelled.  (The S-GC/KS proxies a Group
   Member's de-registration informing the GC/KS that the Group Member
   has been expelled from the group.)  Second, the S-GC/KS will wait for
   a rekey action by the GC/KS.  The immediacy of the rekey action by
   the GC/KS is a management decision at the GC/KS.  Security is best
   served by quick expulsion of untrusted members.

   Upon receipt of the de-registration notification from the S-GC/KS,
   the GC/KS will register the member to be expelled.  The GC/KS will
   then follow group procedure for initiating a rekey action (outside
   the scope of this protocol).  The GC/KS will communicate to the GO
   the expelled member's information (outside the scope of this
   protocol).  With this information, the GO will create a new PT for
   the group with the expelled GM identity added to the excluded list in
   the group's access control rules.  The GO provides this new PT to the
   GC/KS for distribution with the Rekey Event Message.

   The GC/KS will send out a rekey operation with a new PT.  The S-GC/KS
   will receive the rekey and process it.  At the same time, all other
   S-GC/KSes will receive the rekey and note the excluded GM identity.
   All S-GC/KSes will review local identities to ensure that the
   excluded GM is not a local member.  If it is, then the S-GC/KS will
   create a rekey message.  The S-GC/KSes must always create a rekey
   message, whether or not the expelled Group Member is a member of
   their subtrees.

   The S-GC/KS will then create a local rekey message.  The S-GC/KS will
   send the wrapped Group TPK to all members of its local LKH tree,
   except the excluded member(s).

Top      Up      ToC       Page 27 
5.  Group Life Cycle

   The management of a cryptographic group follows a life cycle:  group
   definition, group establishment, and security-relevant group
   maintenance.  Group definition involves defining the parameters
   necessary to support a secure group, including its policy token.
   Group establishment is the process of granting access to new members.
   Security-relevant group maintenance messages include rekey, policy
   changes, member deletions, and group destruction.  Each of these life
   cycle phases is discussed in the following sections.

   The use and processing of the optional Vendor ID payload for all
   messages can be found in Section 7.10.

5.1.  Group Definition

   A cryptographic group is established to support secure communications
   among a group of individuals.  The activities necessary to create a
   policy token in support of a cryptographic group include:

   -  Determine Access Policy: identify the entities that are authorized
      to receive the group key.

   -  Determine Authorization Policy: identify which entities are
      authorized to perform security-relevant actions, including key
      dissemination, policy creation, and initiation of security-
      management actions.

   -  Determine Mechanisms: define the algorithms and protocols used by
      GSAKMP to secure the group.

   -  Create Group Policy Token: format the policies and mechanisms into
      a policy token, and apply the GO signature.

5.2.  Group Establishment

   GSAKMP Group Establishment consists of three mandatory-to-implement
   messages: the Request to Join, the Key Download, and the Key Download
   Ack/Failure.  The exchange may also include two OPTIONAL error
   messages: the Request to Join Error and the Lack_of_Ack messages.
   Operation using the mandatory messages only is referred to as "Terse
   Mode", while inclusion of the error messaging is referred to as
   "Verbose Mode".  GSAKMP implementations MUST support Terse Mode and
   MAY support Verbose Mode.  Group Establishment is discussed in
   Section 5.2.1.

Top      Up      ToC       Page 28 
   A group is set in Terse or Verbose Mode by a policy token parameter.
   All (S-)GC/KSes in a Verbose Mode group MUST support Verbose Mode.
   GSAKMP allows Verbose Mode groups to have GMs that do not support
   Verbose Mode.  Candidate GMs that do not support Verbose Mode and
   receive a RTJ-Error or Lack-of-Ack message must handle these messages
   gracefully.  Additionally, a GM will not know ahead of time that it
   is interacting with the (S-)GC/KS in Verbose or Terse Mode until the
   policy token is received.

   For denial of service protection, a Cookie Exchange MAY precede the
   Group Establishment exchange.  The Cookie Exchange is described in
   Section 5.2.2.

   Regardless of mode, any error message sent between component members
   indicates the first error encountered while processing the message.

5.2.1.  Standard Group Establishment

   After the out-of-band receipt of a policy token, a potential Group
   Controller Key Server (GC/KS) verifies the token and its eligibility
   to perform GC/KS functionality.  It is then permitted to create any
   needed group keys and begin to establish the group.

   The GSAKMP Ladder Diagram, Figure 1, illustrates the process of
   establishing a cryptographic group.  The left side of the diagram
   represents the actions of the GC/KS.  The right side of the diagram
   represents the actions of the GMs.  The components of each message
   shown in the diagram are presented in Sections 5.2.1.1 through
   5.2.1.5.

    CONTROLLER   Mandatory/     MESSAGE                  MEMBER
                 Optional
              !<-M----------Request to Join-------------!
    <Process> !                                         !
    <RTJ>     !                                         !
              !--M----------Key Download--------------->!
              !                                         !<Process KeyDL>
              !--O-------Request to Join Error--------->! or
              !                                         ! <Proc RTJ-Err>
              !<-M----Key Download - Ack/Failure--------!
   <Process  >!                                         !
   <KeyDL-A/F>!                                         !
              !--O------Lack of Acknowledgement-------->!
              !                                         ! <Proc LOA>
              !<=======SHARED KEYED GROUP SESSION======>!

                  Figure 1: GSAKMP Ladder Diagram

Top      Up      ToC       Page 29 
   The Request to Join message is sent from a potential GM to the GC/KS
   to request admission to the cryptographic group.  The message
   contains key creation material, freshness data, an optional selection
   of mechanisms, and the signature of the GM.

   The Key Download message is sent from the GC/KS to the GM in response
   to an accepted Request to Join.  This GC/KS-signed message contains
   the identifier of the GM, freshness data, key creation material,
   encrypted keys, and the encrypted policy token.  The policy token is
   used to facilitate well-ordered group creation and MUST include the
   group's identification, group permissions, group join policy, group
   controller key server identity, group management information, and
   digital signature of the GO.  This will allow the GM to determine
   whether group policy is compatible with local policy.

   The Request to Join Error message is sent from the GC/KS to the GM in
   response to an unaccepted Request to Join.  This message is not
   signed by the GC/KS for two reasons: 1) the GM, at this point, has no
   knowledge of who is authorized to act as a GC/KS, and so the
   signature would thus be meaningless to the GM, and 2) signing
   responses to denied join requests would provide a denial of service
   potential.  The message contains an indication of the error
   condition.  The possible values for this error condition are:
   Invalid-Payload-Type, Invalid-Version, Invalid-Group-ID, Invalid-
   Sequence-ID, Payload-Malformed, Invalid-ID-Information, Invalid-
   Certificate, Cert-Type-Unsupported, Invalid-Cert-Authority,
   Authentication-Failed, Certificate-Unavailable, Unauthorized-Request,
   Prohibited-by-Group-Policy, and Prohibited-by-Locally-Configured-
   Policy.

   The Key Download Ack/Failure message indicates Key Download receipt
   status at the GM.  It is a GM-signed message containing freshness
   data and status.

   The Lack_of_Ack message is sent from the GC/KS to the GM in response
   to an invalid or absent Key Download Ack/Failure message.  The signed
   message contains freshness and status data and is used to warn the GM
   of impending eviction from the group if a valid Key Download
   Ack/Failure is not sent.  Eviction means that the member will be
   excluded from the group after the next Rekey Event.  The policy of
   when a particular group needs to rekey itself is stated in the policy
   token.  Eviction is discussed further in Section 5.3.2.1.

   For the following message structure sections, details about payload
   format and processing can be found in Section 7.  Each message is
   identified by its exchange type in the header of the message.  Nonces
   MUST be present in the messages unless synchronization time is
   available to the system.

Top      Up      ToC       Page 30 
5.2.1.1.  Request to Join

   The exchange type for Request to Join is eight (8).

   The components of a Request to Join Message are shown in Table 1.

              Table 1: Request to Join (RTJ) Message Definition

      Message Name  : Request to Join (RTJ)
      Dissection    : {HDR-GrpID, Key Creation, Nonce_I, [VendorID],
                    : [Notif_Mechanism_Choices], [Notif_Cookie],
                    : [Notif_IPValue]} SigM, [Cert]
      Payload Types : GSAKMP Header, Key Creation, [Nonce], [Vendor
                      ID], Signature, [Certificate], [Notifications]

        SigM        : Signature of Group Member
        Cert        : Necessary Certificates, zero or more
        {}SigX      : Indicates fields used in Signature
        []          : Indicate an optional data item


   As shown by Figure 1, a potential GM MUST generate and send an RTJ
   message to request permission to join the group.  At a minimum, the
   GM MUST be able to manually configure the destination for the RTJ.
   As defined in the dissection of the RTJ message, this message MUST
   contain a Key Creation payload for KEK determination.  A Nonce
   payload MUST be included for freshness and the Nonce_I value MUST be
   saved for potential later use.  The GC/KS will use this supplied
   nonce only if the policy token for this group defines the use of
   nonces versus synchronization time.  An OPTIONAL Notification payload
   of type Mechanism Choices MAY be included to identify the mechanisms
   the GM wants to use.  Absence of this payload will cause the GC/KS to
   select appropriate default policy-token-specified mechanisms for the
   Key Download.

   In response, the GC/KS accepts or denies the request based on local
   configuration.  <Process RTJ> indicates the GC/KS actions that will
   determine if the RTJ will be acted upon.  The following checks SHOULD
   be performed in the order presented.

   In this procedure, the GC/KS MUST verify that the message header is
   properly formed and confirm that this message is for this group by
   checking the value of the GroupID.  If the header checks pass, then
   the identity of the sender is extracted from the Signature payload.
   This identity MUST be used to perform access control checks and find
   the GMs credentials (e.g., certificate) for message verification.  It
   MUST also be used in the Key Download message.  Then, the GC/KS will
   verify the signature on the message to ensure its authenticity.  The

Top      Up      ToC       Page 31 
   GC/KS MUST use verified and trusted authentication material from a
   known root.  If the message signature verifies, the GC/KS then
   confirms that all required payloads are present and properly
   formatted based upon the mechanisms announced and/or requested.  If
   all checks pass, the GC/KS will create and send the Key Download
   message as described in Section 5.2.1.2.

   If the GM receives no response to the RTJ within the GM's locally
   configured timeout value, the GM SHOULD resend the RTJ message up to
   three (3) times.

   NOTE: At any one time, a GC/KS MUST process no more than one (1)
   valid RTJ message from a given GM per group until its pending
   registration protocol exchange concludes.

   If any error occurs during RTJ message processing, and the GC/KS is
   running in Terse Mode, the registration session MUST be terminated,
   and all saved state information MUST be cleared.

   The OPTIONAL Notification payload of type Cookie is discussed in
   Section 5.2.2.

   The OPTIONAL Notification payload of type IPValue may be used for the
   GM to convey a specific IP value to the GC/KS.

5.2.1.2.  Key Download

   The exchange type for Key Download is nine (9).

   The components of a Key Download Message are shown in Table 2:

               Table 2: Key Download (KeyDL) Message Definition

      Message Name  : Key Download (KeyDL)
      Dissection    : {HDR-GrpID, Member ID, [Nonce_R, Nonce_C], Key
                      Creation, (Policy Token)*, (Key Download)*,
                      [VendorID]} SigC, [Cert]
      Payload Types : GSAKMP Header, Identification, [Nonce], Key
                      Creation, Policy Token, Key Download, [Vendor
                      ID], Signature, [Certificate]

        SigC        : Signature of Group Controller Key Server
        Cert        : Necessary Certificates, zero or more
        {}SigX      : Indicates fields used in Signature
        []          : Indicate an optional data item
        (data)*     : Indicates encrypted information

Top      Up      ToC       Page 32 
   In response to a properly formed and verified RTJ message, the GC/KS
   creates and sends the KeyDL message.  As defined in the dissection of
   the message, this message MUST contain payloads to hold the following
   information: GM identification, Key Creation material, encrypted
   policy token, encrypted key information, and signature information.
   If synchronized time is not available, the Nonce payloads MUST be
   included in the message for freshness.

   If present, the nonce values transmitted MUST be the GC/KS's
   generated Nonce_R value and the combined Nonce_C value that was
   generated by using the GC/KS's Nonce_R value and the Nonce_I value
   received from the GM in the RTJ.

   If two-party key determination is used, the key creation material
   supplied by the GM and/or the GC/KS will be used to generate the key.
   Generation of this key is dependent on the key exchange, as defined
   in Section 7.11, "Key Creation Payload".  The policy token and key
   material are encrypted in the generated key.

   The GM MUST be able to process the Key Download message.  <Process
   KeyDL> indicates the GM actions that will determine how the Key
   Download message will be acted upon.  The following checks SHOULD be
   performed in the order presented.

   In this procedure, the GM will verify that the message header is
   properly formed and confirm that this message is for this group by
   checking the value of the GroupID.  If the header checks pass, the GM
   MUST confirm that this message was intended for itself by comparing
   the Member ID in the Identification payload to its identity.

   After identification confirmation, the freshness values are checked.
   If using nonces, the GM MUST use its saved Nonce_I value, extract the
   received GC/KS Nonce_R value, compute the combined Nonce_C value, and
   compare it to the received Nonce_C value.  If not using nonces, the
   GM MUST check the timestamp in the Signature payload to determine if
   the message is new.

   After freshness is confirmed, the signature MUST be verified to
   ensure its authenticity.  The GM MUST use verified and trusted
   authentication material from a known root.  If the message signature
   verifies, the key creation material is extracted from the Key
   Creation payload to generate the KEK.  This KEK is then used to
   decrypt the policy token data.  The signature on the policy token
   MUST be verified.  Access control checks MUST be performed on both
   the GO and the GC/KS to determine both their authorities within this
   group.  After all these checks pass, the KEK can then be used to

Top      Up      ToC       Page 33 
   decrypt and process the key material from the Key Download payload.
   If all is successful, the GM will create and send the Key Download -
   Ack/Failure message as described in Section 5.2.1.4.

   The Policy Token and Key Download Payloads are sent encrypted in the
   KEK generated by the Key Creation Payload information using the
   mechanisms defined in the group announcement.  This guarantees that
   the sensitive policy and key data for the group and potential rekey
   data for this individual cannot be read by anyone but the intended
   recipient.

   If any error occurs during KeyDL message processing, regardless of
   whether the GM is in Terse or Verbose Mode, the registration session
   MUST be terminated, the GM MUST send a Key Download - Ack/Failure
   message, and all saved state information MUST be cleared.  If in
   Terse Mode, the Notification Payload will be of type NACK to indicate
   termination.  If in Verbose Mode, the Notification Payload will
   contain the type of error encountered.

5.2.1.3.  Request to Join Error

   The exchange type for Request to Join Error is eleven (11).

   The components of the Request to Join Error Message are shown in
   Table 3:

         Table 3: Request to Join Error (RTJ-Err) Message Definition

      Message Name  : Request to Join Error (RTJ-Err)
      Dissection    : {HDR-GrpID, [Nonce_I], Notification, [VendorID]}
      Payload Types : GSAKMP Header, [Nonce] Notification, [Vendor ID]

   In response to an unacceptable RTJ, the GC/KS MAY send a Request to
   Join Error (RTJ-Err) message containing an appropriate Notification
   payload.  Note that the RTJ-Err message is not a signed message for
   the following reasons: the lack of awareness on the GM's perspective
   of who is a valid GC/KS as well as the need to protect the GC/KS from
   signing messages and using valuable resources.  Following the sending
   of an RTJ-Err, the GC/KS MUST terminate the session, and all saved
   state information MUST be cleared.

   Upon receipt of an RTJ-Err message, the GM will validate the
   following: the GroupID in the header belongs to a group to which the
   GM has sent an RTJ, and, if present, the Nonce_I matches a Nonce_I
   sent in an RTJ to that group.  If the above checks are successful,
   the GM MAY terminate the state associated with that GroupID and

Top      Up      ToC       Page 34 
   nonce.  The GM SHOULD be capable of receiving a valid KeyDownload
   message for that GroupID and nonce after receiving an RTJ-Err for a
   locally configured amount of time.

5.2.1.4.  Key Download - Ack/Failure

   The exchange type for Key Download - Ack/Failure is four (4).

   The components of the Key Download - Ack/Failure Message are shown in
   Table 4:

      Table 4: Key Download - Ack/Failure (KeyDL-A/F) Message Definition

      Message Name  : Key Download - Ack/Failure (KeyDL-A/F)
      Dissection    : {HDR-GrpID, [Nonce_C], Notif_Ack, [VendorID]}SigM
      Payload Types : GSAKMP Header, [Nonce], Notification, [Vendor
                      ID], Signature
        SigM        : Signature of Group Member
        {}SigX      : Indicates fields used in Signature

   In response to a properly processed KeyDL message, the GM creates and
   sends the KeyDL-A/F message.  As defined in the dissection of the
   message, this message MUST contain payloads to hold the following
   information: Notification payload of type Acknowledgement (ACK) and
   signature information.  If synchronized time is not available, the
   Nonce payload MUST be present for freshness, and the nonce value
   transmitted MUST be the GM's generated Nonce_C value.  If the GM does
   not receive a KeyDL message within a locally configured amount of
   time, the GM MAY send a new RTJ.  If the GM receives a valid LOA (see
   Section 5.2.1.5) message from the GC/KS before receipt of a KeyDL
   message, the GM SHOULD send a KeyDL-A/F message of type NACK followed
   by a new RTJ.

   The GC/KS MUST be able to process the KeyDL-A/F message.  <Process
   KeyDL-A/F> indicates the GC/KS actions that will determine how the
   KeyDL-A/F message will be acted upon.  The following checks SHOULD be
   performed in the order presented.

   In this procedure, the GC/KS will verify that the message header is
   properly formed and confirm that this message is for this group by
   checking the value of the GroupID.  If the header checks pass, the
   GC/KS MUST check the message for freshness.  If using nonces, the
   GC/KS MUST use its saved Nonce_C value and compare it for equality
   with the received Nonce_C value.  If not using nonces, the GC/KS MUST
   check the timestamp in the Signature payload to determine if the
   message is new.  After freshness is confirmed, the signature MUST be
   verified to ensure its authenticity.  The GC/KS MUST use verified and
   trusted authentication material from a known root.  If the message

Top      Up      ToC       Page 35 
   signature verifies, the GC/KS processes the Notification payload.  If
   the notification type is of type ACK, then the registration has
   completed successfully, and both parties SHOULD remove state
   information associated with this GM's registration.

   If the GC/KS does not receive a KeyDL-A/F message of proper form or
   is unable to correctly process the KeyDL-A/F message, the
   Notification payload type is any value except ACK; or if no KeyDL-A/F
   message is received within the locally configured timeout, the GC/KS
   MUST evict this GM from the group in the next policy-defined Rekey
   Event.  The GC/KS MAY send the OPTIONAL Lack_of_Ack message if
   running in Verbose Mode as defined in Section 5.2.1.5.

5.2.1.5.  Lack of Ack

   The exchange type for Lack of Ack is twelve (12).

   The components of a Lack of Ack Message are shown in Table 5:

                Table 5: Lack of Ack (LOA) Message Definition

      Message Name  : Lack of Ack (LOA)
      Dissection    : {HDR-GrpID, Member ID, [Nonce_R, Nonce_C],
                      Notification, [VendorID]} SigC, [Cert]
      Payload Types : GSAKMP Header, Identification, [Nonce],
                      Notification, [Vendor ID], Signature,
                      [Certificate]

        SigC        : Signature of Group Controller Key Server
        Cert        : Necessary Certificates, zero or more
        {}SigX      : Indicates fields used in Signature
        []          : Indicate an optional data item

   If the GC/KS's local timeout value expires prior to receiving a
   KeyDL-A/F from the GM, the GC/KS MAY create and send a LOA message to
   the GM.  As defined in the dissection of the message, this message
   MUST contain payloads to hold the following information: GM
   identification, Notification of error, and signature information.

   If synchronized time is not available, the Nonce payloads MUST be
   present for freshness, and the nonce values transmitted MUST be the
   GC/KS's generated Nonce_R value and the combined Nonce_C value which
   was generated by using the GC/KS's Nonce_R value and the Nonce_I
   value received from the GM in the RTJ.  These values were already
   generated during the Key Download message phase.

Top      Up      ToC       Page 36 
   The GM MAY be able to process the LOA message based upon local
   configuration.  <Process LOA> indicates the GM actions that will
   determine how the LOA message will be acted upon.  The following
   checks SHOULD be performed in the order presented.

   In this procedure, the GM MUST verify that the message header is
   properly formed and confirm that this message is for this group by
   checking the value of the GroupID.  If the header checks pass, the GM
   MUST confirm that this message was intended for itself by comparing
   the Member ID in the Identification payload to its identity.  After
   identification confirmation, the freshness values are checked.  If
   using nonces, the GM MUST use its save Nonce_I value, extract the
   received GC/KS Nonce_R value, compute the combined Nonce_C value, and
   compare it to the received Nonce_C value.  If not using nonces, the
   GM MUST check the timestamp in the Signature payload to determine if
   the message is new.  After freshness is confirmed, access control
   checks MUST be performed on the GC/KS to determine its authority
   within this group.  Then signature MUST be verified to ensure its
   authenticity, The GM MUST use verified and trusted authentication
   material from a known root.

   If the checks succeed, the GM SHOULD resend a KeyDL-A/F for that
   session.

5.2.2.  Cookies: Group Establishment with Denial of Service Protection

   This section defines an OPTIONAL capability that MAY be implemented
   into GSAKMP when using IP-based groups.  The information in this
   section borrows heavily from [IKEv2] as this protocol has already
   worked through this issue and GSAKMP is copying this concept.  This
   section will contain paraphrased sections of [IKEv2] modified for
   GSAKMP to define the purpose of Cookies.

   An optional Cookie mode is being defined for the GSAKMP to help
   against DoS attacks.

   The term "cookies" originates with Karn and Simpson [RFC2522] in
   Photuris, an early proposal for key management with IPSec.  The
   ISAKMP fixed message header includes two eight-octet fields titled
   "cookies".  Instead of placing this cookie data in the header, in
   GSAKMP this data is moved into a Notification payload.

   An expected attack against GSAKMP is state and CPU exhaustion, where
   the target GC/KS is flooded with Request to Join requests from forged
   IP addresses.  This attack can be made less effective if a GC/KS
   implementation uses minimal CPU and commits no state to the
   communication until it knows the initiator potential GM can receive
   packets at the address from which it claims to be sending them.  To

Top      Up      ToC       Page 37 
   accomplish this, the GC/KS (when operating in Cookie mode) SHOULD
   reject initial Request to Join messages unless they contain a
   Notification payload of type "cookie".  It SHOULD instead send a
   Cookie Download message as a response to the RTJ and include a cookie
   in a notify payload of type Cookie_Required.  Potential GMs who
   receive such responses MUST retry the Request to Join message with
   the responder-GC/KS-supplied cookie in its notification payload of
   type Cookie, as defined by the optional Notification payload of the
   Request to Join Msg in Section 5.2.1.1.  This initial exchange will
   then be as shown in Figure 2 with the components of the new message
   Cookie Download shown in Table 6.  The exchange type for Cookie
   Download is ten (10).

     CONTROLLER                  MESSAGE                  MEMBER
     in Cookie Mode
               !<--Request to Join without Cookie Info---!
   <Gen Cookie>!                                         !
   <Response  >!                                         !
               !----------Cookie Download--------------->!
               !                                         ! <Process CD>
               !<----Request to Join with Cookie Info----!
     <Process> !                                         !
     <RTJ    > !                                         !
               !-------------Key Download--------------->!
               !                                         ! <Proc KeyDL>
               !<-----Key Download -  Ack/Failure--------!
    <Process  >!                                         !
    <KeyDL-A/F>!                                         !
               !<=======SHARED KEYED GROUP SESSION======>!

               Figure 2: GSAKMP Ladder Diagram with Cookies


                 Table 6: Cookie Download Message Definition

      Message Name  : Cookie Download
      Dissection    : {HDR-GrpID, Notif_COOKIE_REQUIRED, [VendorID]}
      Payload Types : GSAKMP Header, Notification, [Vendor ID]


   The first two messages do not affect any GM or GC/KS state except for
   communicating the cookie.

   A GSAKMP implementation SHOULD implement its GC/KS cookie generation
   in such a way as not to require any saved state to recognize its
   valid cookie when the second Request to Join message arrives.  The
   exact algorithms and syntax they use to generate cookies does not
   affect interoperability and hence is not specified here.

Top      Up      ToC       Page 38 
   The following is an example of how an endpoint could use cookies to
   implement limited DoS protection.

   A good way to do this is to set the cookie to be:

   Cookie = <SecretVersionNumber> | Hash(Ni | IPi | <secret>)

   where <secret> is a randomly generated secret known only to the
   responder GC/KS and periodically changed, Ni is the nonce value taken
   from the initiator potential GM, and IPi is the asserted IP address
   of the candidate GM.  The IP address is either the IP header's source
   IP address or else the IP address contained in the optional
   Notification "IPvalue" payload (if it is present).
   <SecretVersionNumber> should be changed whenever <secret> is
   regenerated.  The cookie can be recomputed when the "Request to Join
   with Cookie Info" arrives and compared to the cookie in the received
   message.  If it matches, the responder GC/KS knows that all values
   have been computed since the last change to <secret> and that IPi
   MUST be the same as the source address it saw the first time.
   Incorporating Ni into the hash assures that an attacker who sees only
   the Cookie_Download message cannot successfully forge a "Request to
   Join with Cookie Info" message.  This Ni value MUST be the same Ni
   value from the original "Request to Join" message for the calculation
   to be successful.

   If a new value for <secret> is chosen while connections are in the
   process of being initialized, a "Request to Join with Cookie Info"
   might be returned with a <SecretVersionNumber> other than the current
   one.  The responder GC/KS in that case MAY reject the message by
   sending another response with a new cookie, or it MAY keep the old
   value of <secret> around for a short time and accept cookies computed
   from either one.  The responder GC/KS SHOULD NOT accept cookies
   indefinitely after <secret> is changed, since that would defeat part
   of the denial of service protection.  The responder GC/KS SHOULD
   change the value of <secret> frequently, especially if under attack.

   An alternative example for Cookie value generation in a NAT
   environment is to substitute the IPi value with the IPValue received
   in the Notification payload in the RTJ message.  This scenario is
   indicated by the presence of the Notification payload of type
   IPValue.  With this substitution, a calculation similar to that
   described above can be used.

Top      Up      ToC       Page 39 
5.2.3.  Group Establishment for Receive-Only Members

   This section describes an OPTIONAL capability that may be implemented
   in a structured system where the authorized (S-)GC/KS is known in
   advance through out-of-band means and where synchronized time is
   available.

   Unlike Standard Group Establishment, in the Receive-Only system, the
   GMs and (S-)GC/KSes operate in Terse Mode and exchange one message
   only: the Key Download.  Potential new GMs do not send an RTJ.
   (S-)GC/KSes do not expect Key Download - ACK/Failure messages and do
   not remove GMs for lack or receipt of the message.

   Operation is as follows: upon notification via an authorized out-of-
   band event, the (S-)GC/KS forms and sends a Key Download message to
   the new member with the Nonce payloads ABSENT.  The GM verifies

   -  the ID payload identifies that GM

   -  the timestamp in the message is fresh

   -  the message is signed by an authorized (S-)GC/KS

   -  the signature on the message verifies

   When using a Diffie-Hellman Key Creation Type for receive-only
   members, a static-ephemeral model is assumed: the Key Creation
   payload in the Key Download message contains the (S-)GC/KS's public
   component.  The member's public component is assumed to be obtained
   through secure out-of-band means.

5.3.  Group Maintenance

   The Group Maintenance phase includes member joins and leaves, group
   rekey activities, policy updates, and group destruction.  These
   activities are presented in the following sections.

5.3.1.  Group Management

5.3.1.1.  Rekey Events

   A Rekey Event is any action, including a compromise report or key
   expiration, that requires the creation of a new group key and/or
   rekey information.

   Once an event has been identified (as defined in the group security
   policy token), the GC/KS MUST create and provide a signed message
   containing the GTPK and rekey information to the group.

Top      Up      ToC       Page 40 
   Each GM who receives this message MUST verify the signature on the
   message to ensure its authenticity.  If the message signature does
   not verify, the message MUST be discarded.  Upon verification, the GM
   will find the appropriate rekey download packet and decrypt the
   information with a stored rekey key(s).  If a new Policy Token is
   distributed with the message, it MUST be encrypted in the old GTPK.

   The exchange type for Rekey Event is five (5).

   The components of a Rekey Event message are shown in Table 7:

                   Table 7: Rekey Event Message Definition

      Message Name  : Rekey Event
      Dissection    : {HDR-GrpID, ([Policy Token])*, Rekey Array,
                      [VendorID]}SigC, [Cert]
      Payload Types : GSAKMP Header, [Policy Token], Rekey Event,
                      [Vendor ID], Signature, [Certificate],

        SigC        : Signature of Group Controller Key Server
        Cert        : Necessary Certificates, zero or more
        {}SigX      : Indicates fields used in Signature
        (data)*     : Indicates encrypted information
        []          : Indicate an optional data item

5.3.1.2.  Policy Updates

   New policy tokens are sent via the Rekey Event message.  These policy
   updates may be coupled with an existing rekey event or may be sent in
   a message with the Rekey Event Type of the Rekey Event Payload set to
   None(0) (see Section 7.5.1).

   A policy token MUST NOT be processed if the processing of the Rekey
   Event message carrying it fails.  Policy token processing is type
   dependent and is beyond the scope of this document.

5.3.1.3.  Group Destruction

   Group destruction is also accomplished via the Rekey Event message.
   In a Rekey Event message for group destruction, the Sequence ID is
   set to 0xFFFFFFFF.  Upon receipt of this authenticated Rekey Event
   message, group components MUST terminate processing of information
   associated with the indicated group.

Top      Up      ToC       Page 41 
5.3.2.  Leaving a Group

   There are several conditions under which a member will leave a group:
   eviction, voluntary departure without notice, and voluntary departure
   with notice (de-registration).  Each of these is discussed in this
   section.

5.3.2.1.  Eviction

   At some point in the group's lifetime, it may be desirable to evict
   one or more members from a group.  From a key management viewpoint,
   this involves revoking access to the group's protected data by
   "disabling" the departing members' keys.  This is accomplished with a
   Rekey Event, which is discussed in more detail in Section 5.3.1.1.
   If future access to the group is also to be denied, the members MUST
   be added to a denied access control list, and the policy token's
   authorization rules MUST be appropriately updated so that they will
   exclude the expelled GM(s).  After receipt of a new PT, GMs SHOULD
   evaluate the trustworthiness of any recent application data
   originating from the expelled GM(s).

5.3.2.2.  Voluntary Departure without Notice

   If a member wishes to leave a group for which membership imposes no
   cost or responsibility to that member, then the member MAY merely
   delete local copies of group keys and cease group activities.

5.3.2.3.  De-Registration

   If the membership in the group does impose cost or responsibility to
   the departing member, then the member SHOULD de-register from the
   group when that member wishes to leave.  De-registration consists of
   a three-message exchange between the GM and the member's GC/KS:  the
   Request_to_Depart, Departure_Response, and the Departure_Ack.
   Compliant GSAKMP implementations for GMs SHOULD support the de-
   registration messages.  Compliant GSAKMP implementations for GC/KSes
   MUST support the de-registration messages.

5.3.2.3.1.  Request to Depart

   The Exchange Type for a Request_to_Depart Message is thirteen (13).
   The components of a Request_to_Depart Message are shown in Table 8.

   Any GM desiring to initiate the de-registration process MUST generate
   and send an RTD message to notify the GC/KS of its intent.  As
   defined in the dissection of the RTD message, this message MUST
   contain payloads to hold the following information: the GC/KS
   identification and Notification of the desire to leave the group.

Top      Up      ToC       Page 42 
   When synchronization time is not available to the system as defined
   by the Policy Token, a Nonce payload MUST be included for freshness,
   and the Nonce_I value MUST be saved for later use.  This message MUST
   then be signed by the GM.

             Table 8: Request_to_Depart (RTD) Message Definition

     Message Name  : Request_to_Depart (RTD)
     Dissection    : {HDR-GrpID, GC/KS_ID, [Nonce_I], Notif_Leave_Group,
                     [VendorID]} SigM, [Cert]
     Payload Types : GSAKMP Header, Identification, [Nonce],
                     Notification, [Vendor ID], Signature,
                     [Certificate]

       SigM        : Signature of Group Member
       Cert        : Necessary Certificates, zero or more
       {}SigX      : Indicates fields used in Signature
       []          : Indicate an optional data item

   Upon receipt of the RTD message, the GC/KS MUST verify that the
   message header is properly formed and confirm that this message is
   for this group by checking the value of the GroupID.  If the header
   checks pass, then the identifier value in Identification payload is
   compared to its own, the GC/KS's identity, to confirm that the GM
   intended to converse with this GC/KS, the GC/KS who registered this
   member into the group.  Then the identity of the sender is extracted
   from the Signature payload.  This identity MUST be used to confirm
   that this GM is a member of the group serviced by this GC/KS.  Then
   the GC/KS will confirm from the Notification payload that the GM is
   requesting to leave the group.  Then the GC/KS will verify the
   signature on the message to ensure its authenticity.  The GC/KS MUST
   use verified and trusted authentication material from a known root.
   If all checks pass and the message is successfully processed, then
   the GC/KS MUST form a Departure_Response message as defined in
   Section 5.3.2.3.2.

   If the processing of the message fails, the de-registration session
   MUST be terminated, and all state associated with this session is
   removed.  If the GC/KS is operating in Terse Mode, then no error
   message is sent to the GM.  If the GC/KS is operating in Verbose
   Mode, then the GC/KS sends a Departure_Response Message with a
   Notification Payload of type Request_to_Depart_Error.

Top      Up      ToC       Page 43 
5.3.2.3.2.  Departure_Response

   The Exchange Type for a Departure_Response Message is fourteen (14).
   The components of a Departure_Response Message are shown in Table 9.

   In response to a properly formed and verified RTD message, the GC/KS
   MUST create and send the DR message.  As defined in the dissection of
   the message, this message MUST contain payloads to hold the following
   information: GM identification, Notification for acceptance of
   departure, and signature information.  If synchronization time is not
   available, the Nonce payloads MUST be included in the message for
   freshness.

             Table 9: Departure_Response (DR) Message Definition

      Message Name  : Departure_Response (DR)
      Dissection    : {HDR-GrpID, Member_ID, [Nonce_R, Nonce_C],
                      Notification, [VendorID]} SigC, [Cert]
      Payload Types : GSAKMP Header, Identification, [Nonce],
                      Notification, [Vendor ID], Signature,
                      [Certificate]

        SigC        : Signature of Group Member
        Cert        : Necessary Certificates, zero or more
        {}SigX      : Indicates fields used in Signature
        []          : Indicate an optional data item

   If present, the nonce values transmitted MUST be the GC/KS's
   generated Nonce_R value and the combined Nonce_C value that was
   generated by using the GC/KS's Nonce_R value and the Nonce_I value
   received from the GM in the RTD.  This Nonce_C value MUST be saved
   relative to this departing GM's ID.

   The GM MUST be able to process the Departure_Response message.  The
   following checks SHOULD be performed in the order presented.

   The GM MUST verify that the message header is properly formed and
   confirm that this message is for this group by checking the value of
   the GroupID.  If the header checks pass, the GM MUST confirm that
   this message was intended for itself by comparing the Member ID in
   the Identification payload to its identity.  After identification
   confirmation, the freshness values are checked.  If using nonces, the
   GM MUST use its saved Nonce_I value, extract the received GC/KS
   Nonce_R value, compute the combined Nonce_C value, and compare it for
   equality with the received Nonce_C value.  If not using nonces, the
   GM MUST check the timestamp in the signature payload to determine if
   the message is new.  After freshness is confirmed, confirmation of
   the identity of the signer of the DR message is the GMs authorized

Top      Up      ToC       Page 44 
   GC/KS is performed.  Then, the signature MUST be verified to ensure
   its authenticity.  The GM MUST use verified and trusted
   authentication material from a known root.  If the message signature
   verifies, then the GM MUST verify that the Notification is of Type
   Departure_Accepted or Request_to_Depart_Error.

   If the processing is successful, and the Notification payload is of
   type Departure_Accepted, the member MUST form the Departure_ACK
   message as defined in Section 5.3.2.3.3.  If the processing is
   successful, and the Notification payload is of type
   Request_to_Depart_Error, the member MUST remove all state associated
   with the de-registration session.  If the member still desires to
   De-Register from the group, the member MUST restart the de-
   registration process.

   If the processing of the message fails, the de-registration session
   MUST be terminated, and all state associated with this session is
   removed.  If the GM is operating in Terse Mode, then a Departure_Ack
   Message with Notification Payload of type NACK is sent to the GC/KS.
   If the GM is operating in Verbose Mode, then the GM sends a
   Departure_Ack Message with a Notification Payload of the appropriate
   failure type.

5.3.2.3.3.  Departure_ACK

   The Exchange Type for a Departure_ACK Message is fifteen (15).  The
   components of the Departure_ACK Message are shown in Table 10:

               Table 10: Departure_ACK (DA) Message Definition

      Message Name  : Departure_ACK (DA)
      Dissection    : {HDR-GrpID, [Nonce_C], Notif_Ack, [VendorID]}SigM
      Payload Types : GSAKMP Header, [Nonce], Notification, [Vendor
                      ID], Signature
        SigM        : Signature of Group Member
        {}SigX      : Indicates fields used in Signature

   In response to a properly processed Departure_Response message, the
   GM MUST create and send the Departure_ACK message.  As defined in the
   dissection of the message, this message MUST contain payloads to hold
   the following information: Notification payload of type
   Acknowledgement (ACK) and signature information.  If synchronization
   time is not available, the Nonce payload MUST be present for
   freshness, and the nonce value transmitted MUST be the GM's generated
   Nonce_C value.

Top      Up      ToC       Page 45 
   Upon receipt of the Departure_ACK, the GC/KS MUST perform the
   following checks.  These checks SHOULD be performed in the order
   presented.

   In this procedure, the GC/KS MUST verify that the message header is
   properly formed and confirm that this message is for this group by
   checking the value of the GroupID.  If the header checks pass, the
   GC/KS MUST check the message for freshness.  If using nonces, the
   GC/KS MUST use its saved Nonce_C value and compare it to the received
   Nonce_C value.  If not using nonces, the GC/KS MUST check the
   timestamp in the signature payload to determine if the message is
   new.  After freshness is confirmed, the signature MUST be verified to
   ensure its authenticity.  The GC/KS MUST use verified and trusted
   authentication material from a known root.  If the message signature
   verifies, the GC/KS processes the Notification payload.  If the
   notification type is of type ACK, this is considered a successful
   processing of this message.

   If the processing of the message is successful, the GC/KS MUST remove
   the member from the group.  This MAY involve initiating a Rekey Event
   for the group.

   If the processing of the message fails or if no Departure_Ack is
   received, the GC/KS MAY issue a LOA message.



(page 45 continued on part 3)

Next RFC Part