Group Domain of Interpretation or GDOI is a cryptographic protocol for group key management. The GDOI protocol is specified in an IETF Proposed Standard, RFC 3547, and is based on Internet Security Association and Key Management Protocol (ISAKMP), RFC 2408, and Internet Key Exchange version 1 (IKE). Whereas IKE is run between two peers to establish a "pair-wise security association", GDOI protocol is run between a group member and a "group controller/key server" (controller) and establishes a security association among two or more group members.
Contents |
GDOI "interprets" IKE or ISAKMP for the group security domain in addition to pair-wise security associations. GDOI uses an IKE v1 Phase 1 security association for authenticating a GDOI member to a GDOI controller. The IKE/GDOI Phase 1 cryptographic protocol exchange protects a new type of Phase 2 exchange in which the member requests ("pulls") group state from the controller. The "group key" is the most important state in a GDOI member. The group key encrypts keys that decrypt application data. Thus, the group key is also called a "key encrypting key" in GDOI. A group's key-encrypting key is used for the "Rekey Security Association". Once the "Rekey-SA" is established, the GDOI controller can send ("push") unsolicited updates to the group security association to members over multicast, broadcast or unicast channels. This is why GDOI is called a "multicast key management system" as it uses and supports multicast messaging for very large groups. These multicast messages are unsolicited messages and are therefore called "push" messages, which are unsolicited messages sent from the controller to the members; explicit requests from a member to a controller are called "pull" messages in GDOI. Thus GDOI group key updates are pushed and can reach any number of group members with a single efficient transmission from the controller.
GDOI group key updates also serve to remove members from groups. RFC 2627 describes one Group Membership Management protocol that allows selective key updates to members to efficiently remove a member from the group. "Efficiency" is evaluated in terms of space, time and message complexity. RFC 2627 and other algorithms such as "subset-difference" are logarithmic in space, time and message complexity. Thus, RFC 2627 supports efficient group "membership management" for GDOI. In a practical implementation, GDOI group membership management is a separate function that the controller or a AAA function invokes to remove a de-authorized group member. "AAA" is authorization, authentication and accounting, which might run some kind of AAA protocol. But the AAA function could also be a "customer care" function for a service provider or a "subscriber management system" for a media services provider. The provider or AAA function must have a credential infrastructure such as a Public Key Infrastructure using X.509 digital certificates, SPKI or some other credential. In an X.509 environment, the provider or AAA function will install a certificate to allow a member to join a group when the Group Controller queries the PKI during a GDOI Registration exchange when a member attempts to join a group and "pull down" the group state.
The group state that is stored in the group member are keys and key metadata. Conceptually, the group member's keys are structured in a set of 1:N relationships and often called a "key ladder". The member has a credential such as an X.509 certificate that proves it is authorized to join one or more groups. The default group policy for the "Private Authentication Key" is a 2048-bit RSA key, but other policies are possible. Similarly, the default "group key" or "Key Encrypting Key" is a 128-bit AES key, but other policies are possible. Finally, the data encryption key is application-dependent but is commonly a 128-bit AES key. In some groups, a member can be a sender that generates a data encryption key and encrypts it with the key encrypting key. So long as the two share the group key for the same group, the sender can use that "key encrypting key" to encrypt the key(s) for the media files or streams that it serves.
Not all GDOI groups make a distinction between sender and receiver, however, and whether or not group members may send to each other is a matter of group policy. The type of keys in the key ladder are also determined by group policy. Each group can have its own policy for cryptography, key lifetime, and member behavior.
http://www.faqs.org/rfcs/rfc4534.html
http://www.cisco.com/en/US/products/ps7180/index.html
RFC 3547