WDIFF

draft-ietf-msec-gdoi-02.txt --> draft-ietf-msec-gdoi-03.txt

Internet Engineering Task Force Mark Baugher(Cisco)
INTERNET-DRAFT Thomas Hardjono (Verisign)
Document: draft-ietf-msec-gdoi-03.txt Hugh Harney (Sparta)
Expires: July, 2002 Brian Weis (Cisco)

November 21, 2001

January 16, 2002

The Group Domain of Interpretation

<draft-ietf-msec-gdoi-02.txt>
<draft-ietf-msec-gdoi-03.txt>

Status of this Memo

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

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 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
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document presents an ISAMKP Domain of Interpretation (DOI) for
group key management to support secure group communications. The
"GDOI" borrows definitions from GSAKMP, incorporates the definition of a Phase 1 SA of the Internet
DOI, and proposes new payloads and exchanges according to the ISAKMP
standard. The GDOI manages group security associations, which are
used by IPSEC and potentially other data security protocols running
at the IP or application layers. These security associations protect
one or more key-
encrypting key-encrypting keys, traffic-encrypting keys, or data
shared by group members.

Comments on this document should be sent to msec@securemulticast.org.

Baugher, et. al. Standards Track - Expires July, 2002 1
The GDOI Domain of Interpretation January, 2002

Table of Contents

1.0 Introduction Introduction......................................................3
1.1 GDOI Applications...............................................4
1.2 Extending GDOI..................................................5
2.0 Motivation for Using ISAKMP
2.1 Disadvantages of using ISAKMP
2.2 Advantages of using ISAMKP
2.3 Overview of IKE
2.4 Use of IKE Phase 1 as a Secure Channel
2.4.1 IKE Phase 1 SA Payload
2.4.2 Use of the IKE protocol...........................................5
2.1 DOI value.....................................................5
2. 2 UDP port. port.....................................................5
3.0 GROUPKEY-PULL Exchange Exchange............................................5
3.1 ACL-based Versus Credential-based Authorization Authorization...................................................5
3.2 Messages Messages........................................................5
3.2.1 Perfect Forward Secrecy Secrecy.....................................7
3.2.2 ISAKMP Header Initialization Initialization................................8
3.3 Initiator Operations Operations............................................8
3.4 Receiver Operations
3.5 Use of Data Security Protocols for the Secure Channel Operations.............................................9
4.0 GROUPKEY-PUSH Message Message.............................................9
4.1 Perfect Forward Secrecy (PFS) (PFS)..................................10
4.2 Forward and Backward Access Control Control............................10
4.3 Delegation of Key Management Management...................................10
4.4 Use of signature keys..........................................10
4.5 ISAKMP Header Initialization
4.5 Initialization...................................11
4.6 Deletion of SAs SAs................................................11
4.7 Initiator Operations...........................................11
4.8 Receiver Operations............................................12
5.0 Payloads and Defined Values Values......................................12
5.1 Identification Payload Payload.........................................13
5.1.1 Identification Type Values
5.1.1.1 ID_KEY_ID Values.................................13
5.2 Security Association Payload Payload...................................14
5.2.1 Payloads following the SA payload payload..........................14
5.3 SA KEK payload payload.................................................15
5.3.1 KEK Attributes Attributes.............................................17
5.3.2 KEK_MANAGEMENT_ALGORITHM KEK_MANAGEMENT_ALGORITHM...................................17
5.3.3 KEK_ALGORITHM KEK_ALGORITHM..............................................17
5.3.4 KEK_KEY_LENGTH KEK_KEY_LENGTH.............................................18
5.3.5 KEK_KEY_LIFETIME KEK_KEY_LIFETIME...........................................18
5.3.6 SIG_HASH_ALGORITHM SIG_HASH_ALGORITHM.........................................18
5.3.7 SIG_ALGORITHM SIG_ALGORITHM..............................................19
5.3.8 SIG_KEY_LENGTH SIG_KEY_LENGTH.............................................19
5.3.9 KE_OAKLEY_GROUP KE_OAKLEY_GROUP............................................19
5.4 SA TEK Payload Payload.................................................19
5.4.1 PROTO_IPSEC_ESP PROTO_IPSEC_ESP............................................20
5.4.2 Other Security Protocols Protocols...................................22
5.5 Key Download Payload Payload...........................................22
5.5.1 TEK Download Type Type..........................................23
5.5.2 KEK Download Type Type..........................................24
5.5.3 LKH
5.5.4 OFT Download Type..........................................25
5.6 Sequence Number Payload Payload........................................27

Baugher, et. al. Standards Track - Expires July, 2002 2
The GDOI Domain of Interpretation January, 2002

5.7 Proof of Possession Possession............................................27
5.8 Nonce
6.0 Application Scenarios
6.1 Data Broadcast
6.2 Video-on-demand
6.3 Summary Nonce..........................................................28
7.0 Security Considerations Considerations..........................................28
8.0 IANA Considerations Considerations..............................................28
8.1 ISAKMP DOI DOI.....................................................28
8.2 Payload Types Types..................................................28
8.3 New Namespaces Namespaces.................................................29
8.3 UDP Port.......................................................29
9.0 Acknowledgements Acknowledgements.................................................29
10.0 References References......................................................29
Authors Address:
Appendix A: Sample GDOI definitions for MESP and AMESP
A.1 SA TEK bindings
A.2 MESP/AMESP SA TEK Attributes
A.2.1 GS_ORDER
A.2.2 GS_PROTOCOL
A.2.3 GS_TRANSFORM
A.2.4 GS_TRANSFORM_KEY_LENGTH
A.2.5 GS_TRANSFORM_KEY_LIFETYPE
A.2.6 GA_ORDER
A.2.7 GA_PROTOCOL
A.2.8 GA_TRANSFORM
A.2.9 SrA_ORDER
A.2.10 SrA_PROTOCOL
A.2.11 SrA_ALGORITHM
A.3 TESLA SA TEK Attributes
A.3.1 SOURCE_ID
A.3.2 DIRECT_SYNCHRONIZATION
A.3.3 SENDERS_CERT_TYPE
A.3.4 SENDERS_CERT
A.3.5 HMAC_TYPE
A.3.6 KEY_CHAIN_PRF
A.3.7 INTERVAL_TIME
A.3.9 INTERVAL_DURATION
A.3.10 KEY_DISCLOSURE_DELAY
Appendix B: LKH Data Key Download Definitions
B.1 LKH Key Data (KD) Payload definitions
B.1.1 KEK_LKH
Appendix C: Sample GDOI Definitions for SRTP
C.1 SRTP Namespace: SA TEK Bindings
C.2 SRTP Namespace: SA TEK Attributes
C.2.1 SSRC
C.2.2 DESTINATION_ADDRESS
C.2.3 DESTINATION_RTP_PORT
C.2.4 DESTINATION_RTCP_PORT
C.2.5 ROLLOVER_COUNTER
C.2.6 CIPHER
C.2.7 CIPHER_MODE
C.2.8 CIPHER_KEY_LENGTH
C.2.9 SALT_KEY_LENGTH
C.2.10 AUTHENTICATION_ALGORITHM
C.2.11 WINDOW_SIZE
C.2.12 SRTCP_INDEX Addresses....................................................30

1.0 Introduction

This document presents an ISAMKP Domain of Interpretation (DOI) for
group key management [GKMARCH]. called the ?Group Domain of Interpretation?
(GDOI). In this group key management model, the GDOI protocol is run
between a group member and a ?group controller/key server? (GCKS),
which establishes security associations [Section 4.6.2 RFC2401] among
authorized group members. ISAKMP defines two "phases" of negotiation
[p.16 RFC2408]. The GDOI incorporates the Phase 1 SA
of security
association (SA) definition from the Internet DOI [RFC2407, RFC2409], RFC2409].
The Phase 2 exchange is defined in this document, and proposes new
payloads and exchanges according to the ISAKMP standard [p. 14 RFC2408,].
RFC2408].

There are several six new payloads:
1) GDOI SA
2) SA KEK (SAK) which follows the SA payload
3) SA TEK (SAT) which follows the SA payload
4) Key Download Array (KD, or Key Download in GSAKMP) (KD)
5) Sequence number (SEQ)
6) Proof of Possession (POP)

There are two new exchanges.

1) A Phase 2 exchange creates Category-2 or Category-3 Re-key and Data-Security Protocol SAs.

The new Phase 2 exchange, called "GROUPKEY-PULL," downloads keys for group key management (an
a group?s ?Re-key? SA and/or ?Data-security? SA. The Re-key SA that
includes a key encrypting key, or KEK, common to the group) or for group; a Data-
security protocols [Section 2.1
RFC2407], which consist of an SA that includes a data encryption key, or TEK. The SA [Section 4.6.2 RFC2401] for the KEK or TEK includes TEK, used by a data-
security protocol to encrypt or decrypt data traffic [Section 2.1
RFC2407]. The SA for the KEK or TEK includes authentication keys,
encryption keys, cryptographic policy, and
attributes specific to the data security protocol (see Appendices of
this document). attributes. The GROUPKEY-PULL GROUPKEY-
PULL exchange uses "pull" behavior since the Member member initiates the
retrieval of these SAs from a group
controller and key server ("GCKS"). The Member is aware of the Group
through some out-of-band announcement scheme (such as Session
Description Protocol) and initiates the pull. GCKS.

2) A datagram creates or modifies Category-2 and Category-3 subsequently establishes additional Rekey and/or Data-
Security Protocol SAs.

Baugher, et. al. Standards Track - Expires July, 2002 3
The GDOI Domain of Interpretation January, 2002

The GROUPKEY-PUSH datagram is "pushed" from the GCKS to the Members.
A KEK members
to create or KEK array protects the GROUPKEY-PUSH message, which creates update a
new Category-2 Re-key or Category 3 Data-security SA. A Category-2 Re-key SA
protects GROUPKEY-
PUSH messages (i.e. it contains the group KEK). A Category-3 SA is GROUPKEY-PUSH messages. Thus, a
Data Security protocol GROUPKEY-PULL is necessary
to establish at least one Re-key SA - in order to protect subsequent
GROUPKEY-PUSH messages. The GDOI passes this information sender encrypts the GROUPKEY-PUSH
message using the KEK Re-key SA. GDOI accommodates the use of arrays
of KEKs for group key management algorithms using the Logical Key
Hierarchy (LKH) algorithm to efficiently add and remove group members
[RFC2627]. Although the
particular Data Security Protocol (IPsec, SRTP, AMESP). Multiple
Category-3 SAs GROUPKEY-PUSH specified by this document can
be specified through the SAT. The GCKS or Delegate
creates each Category-3 SA with used to refresh a TEK (carried in KD) on behalf Re-key SA, the most common use of GROUPKEY-PUSH
is to establish a
Security Protocol, which secures Data-security SA for a new data session (e.g., IP
multicast file transfer). security protocol. GDOI
can accommodate future extensions to support a variety of data
security protocols. This document only specifies data-security SAs
for one security protocol, IPsec ESP. A Security Protocol separate RFC will specify
support for other data security protocols such as a future secure
Real-time Transport Protocol. A security protocol uses the TEK and
"owns" the Category-3 data-security SA in the same way that IPsec ESP uses the
IKE Phase 2 keys and owns the Phase 2 SA. When the GROUPKEY-PUSH message carries
a KEK array, it creates a new Category-2 SA. The GKCS or Delegate
creates a new Category-2 SA with a KEK array in order to add or remove
group members using a membership management protocol [RFC2627, GSAKMP,
OFT]. Alternatively, membership may expire when the KEK expires
[MARKS] and the GROUPKEY-PUSH message is not used to create Category-2
SAs SA; for GDOI, IPsec ESP uses
the particular Group. Use of LKH-style membership management
is an option in the GDOI.

The GROUPKEY-PULL exchange resembles the GSAKMP Group Establishment
procedure and gthe GROUPKEY-PUSH resembles GSAKMP Re-key [GSAKMP].
Unlike GSAKMP, TEK.

GDOI uses IKE exchanges (the the Phase 1 exchanges) exchanges defined in [RFC2409] and definitions
and
definitions. GDOI uses an IKE-compliant ISAKMP-compliant header in which from [RFC2408]. "GDOI" is the
declared domain of interpretation in the header used in the IKE Phase 1
and subsequent GDOI Phase 2 (GROUPKEY-PULL) exchanges.

Thus

Thus, GDOI is a group security association management protocol: All
GDOI messages are used to create, maintain, or delete security
associations for a group. As described above, these security
associations protect one or more key-encrypting keys, traffic-
encrypting keys, or data shared by group members.

2.0 Motivation members for Using ISAKMP multicast and
groups-security applications.

The ISAKMP protocol is keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC 2119 [RFC2119].

1.1 GDOI Applications

Secure multicast applications include video broadcast and multicast
file transfer. In a key management framework for transferring key business environment, many of these applications
require network security and authentication may use IPsec ESP to secure their data independent
traffic. Section 5.4.1 specifies how GDOI carries the needed SA
parameters for ESP. In this way, GDOI supports multicast ESP with
group authentication of ESP packets using the shared, group key generation process
[Section 1 RFC2408]. ISAKMP defines a set
(authentication of protocol exchanges that
set up a unique sources of ESP packets is not possible).

GDOI can also secure channel for key management, as well group applications that do not use multicast
transport such as video-on-demand. For example, the exchange GROUPKEY-PUSH
message may establish a pair-wise IPsec ESP SA for a member of
key and authentication data.

Generalized payloads a
subscription group without the need for exchanging key generation management exchanges and authentication
data are defined by ISAKMP. These payloads are combined with a
costly asymmetric cryptography.

Baugher, et. al. Standards Track - Expires July, 2002 4
The GDOI Domain of Interpretation (DOI), which defines the specifics of key exchange
protocol.

ISAKMP is intended to support the negotiation of SAs for Security
Protocols at January, 2002

1.2 Extending GDOI

Not all layers of the network stack, although in practice it
is commonly used at secure multicast or multimedia applications can use IPsec
ESP. Many Real Time Transport Protocol applications, for example,
require security above the network layer.

2.1 Disadvantages of using ISAKMP IP layer to preserve RTP header
compression efficiencies and transport-independence [RFC1889]. A generalized protocol such as ISAMKP has a tendency towards
complexity. This complicates
future RTP security reviews of the protocol [FS00].
Protocol complexity may also lead to implementation errors.

2.2 Advantages of benefit from using ISAMKP

The IKE protocol is GDOI to establish
group SAs for multicast and unicast security services. In order to
add a widely-deployed key exchange protocol that
supports new DOIs [Section 4 RFC2409]. It is primarily used as data security protocol, a key
exchange protocol for IPSEC, but can be used new RFC MUST specify the data-
security SA parameters conveyed by GDOI for other that security
protocols as well. IPSEC protocols have been deployed protocol;
these parameters are listed in the majority section 5.4.2 of all internetworking devices as well as end-user host products. As
IPSEC support has grown, support for the IKE this document.

2.0 ISAKMP Phase 1 protocol has proliferated

The GDOI uses ISAKMP phase 1 exchanges as well. As a measure of IPsec deployment, 70 vendors participated defined in
the IKE interoperability testing at the most recent VPN
interoperability conference.

There [RFC2409]. The
following sections define characteristics which are many advantages to making use of this existing support unique for
ISAKMP as a key management framework and IKE these
exchanges when used for the secure channel
that is our Category-1 GDOI.

2.1 DOI value

The Phase 1 SA of Figure 2:

a. Re-using much of the existing key management protocol promotes payload has a
single key management framework.

b. Systems that provide network-layer protection of unicast data will
have DOI value. That value MUST be the same market needs to provide network-layer protection for
multicast data.

c. Using the same underlying protocol will reduce both complexity and
size of the key management code.

d. Implementation can be achieved more expediently.

2.3 Overview of IKE

IKE is logically divided into two exchanges, referred to GDOI
DOI value as Phase 1
and Phase defined later in this document.

2. 2 UDP port.

GDOI MUST NOT run on port 500 (the port commonly used for IKE). A Phase 1 exchange must new
port number MUST be completed before any Phase 2
exchanges are attempted. Once defined by IANA for GDOI.

3.0 GROUPKEY-PULL Exchange

The goal of the Phase 1 GROUPKEY-PULL exchange has completed,
there is no limit to establish a Re-key
and/or Data-security SAs at the number of member for a particular group. A
Phase 2 exchanges that can take
place, and 1 SA (as defined in [RFC2407]) protects the GROUPKEY-PULL;
there may be simultaneous Phase 2 multiple GROUPKEY-PULL exchanges occurring
between IKE peers.

In Phase 1, two peers establish a bi-directional secure authenticated
channel using payloads and semantics defined in ISAKMP. Several
different authentication methods are defined for use in IKE, i.e.
manually shared keys, digital signatures, or public key encryption.
The two peers negotiate a mutually-acceptable set of cryptographic
policies, and derive keying material using given Phase 1 SA.
The GROUPKEY-PULL exchange downloads the Diffie-Hellman or
public group key encryption algorithms. At encrypting key
(KEK) or KEK array under the end protection of Phase 1, the two peers
have fully authenticated each other and have exchanged adequate keying
material used to create a secure authenticated channel for Phase 1 and
Phase 2.

In Phase 2, the SA.

3.1 Authorization

There are two peers negotiate Security Associations on behalf of
IPSEC (or other security protocols if another DOI has been defined).
IKE alternative means for authorizing the GROUPKEY-PULL
message. First, the Phase 1 provides identity can be used to authorize the following protections for any defined
Phase 2
protocol:

a. Confidentiality. All messages are protected using an encryption
protocol negotiated during Phase 1.

b. Integrity. Each message contains (GROUPKEY-PULL) request for a per-message authentication
obtained with the use of an HMAC protocol which signs hashes taken
over group key. Second, a new
identity can be passed in the Phase 2 payloads GROUPKEY-PULL request. The new
identity could be specific to the group and other relevant data.

c. Replay protection. If use a certificate that is
signed by the group owner to identify the holder as an authorized
group member. The Proof-of-Possession payload validates that the
holder possesses the secret key associated with the Phase 2 protocol uses nonces, they can
be included in the hashed data for identity.

3.2 Messages

The GROUPKEY-PULL is an Phase 2 messages.

d. Generation of key exchange protocol keying material. If the key
exchange protocol requires keying material to be generated, it can be
generated using exchange. Phase 1 computes SKEYID_a
from the DH keying material exchanged during in Phase 1.

2.4 Use SKEYID_a is the

Baugher, et. al. Standards Track - Expires July, 2002 5
The GDOI Domain of Interpretation January, 2002

"key" in the keyed hash used in the GROUPKEY-PULL HASH payloads. As
with the IKE Phase 1 as HASH payload generation [RFC 2409 section 5.5], each
GROUPKEY-PULL message hashes a Secure Channel

The secure channel uniquely defined by an IKE Phase 1 protects GDOI keying
material. It can directly provide confidentiality set of values.
Nonces permute the HASH and integrity. IKE
exchanges protect provide some protection against man-in-the middle, connection hijacking,
reflection and replay
attacks. IKE offers some Replay protection against
denial-of-service attacks as well. GDOI uses the IKE Phase 1 is important to protect the GCKS from
attacks that a new Phase 2 exchange called "GROUPKEY-PULL", which is
defined below.

2.4.1 IKE Phase 1 SA Payload key management server will attract.

The IKE Phase 1 SA payload has GROUPKEY-PULL uses nonces to guarantee "liveliness", or against
replay of a DOI value. That value MUST be the
GDOI DOI value as defined later recent GROUPKEY-PULL message. The replay attack is only
useful in this document.

2.4.2 Use the context of the IKE UDP port.

GDOI does not extend IKE, but current Phase 1. If a GROUPKEY-PULL
message is replayed based on a companion protocol to it. Therefore
the IKE previous Phase 1 exchange and GDOI ("phase 2") exchange SHOULD NOT use 1, the UDP port used by IKE. This allows a GDOI implementation HASH calculation
will fail due to be
written independent of an IKE implementation.

3.0 GROUPKEY-PULL Exchange a wrong SKEYID_a. The goal of message will fail processing
before the GROUPKEY-PULL exchange nonce is ever evaluated. In order for either peer to establish a Category-2
and/or Category-3 SAs at get
the Member for a particular Group. An IKE
Phase 1 SA protects benefit of the GROUPKEY-PULL; there may be multiple GROUPKEY-
PULL exchanges for a given Phase 1 SA. The GROUPKEY-PULL exchange
downloads replay protection it must postpone as much
processing as possible until it receives the Group key encrypting key (KEK) or KEK array under message in the
protection of protocol
that proves the Category 1 (IKE Phase 1) SA.

3.1 ACL-based Versus Credential-based Authorization

The GROUPKEY-PULL exchange supports two authorization models. If peer is live. For example, the
GCKS authorizes access to Responder MUST NOT
compute the Group KEK using shared Diffie-Hellman number (if KE payloads were
included) or install the new SAs until it receives a mechanism such as message with Nr
included properly in the HASH payload.

Nonces require an
access control List (ACL), then a single Member identity may suffice
and additional message in the GROUPKEY-PULL protocol exchange will not include additional credential
(CERT) and authentication data. If to
ensure that the GCKS uses does not add a more sophisticated
credential-based authorization mechanism, then group member until it proves
liveliness. The GROUPKEY-PULL member-initiator expects to find its
nonce, Ni, in the Member may have HASH of a
separate identity for each Group and the GROUPKEY-PULL exchange does
this securely [STS].

In ACL-based authorization, returned message. And the GCKS keeps a list of members for every
Group, and GROUPKEY-PULL
GKCS responder expects to see its nonce, Nr, in the identity HASH of a
returned message before providing group-keying material as in the Member
following exchange.

Hashes are computed as follows:
HASH(1) = prf(SKEYID_a, M-ID | Ni | ID)
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA)
HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_I ][ | POP_I ])
HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] [ | SEQ | ]
KD [ | POP_R])

POP payload is contained constructed as described in Section 5.7.
* Protected by the Phase 1 SA, encryption occurs after HDR

HDR is an ISAKMP header payload that uses the Phase 1 cookies and a
message identifier (M-ID) as in IKE
ID payload. The [RFC2409]. Note that nonces are
included in the first two exchanges, with the GCKS forwards returning only the ID
SA policy payload before liveliness is proven. The HASH payloads from
[RFC2409] prove that the Member to peer has the
authorization application program (see Figure 3) to check Phase 1 secret (SKEYID_a) and
the ACL
before nonce for the exchange identified by message id, M-ID. Once

Baugher, et. al. Standards Track - Expires July, 2002 6
The GDOI Domain of Interpretation January, 2002

liveliness is established, the last message completes the real
processing of downloading the KD payload (section 5.5) payload.

In addition to the Member. There
are no cryptographic data passed in the GROUPKEY-PULL exchange for
ACL-based Authorization beyond SA Nonce and KD HASH payloads, and nonces for
replay protection (see section 5.2).

Credential-based authorization uses public-key cryptography, which is
probably the most scalable authentication technology for key
management [SKEME]. In the credential-based authorization model, a
much smaller list of signing authorities will be kept by member-initiator
identifies the GCKS
authorization application. The Member can use up to one CERT payload
for each KEK or KEK array group it requests (through a Phase 2 wishes to join through the ISAKMP ID payload). payload.
The GCKS authenticates this identity as part of the GROUPKEY-PULL
exchange.

3.2 Messages

The GROUPKEY-PULL is an IKE Phase 2 exchange. IKE Phase 1 computes
SKEYID_a from responder informs the DH keying material exchanged in Phase 1. SKEYID_a is member of the "key" in current value of the keyed hash used
sequence number in the GROUPKEY-PULL HASH payloads.
As with SEQ payload; the IKE HASH payload generation [RFC 2409 section 5.5], each
GROUPKEY-PULL message hashes a uniquely-defined set of values. Nonces
permute sequence number orders the HASH and provide some protection against replay attacks.
Replay protection is important to protect
GROUPKEY-PUSH datagrams (section 4); the GCKS from attacks that a
key management server will attract.

The GROUPKEY-PULL uses nonces member MUST check to guarantee "liveliness", or see
that
someone is not replaying a recent GROUPKEY-PULL message. The replay
attack the sequence number is only useful greater than in the context of the current Phase 1. If a
GROUPKEY-PULL message is replayed based on a previous IKE Phase 1, the
HASH calculation will fail due to a wrong SKEYID_a. The message will
fail processing before SEQ payload
the nonce is ever evaluated. In order member holds for
either peer to get the benefit of the replay protection it must
postpone as much processing as possible until group (if it receives holds any) before installing
any new SAs . The SEQ payload MUST be present if the message
in SA payload
contains an SA KEK attribute. The GCKS responder informs the protocol that proves member
of the peer is live. For example, cryptographic policies of the
Responder MUST NOT compute group in the shared Diffie-Hellman number (if KE
payloads were included) or install SA payload, which
describes the new SAs until it receives a
message with Nr included properly in DOI, KEK and/or TEK keying material, and authentication
transforms. The SPIs are also determined by the HASH payload.

Nonces require an additional message GCKS and downloaded
in the protocol exchange to
ensure that SA payload chain (see section 5.2). The SA KEK attribute
contains the GCKS does ISAKMP cookie pair for the Re-key SA, which is not add a group member until it proves
liveliness.
negotiated but downloaded. The GROUPKEY-PULL Member-Initiator expects to find its
nonce, Ni, SA TEK attribute contains an SPI as
defined in the HASH section 5.4 of this document. The second message
downloads this SA payload. If a returned message. And the GROUPKEY-PULL
GKCS Responder expects to see its nonce, Nr, Re-key SA is defined in the HASH of a returned
message before providing Group-keying material as SA
payload, then KD will contain the KEK; if one or more Data-security
SAs are defined in the following
exchange.

Initiator (Member) Responder (GCKS)
------------------ ----------------
HDR*, HASH(1), Ni, ID -->
<-- HDR*, HASH(2), Nr, SA
HDR*, HASH(3) [,KE_I] -->
[,CERT] [,POP_I]
<-- HDR*, HASH(4), [KE_R,][SEQ,] payload, KD [,CERT] [,POP_R]
Hashes are computed as follows:
HASH(1) = prf(SKEYID_a, M-ID | Ni | ID)
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA)
HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_I ][ | POP_I ])
HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] [ | SEQ | ]
KD
[ | POP_R])
POP payload will contain the TEKs. This is constructed from prf(Ni | Nr)
* Protected by IKE Phase 1 SA, encryption occurs after HDR

HDR
useful if there is an ISAKMP header payload that uses initial set of TEKs for the Phase 1 cookies particular group
and a
message identifier (M-ID) as can obviate the need for future TEK GROUPKEY-PUSH messages
(described in IKE [RFC2409]. Note that nonces are
included section 4).

As described above, the member may establish an identity in the first two exchanges, with
GROUPKEY-PULL exchange in an optional CERT payload that is separate
from the GCKS returning only Phase 1 identity. When the
SA policy member passes a new CERT, a
proof of possession (POP) payload before liveliness is proven. accompanies it. The HASH payloads
[RFC2409] prove POP payload
demonstrates that the peer member or GCKS has used the Phase 1 very secret (SKEYID_a) and
the nonce for that
authenticates it. POP_I is an ISAKMP SIG payload containing a hash
including the exchange identified nonces Ni and Nr signed by message id, M-ID. Once
liveliness is established, the last message completes member, when the real
processing of downloading member
passes a CERT, signed by the KD payload.

In addition Group Owner to prove its authorization.
POP_R contains the Nonce and HASH payloads, hash including the Member Initiator
identifies concatenated nonces Ni and Nr
signed by the Group it wishes to join through GCKS, when the ISAKMP ID payload.
The GCKS Responder informs passes a CERT, signed by the Member of the current value group
owner, to prove its authority to provide keys for a particular group.
The use of the
sequence number in the SEQ payload; the sequence number orders the
GROUPKEY-PUSH datagrams (section 4); nonce pair for the member MUST check POP payload, transformed through a
pseudo-random function (prf) and encrypted, is designed to see that withstand
compromise of the sequence number Phase 1 key.

3.2.1 Perfect Forward Secrecy

If PFS is greater than in desired and the previous SEQ optional KE payload is used in the
member holds for the group (if
exchange, then both sides compute a DH secret and use it holds any) before installing any KEK
SA. The SEQ payload MUST be present if to protect
the SA payload contains a KEK
SA payload. new keying material contained in KD. The GCKS Responder informs the Member of responder will xor
the cryptographic
policies of DH secret with the Group in KD payload and send it to the SA payload, member
Initiator, which describes recovers the DOI, KEK
and/or TEK keying material, and authentication transforms. The SPIs
are also determined KD by the GCKS and downloaded repeating this operation as in
the SA payload chain
(see section 5.2). The KEK SA contains the Oakley IEXTKEY procedure [RFC2412].

3.2.2 ISAKMP cookie pair for the
Category-2 SA, which is not negotiated but downloaded. Header Initialization

Baugher, et. al. Standards Track - Expires July, 2002 7
The TEK SA
contains an SPI as defined in section 5.3 GDOI Domain of this document. The
second message downloads this SA payload. If a Category-2 SA is
defined in the SA payload, then KD will contain the KEK; if one or
more Category-3 SAs Interpretation January, 2002

Cookies are defined used in the SA payload, KD will contain the
TEKs. This is useful if there is an initial set ISAKMP header as a weak form of TEKs for the
particular Group and can obviate the need for future TEK GROUPKEY-PUSH
messages (described in section 4).

As described above, the Member may establish an identity in the denial of
service protection. The GDOI GROUPKEY-PULL exchange in uses cookies
according to ISAKMP [RFC2408].

Next Payload identifies an optional CERT ISAKMP or GDOI payload that (see Section 5.0).

Major Version is separate
from the Phase 1 identity. When the Member Responder passes a new
CERT, a proof of possession (POP) payload accompanies it. and Minor Version is 0 according to ISAKMP
[RFC2408, Section 3.1].

The POP
payload demonstrates that the Member or GCKS principal Exchange Type has used the
very secret that authenticates that principal (i.e., value 240 for the principal's
private key that corresponds GDOI GROUPKEY-PULL exchange.

Flags, Message ID, and Length are according to the public key used in the CERT
payload). POP_I is an ISAKMP SIG payload containing [RFC2408,
Section 3.1]

3.3 Initiator Operations

Before a hash of group member (GDOI initiator) contacts the
concatenated nonces Ni GCKS, it must
determine the group identifier and Nr signed by acceptable Phase 1 policy via an
out-of-band method such as SDP. Phase 1 is initiated using the Member, when GDOI
DOI in the Member
passes a CERT, signed by SA payload. Once Phase 1 is complete the Group Owner initiator state
machine moves to prove its authorization.
POP_R contains the hash of GDOI protocol.

To construct the concatenated nonces first GDOI message the initiator chooses Ni and Nr signed by
the GCKS, when the GCKS passes
creates a CERT, signed by nonce payload, builds an identity payload including the Group owner, to
prove its authority to provide keys for a particular Group. The use
group identifier, and generates HASH(1).

Upon receipt of the nonce pair for second GDOI message, the POP payload, transformed through initiator validates
HASH(2), extracts the IKE
prf, is designed to withstand compromise of nonce Nr, and interprets the Category 1 (IKE Phase
1) key.

3.2.1 Perfect Forward Secrecy SA payload. If PFS is desired and the optional KE
policy in the SA payload is used in acceptable (e.g., the exchange,
then both sides compute a DH secret security protocol
and use it to protect cryptographic protocols can be supported by the new
keying material contained in KD. The GCKS Responder will xor initiator), the DH
secret with
initiator continues the KD payload protocol.

If the group policy uses certificates for authorization, the
initiator generates a hash including Ni and send it to Nr and signs it. This
becomes the Member Initiator, contents of the POP payload. If necessary, a CERT payload
is constructed which
recovers holds the KD by repeating this operation as in public key corresponding to the Oakley IEXTKEY
procedure [RFC2412].

3.2.2 ISAKMP Header Initialization

Cookies are
private key used in to sign the ISAKMP header as a weak form of denial of
service protection. POP payload.

The initiator constructs the third GDOI GROUPKEY-PULL exchange uses cookies
according to ISAKMP message by including the CERT
and IKE [RFC2527, RFC2408, RFC2409].

Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0).

Major Version is 1 POP payloads (if needed) and Minor Version is 0 according to ISAKMP
[RFC2408, Section 3.1].

The Exchange Type has value 240 for creating HASH(3).

Upon receipt of the GDOI GROUPKEY-PULL exchange.

Flags, Message ID, and Length are according to ISAKMP [RFC2408,
Section 3.1]

3.3 Initiator Operations

Before an group member (GDOI initiator) contacts the GCKS, it must
determine the group identifier and acceptable IKE Phase 1 policy via a
unspecified method. IKE Phase 1 is initated using the GDOI DOI in the
SA payload. Once IKE Phase 1 is complete, the initator state machine
moves to the GDOI protocol.

To construct the first GDOI message the initiator chooses Ni and
creates a nonce payload, builds an identity payload including the
group identifer, and generates HASH(1).

Upon receipt of the second GDOI message, the initiator validates
HASH(2), extracts the nonce Nr, and interprets the SA payload. If the
policy in the SA payload is acceptable (e.g., the security protocol
and cryptographic protocols can be supported by the initator), the
initiator continutes the protocol.

If the group policy is to use certificates for authorization, the
initiator generates a hash of the Ni and Nr and signs it. This
becaomes the contents of the POP payload. If necessary, a CERT payload
is constructed which holds the public key corresponding to the private
key used to sign the POP payload.

The initator constructs the third GDOI message by including the CERT
and POP payloads (if needed) and creating HASH(3).

Upon receipt of the fourth fourth GDOI messages, the initiator validates
HASH(4). If the responder sent CERT and POP_R payloads, the POP
signature is validated.

If a SEQ payload is present, the sequence number in the SEQ payload
must be checked against any previously received sequence number for
this group. If it is less than the previously received number, it
should be considered stale and ignored. (This This could happen if two
GROUPKEY-PULL messages happened in parallel, and the sequence number
changed between the time times the results of two GROUPKEY-PULL messages
were returned from the GCKS.

Baugher, et. al. Standards Track - Expires July, 2002 8
The GDOI Domain of Interpretation January, 2002

The initiator interprets the KD key packets, matching the SPIs in the
key packets to SPIs previously sent in the SA payloads identifying
particular policy. For TEK SAs, TEKs, once the keys and policy are matched,
the initiator is ready to send or receive packets matching the TEK SA.
policy. (If policy and keys had been previously received for this
TEK SA, policy, the
initator initiator may decide instead to ignore this TEK SA
policy in case it is stale.) If this group has a KEK, the KEK policy
and keys are marked as ready for use.

3.4 Receiver Operations

The GCKS (responder) passively listens for incoming requests from
group members. The IKE Phase 1 authenticates the group member and sets up
the secure session with them.

Upon receipt of the first GDOI message the GCKS validates HASH(1),
extracts the Nr and group identifier in the ID payload. It verifies
that it's its database contains the group information for the group
identifier.

The GCKS constructs the second GDOI message, including a nonce Nr,
and the policy for the group in an SA payload, followed by SA TEK
payloads for traffic SAs, and SA KEK policy (if the group controller
will be sending rekey Re-key messages to the group).

Upon receipt of the third GDOI message the GCKS validates HASH(3). If
the initiator sent CERT and POP_I payloads, the POP signature is
validated.

The GCKS constructs the fourth GDOI message, including the SEQ
payload (if the group controller will besending GCKS sends rekey messages), the KD payload containing
keys corresponding to policy previously sent in the SA TEK and SA KEK
payloads, and the CERT and POP payloads (if needed).

3.5 Use of Data Security Protocols for the Secure Channel

The IKE Phase 1 is used as a Secure Channel for the "registration" of
a Member to a Group whereby the Member authenticates itself to the
GCKS and receives keying material. In principle, a variety of means
might be used to protect the registration and pulling of keys such as
IPSEC ESP or SSL. There are advantages to that approach, moreover, in
simplicity of implementation and robustness of operation. Web
servers, for example, support SSL, which might serve as a convenient
means of securely downloading keys from the GCKS to the Member.

There is no requirement that GROUPKEY-PULL be the means by which the
GDOI SAD is initialized. It is possible that GDOI GROUPKEY-PUSH
datagrams (described below) use keying material obtained by means
other than a GROUPKEY-PULL. The GDOI, however, does not define these
other means since it is intended to be an extension to IKE for group
key management. Although the GDOI could specify a mode of operation
for GROUPKEY-PULL other than over an IKE Phase 1 SA, this is not done
in the interests of simplicity of the specification.

4.0 GROUPKEY-PUSH Message

Following the model described in [HBH00], GDOI sends control
information securely using group communications, i.e. using IP
multicast distribution

4.0 GROUPKEY-PUSH Message

GDOI sends control information securely using group communications.
Typically this will be using IP multicast distribution of a GROUPKEY-PUSH GROUPKEY-
PUSH message (which but it can also be "pushed" using unicast delivery). delivery if IP
multicast is not possible. The GROUPKEY-PUSH message replaces a Category-2 Re-
key SA KEK or KEK array, and/or creates a new Category-3 Data-security SA (see
section 1.3).

Member GCKS or Delegate
------ ----------------

<---- HDR*, SEQ, SA, KD, [CERT,] SIG

* Protected by the Category-2 Re-key SA KEK; encryption occurs after HDR

Baugher, et. al. Standards Track - Expires July, 2002 9
The GDOI Domain of Interpretation January, 2002

HDR is defined below. The SEQ payload is defined in the Payloads
section. The SA defines the policy (e.g. crypto protection suite) and
attributes (e.g. SPI) for a Category-2 Re-key and/or Category-3 Data-security SAs. The
GCKS or
Delegate delegate optionally provides a CERT payload for verification
of the
SIG, which SIG. KD is the key download payload as described in the
Payloads section.

The SIG payload is a signature of a hash of the entire message before
encryption (including the header and excluding the SIG payload
itself). KD is
itself), prefixed with the key download payload as described string "rekey". The prefixed string
ensures that the signature of the Rekey datagram cannot be used for
any other purpose in the Payloads
section. GDOI protocol.

If the SA defines an LKH-style KEK array or single KEK, KD contains a
KEK or KEK array for a new Category-2 Re-key SA, which has a new cookie pair.
When the KD payload carries a new KEK SA KEK attribute (section 5.3), a Category-2
Re-key SA is replaced with a new SA having the same Group group identifier
(ID specified in message 1 of section 3.1) and incrementing the same
sequence counter, which is initialized in message 4 of section 3.1.
If the SA defines an SA TEK payload, this informs the member that a
new
Category-3 Data-security SA has been created, with keying material carried
in KD (Section 5.5).

4.1 Perfect Forward Secrecy (PFS)

The GROUPKEY-PUSH message is protected by the Group group KEK though in all
cases, the GROUPKEY-PUSH message carries new key downloads, among
other information. A freshly generated secret must protect the key
download for the GROUPKEY-PUSH message to have PFS. This issue is
for further study.

4.2 Forward and Backward Access Control

Through GROUPKEY-PUSH, the GDOI supports algorithms such as LKH and
OFT that
have the property of denying access to a new group key by a member
removed from the group (forward access control) and to an old group
key by a member added to the group (backward access control). An
unrelated notion to PFS, "forward access control" and "backward
access control" have been called "perfect forward security" and
"perfect backward security" in the literature [RFC2627, GSAKMP, CP00,
OFT]. [RFC2627].

4.3 Delegation of Key Management

GDOI supports delegation of GROUPKEY-PUSH datagrams through the
delegation capabilities of the PKI. However, GDOI does not explicitly
specify how the GCKS identifies delegates, but leaves this to the PKI
that is used by a particular GDOI implementation.

4.4 Use of signature keys

The GCKS SHOULD NOT use the same key to sign the SIG payload in the
GROUPKEY-PUSH message as was used for authorization in the GROUPKEY-
PULL POP payload. Doing so may contribute to an attack by a dishonest
group member where be can unwittingly cause the GCKS to sign a validly
formed GROUPKEY-PUSH message masquerading as Ni. If If the same key must be used, a different hash

Baugher, et. al. Standards Track - Expires July, 2002 10
The GDOI Domain of Interpretation January, 2002

function SHOULD be used as a base for the POP payload than is used as
a base for the SIG payload.

4.4

4.5 ISAKMP Header Initialization

Unlike ISAKMP or IKE, the cookie pair is completely determined by the
GCKS. The cookie pair in the GDOI ISAKMP header identifies the
Category-2 Re-key
SA to differentiate the secure groups managed by a GCKS. Thus, GDOI
uses the cookie fields as an SPI. Use of the cookie as an
anti-clogging token [RFC2522, RFC2408] is for further study. SPI

Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0).

Major Version is 1 and Minor Version is 0 according to ISAKMP
[RFC2408, Section 3.1].

The Exchange Type has value 241 for the GDOI GROUPKEY-PUSH message.

Flags, Message ID, and Length are according to ISAKMP [RFC2408,
Section 3.1]

4.5

4.6 Deletion of SAs

There are times the GCKS may want to signal to receivers to delete
SAs, for example at the end of a broadcast. Deletion of keys may be
accomplished by sending an ISAKMP Delete payload as part of a GDOI
GROUPKEY-PUSH message.

5.0 Payloads and Defined Values

This document specifies use

4.7 Initiator Operations

An initiator (GCKS or delegate) may initate a Rekey message for one
of several reasons, e.g. the group membership has changed or keys are
due to expire.

To begin the rekey datagram the GCKS builds an ISAKMP payloads, HDR with the
correct cookie pair, and a SEQ payload that includes a sequence
number which is one greater than the previous rekey datagram.

An SA payload is then added. This is identical in structure and
meaning to a SA payload sent in a GROUPKEY-PULL exchange. If there
are
defined changes to the KEK (in the case of a static KEK) or in accordance with RFC2408. The following payloads group
membership (in the case of LKH) an SA_KEK attribute is added to the
SA. If there are
extended one or further specified.

Next Payload Type Value
----------------- -----
Security Association (SA) 1
Identification (ID) 5
Nonce (N) 10

Several more new TEKs then SA_TEK attributes are
added to describe that policy.

A KD payload formats is then added. This is identical in structure and
meaning to a KD payload sent in a GROUPKEY-PULL exchange. If an
SA_KEK attribute was included in the SA payload then corresponding
KEK keys (or a KEK array) is included. TEK keys are required sent for each
SA_TEK attribute included in the group security
exchanges. SA payload.
The Payload types for payloads following the new headers HDR are defined in then encrypted using the
ISAKMP "Private USE" range.

Next Payload Type Value
----------------- -----
RESERVED 128 - 129
SA current
KEK Payload (SAK) 130 encryption key.

Baugher, et. al. Standards Track - Expires July, 2002 11
The GDOI Domain of Interpretation January, 2002

A CERT payload is added if the initiator needs to provide its
certificate.

Finally, the initiator hashes the string "rekey" followed by the key
management message already formed. The hash is signed, placed in a
SIG payload and added to the datagram. The datagram can now be sent.

4.8 Receiver Operations

A group member receiving the GROUPKEY-PUSH datagram matches the
cookie pair in the ISAKMP HDR to an existing SA. The message is
decrypted, and the form of the datagram is validated. This weeds out
obvious ill-formed messages (which may be sent as part of a Denial of
Service attack on the group).

The signature of the decrypted message is then validated, possibly
using the CERT payload if it is included.

The sequence number in the SEQ payload is validated to ensure that it
is greater than the previously received sequence number, and that it
fits within a window of acceptable values.

The SA and KD payloads are processed which results in a new GDOI
Rekey SA (if the SA payload included an SA_KEK attribute) and/or new
IPsec SAs being added to the system.

5.0 Payloads and Defined Values

This document specifies use of several ISAKMP payloads, which are
defined in accordance with RFC2408. The following payloads are
extended or further specified.

Next Payload Type Value
----------------- -----
Security Association (SA) 1
Identification (ID) 5
Nonce (N) 10

Several new payload formats are required in the group security
exchanges. The Payload types for the new headers are defined in the
ISAKMP "Private USE" range.

Next Payload Type Value
----------------- -----
RESERVED 128 - 129
SA KEK Payload (SAK) 130
SA TEK Payload (SAT) 131
Key Download (KD) 132
Sequence Number (SEQ) 133
Proof of Possession (POP) 134
RESERVED 135 - 200
GDOI Private Use 201 - 255

5.1 Identification Payload

The

Baugher, et. al. Standards Track - Expires July, 2002 12
The GDOI Domain of Interpretation January, 2002

5.1 Identification Payload

The Identification Payload is used to identify a group identity that
will later be associated with Security Associations for the group. A
group identity may map to a specific IP multicast group, or may
specify a more general identifier, such as one that represents a set
of related multicast streams.

The Identification Payload is defined as follows:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! RESERVE2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Identification Payload Format

The Identification Payload fields are defined as follows:

o Next Payload (1 octet) - Identifier for the payload type of
the next payload in the message. If the current payload is the last
in the message, this field will be zero (0).

o RESERVED (1 octet) - Unused, must be zero (0).

o Payload Length (2 octets) - Length, in octets, of the
identification data, including the generic header.

o Identification Type (1 octet) - Value describing the identity
information found in the Identification Data field.

o RESERVED2 (2 octets) - Unused, must be zero (0).

O Identification Data (variable length) - Value, as indicated by
the Identification Type.

5.1.1 Identification Type Values

The following table lists the assigned values for the Identification
Type field found in the Identification Payload.

ID Type Value
------- -----
RESERVED 0 - 10
ID_KEY_ID 11
RESERVED 12 - 127
Private Use 128 - 255

Baugher, et. al. Standards Track - Expires July, 2002 13
The GDOI Domain of Interpretation January, 2002

5.1.1.1 ID_KEY_ID
In the context of a GDOI ID payload, ID_KEY_ID specifies a four (4)-
octet group identifier.

5.2 Security Association Payload

The Security Association payload is defined in RFC 2408. For the
GDOI, it is used by the GCKS to assert security attributes for both
Category-2
Re-key and Category-3 SAs. In the GDOI, this payload may also be
called a GSA Payload. Data-security SAs
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! DOI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SA Attribute Next Payload ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

The Security Association Payload fields are defined as follows:

o Next Payload (1 octet) - Identifies the next payload for the
GROUPKEY-PULL or the GROUPKEY-PUSH message as defined above. The next
payload MUST NOT be a SAK Payload or SAT Payload type, but the next
non-Security Association type payload.

o RESERVED (1 octet) - Must be zero.

o Payload Length (2 octets) is the octet length of the current
payload including the generic header and all TEK and KEK payloads.

o DOI (4 octets) - Is the GDOI, which is value 196 pending
assignment by the IANA.

o SA Attribute Next Payload (1 octet) - Must be either a SAK
Payload or a SAT Payload. See section 5.3.2 for a description of
which circumstances are required for each payload type to be present.

o RESERVED (2 octets) - Must be zero.

5.2.1 Payloads following the SA payload

Payloads that define specific security association attributes for the
KEK and/or TEKs used by the group MUST follow the SA payload. How
many of each payload is dependant upon the group policy. There may be
zero or one SAK Payloads, and zero or more SAT Payloads, where either
one SAK or SAT payload MUST be present.

This latitude allows for various group policies to be accommodated.
For example if the group policy does not require the use of a
Category-2 Re-key
SA, the GCKS would not need to send a KEK an SA payload KEK attribute to the group
member since all SA updates would be performed using the
Category-1 Registration

Baugher, et. al. Standards Track - Expires July, 2002 14
The GDOI Domain of Interpretation January, 2002

SA. Alternatively, group policy might use a Category-2 Re-key SA but choose to
download a KEK to the group member only as part of the
Category-1 Registration
SA. Therefore, the KEK policy (in the SA KEK payload) attribute) would not be
necessary as part of the Category-2 Re-key SA message SA payload.

Specifying multiple SATs allows multiple sessions to be part of the
same group and multiple streams to be associated with a session
(e.g., video, audio, and text) but each with individual security
association policy.

5.3 SA KEK payload

The SA KEK (SAK) payload contains security attributes for the KEK
method for a Group group and parameters specific to the GROUPKEY-PULL
operation. The source and destination identities describe the
identities used for the GROUPKEY-PULL datagram.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol ! SRC ID Type ! SRC ID Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
!SRC ID Data Len! SRC Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST ID Type ! DST ID Port !DST ID Data Len!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! !
~ SPI ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! POP Algorithm ! POP Key Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ KEK Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

The SAK Payload fields are defined as follows:

o Next Payload (1 octet) - Identifies the next payload for the
GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid next
payload types for this message are a SAT Payload or zero to indicate
there is no SA TEK payload.

o RESERVED (1 octet) - Must be zero.

o Payload Length (2 octets) - Length of this payload, including
the KEK attributes.

o SPI (16 octets) Protocol (1 octet) - Security Parameter Index Value describing an IP protocol ID (e.g.,
UDP/TCP) for the KEK. rekey datagram.

Baugher, et. al. Standards Track - Expires July, 2002 15
The SPI
must be the ISAKMP Header cookie pair where the first 8 octets become
the "Initiator Cookie" field GDOI Domain of Interpretation January, 2002

o SRC ID Type (1 octet) - Value describing the GROUPKEY-PUSH message ISAKMP HDR,
and the second 8 octets become the "Responder Cookie" identity
information found in the same HDR.
As described above, these cookies are assigned by the GCKS.

o POP Algorithm (2 octets) - The POP payload algorithm. SRC Identification Data field. Defined
values are specified in the following table. If no POP algorithm is
defined by the KEK policy this field must be zero.

Algorithm IPSEC Identification Type Value
-------------- -----
RESERVED 0
POP_ALG_RSA 1
POP_ALG_DSS 2
POP_ALG_ECDSS 3
RESERVED 4-127
Private Use 128-255 section in the
IANA isakmpd-registry [ISAKMP-REG].

o POP Key Length SRC ID Port (2 octets) - Length Value specifying a port associated
with the source Id. A value of zero means that the POP payload key. If no
POP algorithm is defined in the KEK policy this SRC ID Port field must
should be zero. ignored.

o KEK Attributes SRC ID Data Len (1 octet) - Contains KEK policy attributes associated with
the group. The following sections describe the possible attributes.
Any or all attributes may be optional, depending on the group policy.

5.3.1 KEK Attributes

The following attributes may be present in a SAK Payload. The
attributes must follow Value specifying the format defined in ISAKMP [RFC2408] section
3.3. In length of the table, attributes that are defined as TV are marked as
Basic (B); attributes that are defined as TLV are marked
SRC Identification Data field.

o SRC Identification Data (variable length) - Value, as Variable
(V). indicated
by the SRC ID Type.

o DST ID Class Value Type
-------- ----- ----
RESERVED 0
KEK_MANAGEMENT_ALGORITHM 1 B
KEK_ALGORITHM 2 B
KEK_KEY_LENGTH 3 B
KEK_KEY_LIFETIME 4 V
SIG_HASH_ALGORITHM 5 B
SIG_ALGORITHM 6 B
SIG_KEY_LENGTH 7 B
KE_OAKLEY_GROUP 10 B

The following attributes may only be included (1 octet) - Value describing the identity
information found in a GROUPKEY-PULL
message: KEK_MANAGEMENT_ALGORITHM, KE_OAKLEY_GROUP.

5.3.2 KEK_MANAGEMENT_ALGORITHM

The KEK_MANAGEMENT_ALGORITHM class specifies the group KEK management
algorithm used to provide forward or backward access control (i.e.,
used to exclude group members). DST Identification Data field. Defined
values are specified in by the
following table.

KEK Management IPSEC Identification Type Value
------------------- -----
RESERVED 0
LKH 1
OFT 2
RESERVED 3-127
Private Use 128-255

5.3.3 KEK_ALGORITHM

The KEK_ALGORITHM class specifies the encryption algorithm using with
the KEK. Defined values are specified section in the following table.

Algorithm Type Value
-------------- -----
RESERVED 0
KEK_ALG_DES 1
KEK_ALG_3DES 2
KEK_ALG_TWOFISH 3
KEK_ALG_AES 4
RESERVED 5-127
Private Use 128-255

5.3.4 KEK_KEY_LENGTH

The KEK_KEY_LENGTH class specifies
IANA isakmpd-registry [ISAKMP-REG].

o DST ID Prot (1 octet) - Value describing an IP protocol ID
(e.g., UDP/TCP).

o DST ID Port (2 octets) - Value specifying a port associated
with the source Id.

o DST ID Data Len (1 octet) - Value specifying the KEK Algorithm key length (in
bits).

5.3.5 KEK_KEY_LIFETIME

The KEK_KEY_LIFETIME class specifies of the maximum time
DST Identification Data field.

o DST Identification Data (variable length) - Value, as indicated
by the DST ID Type.

o SPI (16 octets) - Security Parameter Index for which the
KEK is valid. KEK. The GCKS may refresh SPI
must be the KEK at any time before ISAKMP Header cookie pair where the end first 8 octets become
the "Initiator Cookie" field of the valid period. The value is a four (4) octet number defining a
valid time period GROUPKEY-PUSH message ISAKMP HDR,
and the second 8 octets become the "Responder Cookie" in seconds.

5.3.6 SIG_HASH_ALGORITHM

SIG_HASH_ALGORITHM specifies the SIG payload hash algorithm. The
following tables define same
HDR. As described above, these cookies are assigned by the algorithms for SIG_HASH_ALGORITHM. GCKS.

o POP Algorithm Type Value
-------------- -----
RESERVED 0
SIG_HASH_MD5 1
SIG_HASH_SHA1 2
RESERVED 3-127
PRIVATE USE 128-255

SIG_HASH_ALGORITHM is not required if the SIG_ALGORITHM is SIG_ALG_DSS
or SIG_ALG_ECDSS, which imply SIG_HASH_SHA1.

5.3.7 SIG_ALGORITHM (2 octets) - The SIG_ALGORITHM class specifies the SIG POP payload signature algorithm. Defined
values are specified in the following table. If no POP algorithm is
defined by the KEK policy this field must be zero.

Algorithm Type Value
-------------- -----
RESERVED 0
SIG_ALG_RSA
POP_ALG_RSA 1
SIG_ALG_DSS
POP_ALG_DSS 2
SIG_ALG_ECDSS
POP_ALG_ECDSS 3
RESERVED 4-127
Private Use 128-255

5.3.8 SIG_KEY_LENGTH

Baugher, et. al. Standards Track - Expires July, 2002 16
The SIG_KEY_LENGTH class specifies the length GDOI Domain of Interpretation January, 2002

o POP Key Length (2 octets) - Length of the SIG POP payload key.

5.3.9 KE_OAKLEY_GROUP

The KE_OAKLEY_GROUP class defines the OAKLEY Group used to compute the
PFS secret If
no POP algorithm is defined in the optional KE payload of KEK policy this field must be
zero.

o KEK Attributes - Contains KEK policy attributes associated with
the GDOI GROUPKEY-PULL
exchange. This attribute uses group. The following sections describe the values assigned to Group
Definitions in possible attributes.
Any or all attributes may be optional, depending on the IANA ipsec-registry [IPSEC-REG].

5.4 SA TEK Payload group policy.

5.3.1 KEK Attributes

The SA TEK (SAT) payload contains security following attributes for a single TEK
SA associated with may be present in a group.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 SAK Payload. The
attributes must follow the format defined in ISAKMP [RFC2408] section
3.3. In the table, attributes that are defined as TV are marked as
Basic (B); attributes that are defined as TLV are marked as Variable
(V).

ID Class Value Type
-------- ----- ----
RESERVED 0
KEK_MANAGEMENT_ALGORITHM 1 B
KEK_ALGORITHM 2 B
KEK_KEY_LENGTH 3 B
KEK_KEY_LIFETIME 4 V
SIG_HASH_ALGORITHM 5 B
SIG_ALGORITHM 6 B
SIG_KEY_LENGTH 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol-ID ! TEK Protocol-Specific Payload ~
+-+-+-+-+-+-+-+-+ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! B
KE_OAKLEY_GROUP 10 B

The SAT Payload fields are defined as follows:

o Next Payload (1 octet) - Identifies the next payload for the following attributes may only be included in a GROUPKEY-PULL or the GROUPKEY-PUSH message.
message: KEK_MANAGEMENT_ALGORITHM, KE_OAKLEY_GROUP.

5.3.2 KEK_MANAGEMENT_ALGORITHM

The only valid next
payload types for this message are another SAT Payload KEK_MANAGEMENT_ALGORITHM class specifies the group KEK management
algorithm used to provide forward or zero backward access control (i.e.,
used to
indicate there exclude group members). Defined values are no more security association attributes.

o RESERVED (1 octet) - Must be zero.

o Payload Length (2 octets) - Length of this payload, including specified in the TEK Protocol-Specific Payload.

o Protocol-ID (1 octet) -
following table.

KEK Management Type Value specifying the Security Protocol.
------------------- -----
RESERVED 0
LKH 1
RESERVED 2-127
Private Use 128-255

5.3.3 KEK_ALGORITHM

The following table defines KEK_ALGORITHM class specifies the encryption algorithm using with
the KEK. Defined values for are specified in the Security Protocol

Protocol ID following table.

Algorithm Type Value
-----------
-------------- -----
RESERVED 0
GDOI_PROTO_IPSEC_ESP

Baugher, et. al. Standards Track - Expires July, 2002 17
The GDOI Domain of Interpretation January, 2002

KEK_ALG_DES 1
GDOI_PROTO_MESP
KEK_ALG_3DES 2
GOI_PROTO_AMESP
KEK_ALG_AES 3
GDOI_PROTO_SRTP 4
RESERVED 5-127
PRIVATE USE 4-127
Private Use 128-255

o TEK Protocol-Specific Payload (variable) - Payload which
describes

5.3.3.1 KEK_ALG_DES

This algorithm specifies DES using the attributes specific Cipher Block Chaining (CBC) mode
as described in [FIPS81].

5.3.3.2 KEK_ALG_3DES

This algorithm specifies 3DES using three independent keys as described
in "Keying Option 1" in [FIPS46-3].

5.3.3.3 KEK_ALG_AES

This algorithm specifies AES as described in [FIPS197]. The mode of
operation for AES is Cipher Block Chaining (CBC) as recommended in [AES-
MODES].

5.3.4 KEK_KEY_LENGTH

The KEK_KEY_LENGTH class specifies the Protocol-ID.

5.4.1 PROTO_IPSEC_ESP KEK Algorithm key length (in
bits).

5.3.5 KEK_KEY_LIFETIME

The TEK Protocol-Specific payload KEK_KEY_LIFETIME class specifies the maximum time for ESP which the
KEK is as follows:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol ! SRC ID Type ! SRC ID Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
!SRC ID Data Len! SRC Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST ID Type ! DST ID Port !DST ID Data Len!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Transform ID ! SPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SPI ! RFC 2407 SA Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! valid. The SAT Payload fields are defined as follows:

o Protocol (1 octet) - Value describing an IP protocol ID (e.g.,
UDP/TCP). A value GCKS may refresh the KEK at any time before the end
of zero means that the SRC Id Prot field should be
ignored.

o SRC ID valid period. The value is a four (4) octet number defining a
valid time period in seconds.

5.3.6 SIG_HASH_ALGORITHM

SIG_HASH_ALGORITHM specifies the SIG payload hash algorithm. The
following tables define the algorithms for SIG_HASH_ALGORITHM.

Algorithm Type (1 octet) - Value describing
-------------- -----
RESERVED 0
SIG_HASH_MD5 1
SIG_HASH_SHA1 2
RESERVED 3-127
PRIVATE USE 128-255

SIG_HASH_ALGORITHM is not required if the identity
information found in SIG_ALGORITHM is
SIG_ALG_DSS or SIG_ALG_ECDSS, which imply SIG_HASH_SHA1.

Baugher, et. al. Standards Track - Expires July, 2002 18
The GDOI Domain of Interpretation January, 2002

5.3.7 SIG_ALGORITHM

The SIG_ALGORITHM class specifies the SRC Identification Data field. SIG payload signature
algorithm.
Defined values are specified by in the IPSEC Identification following table.
Algorithm Type section Value
-------------- -----
RESERVED 0
SIG_ALG_RSA 1
SIG_ALG_DSS 2
SIG_ALG_ECDSS 3
RESERVED 4-127
Private Use 128-255

5.3.7.1 SIG_ALG_RSA

This algorithm specifies the RSA digital signature algorithm as
described in [RSA].

5.3.7.2 SIG_ALG_DSS

This algorithm specifies the IANA
isakmpd-registry [ISAKMP-REG].

o SRC ID Port (2 octets) - Value specifying a port associated with DSS digital signature algorithm as
described in [FIPS186-2].

5.3.7.3 SIG_ALG_ECDSS

This algorithm specifies the source Id. A value Eliptic Curve digital signature algorithm
as described in [FIPS186-2].

5.3.8 SIG_KEY_LENGTH

The SIG_KEY_LENGTH class specifies the length of zero means that the SRC ID Port field should
be ignored.

o SRC ID Data Len (1 octet) - Value specifying SIG payload key.

5.3.9 KE_OAKLEY_GROUP

The KE_OAKLEY_GROUP class defines the length OAKLEY Group used to compute
the PFS secret in the optional KE payload of the
SRC Identification Data field.

o SRC Identification Data (variable length) - Value, as indicated
by GDOI GROUPKEY-PULL
exchange. This attribute uses the SRC ID Type. Set values assigned to three bytes of zero Group
Definitions in the IANA IPsec-registry [IPSEC-REG].

5.4 SA TEK Payload

The SA TEK (SAT) payload contains security attributes for multiple-source
multicast groups that use a common single
TEK for all senders. associated with a group.

Baugher, et. al. Standards Track - Expires July, 2002 19
The GDOI Domain of Interpretation January, 2002

! Protocol-ID ! TEK Protocol-Specific Payload ~
+-+-+-+-+-+-+-+-+ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

The SAT Payload fields are defined as follows:

o DST ID Type Next Payload (1 octet) - Value describing the identity
information found in Identifies the DST Identification Data field. Defined values
are specified by next payload for the IPSEC Identification Type section in
GROUPKEY-PULL or the IANA
isakmpd-registry [ISAKMP-REG]. GROUPKEY-PUSH message. The only valid next
payload types for this message are another SAT Payload or zero to
indicate there are no more security association attributes.

o DST ID Prot RESERVED (1 octet) - Value describing an IP protocol ID
(e.g., UDP/TCP). A value Must be zero.

o Payload Length (2 octets) - Length of this payload, including
the TEK Protocol-Specific Payload.

o Protocol-ID (1 octet) - Value specifying the Security Protocol.
The following table defines values for the Security Protocol

Protocol ID Value
----------- -----
RESERVED 0
GDOI_PROTO_IPSEC_ESP 1
RESERVED 2-127
PRIVATE USE 128-255

o TEK Protocol-Specific Payload (variable) - Payload which
describes the attributes specific for the Protocol-ID.

5.4.1 PROTO_IPSEC_ESP

The TEK Protocol-Specific payload for ESP is as follows:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol ! SRC ID Type ! SRC ID Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
!SRC ID Data Len! SRC Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST ID Type ! DST ID Port !DST ID Data Len!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Transform ID ! SPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SPI ! RFC 2407 SA Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

The SAT Payload fields are defined as follows:

Baugher, et. al. Standards Track - Expires July, 2002 20
The GDOI Domain of Interpretation January, 2002

o Protocol (1 octet) - Value describing an IP protocol ID (e.g.,
UDP/TCP). A value of zero means that the DST SRC Id Prot field should be
ignored.

o DST SRC ID Type (1 octet) - Value describing the identity
information found in the SRC Identification Data field. Defined
values are specified by the IPSEC Identification Type section in the
IANA isakmpd-registry [ISAKMP-REG].

o SRC ID Port (2 octets) - Value specifying a port associated
with the source Id. A value of zero means that the DST SRC ID Port field
should be ignored.

o DST SRC ID Data Len (1 octet) - Value specifying the length of the
DST
SRC Identification Data field.

o DST SRC Identification Data (variable length) - Value, as indicated
by the DST SRC ID Type.

o Transform ID (1 octet) - Value specifying which ESP transform is Set to be used. The list three bytes of zero for multiple-source
multicast groups that use a common TEK for all senders.

o DST ID Type (1 octet) - Value describing the identity
information found in the DST Identification Data field. Defined
values are specified by the IPSEC Identification Type section in the
IANA isakmpd-registry [ISAKMP-REG].

o DST ID Prot (1 octet) - Value describing an IP protocol ID
(e.g., UDP/TCP). A value of zero means that the DST Id Prot field
should be ignored.

o DST ID Port (2 octets) - Value specifying a port associated
with the source Id. A value of zero means that the DST ID Port field
should be ignored.

o DST ID Data Len (1 octet) - Value specifying the length of the
DST Identification Data field.

o DST Identification Data (variable length) - Value, as indicated
by the DST ID Type.

o Transform ID (1 octet) - Value specifying which ESP transform
is to be used. The list of valid values are defined in the IPSEC ESP
Transform Identifiers section of the IANA isakmpd-registry [ISAKMP-
REG].

o SPI (4 octets) - Security Parameter Index for ESP.

o RFC 2407 Attributes - ESP Attributes from RFC 2407 Section 4.5.
The GDOI supports all IPSEC DOI SA Attributes for PROTO_IPSEC_ESP
excluding the Group Description [RFC2407, section 4.5], which MUST
NOT be sent by a GDOI implementation and is ignored by a GDOI
implementation if received. All mandatory IPSEC DOI attributes are
mandatory in GDOI PROTO_IPSEC_ESP. The Authentication Algorithm
attribute of the IPSEC DOI is group authentication [AMESP] in GDOI.

Baugher, et. al. Standards Track - Expires July, 2002 21
The GDOI Domain of Interpretation January, 2002

5.4.2 Other Security Protocols

Besides ESP, GDOI should serve to establish SAs for secure groups
needed by other Security Protocols that operate at the transport,
application, and internetwork layers. These other Security
Protocols, however, are in the process of being developed or do not
yet exist.
MESP and AMESP are two related secure multicast protocols being
developed under the auspices of the IRTF Secure Multicast Group
[AMESP]. These Security Protocols must be defined in the context of
the GDOI.

The following information needs to be provided for a Security
Protocol to the GDOI.

o The Protocol-ID for the particular Security Protocol
o The SPI Size
o The method of SPI generation
o The transforms, attributes and keys needed by the Security
Protocol

All Security Protocols must provide the information in the bulleted
list above to guide the GDOI implementation for that protocol. If and
when the GDOI progresses on an IETF standards track, other Security
Protocols operating within its framework protocoland
will be specified in separate
standards track documents. To exemplify the structure and content of
GDOI security-protocol specifications, Appendix A contains a
specification for the SMuG Security Protocols, MESP and AMESP (see
Appendix A).
5.5 Key Download Payload

The Key Download Payload contains group keys for the Group group specified
in the SA Payload. These key download payloads can have several
security attributes applied to them based upon the security policy of
the group as defined by the associated SA Payload.

When included as part of the Category-2 Re-key SA with an optional KE payload,
The Key Download Payload will be xor'ed with the new Diffie-
Hellman Diffie-Hellman
shared secret. The xor operation will begin at the "Number of Key
Packets" field.

If the "Number of Key Packets" is zero, the group member is expected
to delete all keys associated with the ID. This type of KD payload
will only be sent by the GCKS when a group is deleted.

The Key Download Payload fields are defined as follows:

o Next Payload (1 octet) - Identifier for the payload type of
the next payload in the message. If the current payload is the last
in the message, then this field will be zero.

o RESERVED (1 octet) - Unused, set to zero.

Baugher, et. al. Standards Track - Expires July, 2002 22
The GDOI Domain of Interpretation January, 2002

o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.

o Number of Key Packets (2 octets) -- Contains the total number
of both TEK and Rekey arrays being passed in this data block.

o Key Packets
Several types of key packets are defined. Each Key Packet has
the following format.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! KD Type ! RESERVED ! KD Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SPI Size ! SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Key Packet Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

o Key Download (KD) Type (1 octet) -- Identifier for the Key
Data field of this Key Packet.

Key Download Type Value
----------------- -----
RESERVED 0
TEK 1
KEK 2
LKH 3
OFT 4
RESERVED 5-127 4-127
Private Use 128-255

"KEK" is a single key whereas LKH and OFT are arrays of key-
encrypting keys. The definition for LKH is given in the appendix. an array of key-encrypting
keys
o RESERVED (1 octet) - Unused, set to zero.

o Key Download Length (2 octets) -- Length in octets of the Key
Packet data following this field.

o SPI Size (1 octet) - Value specifying the length in octets of
the SPI as defined by the Protocol-Id.

o SPI (variable length) - Security Parameter Index which matches
a SPI previously sent in an SAK or SAT Payload.

o Key Packet Attributes (variable length) -- Contains Key
information. The format of this field is specific to the value of the
KD Type field. The following sections describe the format of each KD
Type.

5.5.1 TEK Download Type

Baugher, et. al. Standards Track - Expires July, 2002 23
The GDOI Domain of Interpretation January, 2002

The following attributes may be present in a SAT Payload. Exactly one
attribute matching each type sent in the SAT payload MUST be present.
The attributes must follow the format defined in ISAKMP [RFC2408]
section 3.3. In the table, attributes which are defined as TV are
marked as Basic (B); attributes which are defined as TLV are marked
as Variable (V).

TEK Class Value Type
--------- ----- ----
RESERVED 0
TEK_ALGORITHM_KEY 1 V
TEK_INTEGRITY_KEY 2 V
TEK_SOURCE_AUTH_KEY 3 V

If no TEK key packets are included in a Category-1 Registration KD payload, the
group member can expect to receive the TEK as part of a Category-2 Re-key SA. At
least one TEK must be included in each Category-2 Re-key KD payload. Multiple TEKs
may be included if multiple streams associated with the SA are to be
rekeyed.

5.5.1.1 TEK_ALGORITHM_KEY

The TEK_ALGORITHM_KEY class declares that the encryption key for this
SPI is contained as the Key Packet Attribute. The encryption
algorithm that will use this key was specified in the SAT payload.

DES keys will consist of 64 bits (the 56 key bits with parity bit).
Triple DES keys will be be specified as 64 bits (including parity
bits) in the order that they are to be used for encryption (e.g.,
DES_KEY1, DES_KEY2, DES_KEY3).

5.5.1.2 TEK_INTEGRITY_KEY

The TEK_INTEGRITY_KEY class declares that the integrity key for this
SPI is contained as the Key Packet Attribute. The integrity algorithm
that will use this key was specified in the SAT payload. Thus GDOI
assumes that both the symmetric encryption and integrity keys are
pushed to the Member. member. SHA keys will consist of 160 bits, and MD5 keys
will consist of 128 bits.

5.5.1.3 TEK_SOURCE_AUTH_KEY

The TEK_SOURCE_AUTH_KEY class declares that the source authentication
key for this SPI is contained in the Key Packet Attribute. The source
authentication algorithm that will use this key was specified in the
SAT payload.

5.5.2 KEK Download Type

Baugher, et. al. Standards Track - Expires July, 2002 24
The GDOI Domain of Interpretation January, 2002

The following attributes may be present in a SAK Payload. Exactly one
attribute matching each type sent in the SAK payload MUST be present.
The attributes must follow the format defined in ISAKMP [RFC2408]
section 3.3. In the table, attributes which are defined as TV are
marked as Basic (B); attributes which are defined as TLV are marked
as Variable (V).

KEK Class Value Type
--------- ----- ----
RESERVED 0
KEK_ALGORITHM_KEY 1 V
SIG_ALGORITHM_KEY 2 V

If the KEK key packet is included, there MUST be only one present in
the KD payload.

5.5.2.1 KEK_ALGORITHM_KEY

The KEK_ALGORITHM_KEY class declares the encryption key for this SPI
is contained in the Key Packet Attribute. The encryption algorithm
that will use this key was specified in the SAK payload.

If the mode of operation for the algorithm requires an Initialization
Vector (IV), an explicit IV MUST be included in the KEK_ALGORITHM_KEY
before the actual key.

5.5.2.2 SIG_ALGORITHM_KEY

The SIG_ALGORITHM_KEY class declares that the public key for this SPI
is contained in the Key Packet Attribute, which may be useful when no
public key infrastructure is available. The signature algorithm that
will use this key was specified in the SAK payload.

5.5.3 LKH Download Type

The LKH key packet is comprised of attributes representing different
leaves in the LKH key tree.

The format of those following attributes are
described used to pass an LKH KEK array in Appendix B.

5.5.4 OFT the KD
payload. The OFT key packet is comprised of attributes representing different
leaves in must follow the OFT key tree. The format of those defined in ISAKMP
[RFC2408] section 3.3. In the table, attributes which are TBD.

5.6 Sequence Number Payload

The Sequence Number Payload (SEQ) provides defined as
TV are marked as Basic (B); attributes which are defined as TLV are
marked as Variable (V).

KEK Class Value Type
--------- ----- ----
RESERVED 0
KEK_LKH 1 V

If an anti-replay protection
for GROUPKEY-PUSH messages. Its use LKH key packet is similar to the Sequence Number
field defined included in the IPsec ESP protocol [RFC2406]. KD payload, there must be
only one present.

Baugher, et. al. Standards Track - Expires July, 2002 25
The GDOI Domain of Interpretation January, 2002

5.5.3.1 KEK_LKH

This attribute consists of a header block, followed by one or more
LKH keys.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED LKH Version ! Payload Length Leaf ID ! Number of ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ LKH Keys ! Sequence Number !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ LKH Keys !
~ ~
+---------------------------------------------------------------+

The Sequence Number Payload KEK_LKH attribute fields are defined as follows:

o Next Payload LKH version (1 octet) - Identifier for Contains the payload type version of the
next payload in the message. If LKH
protocol which the current payload data is the last in
the message, then this field will be zero.

o RESERVED (1 octet) - Unused, set to zero. formatted in.

o Payload Length Leaf ID (2 octets) - Length in octets of -- This is the current
payload, including Leaf Node ID of the generic payload header. LKH
sequence contained in this Key Packet Data block.

o Sequence Number (4 of LKH Keys (2 octets) - -- This field contains a monotonically
increasing counter value for the group. It is initialized to zero by
the GCKS, and incremented in each subsequently-transmitted message.
Thus the first packet sent for a given Cat-2 SA will have a Sequence
Number number of 1. The GDOI implementation keeps a sequence counter
distinct LKH keys in this sequence.

Each LKH Key is defined as an
attribute for Cat-2 SA and increments follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH ID ! Key Type ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key Creation Date ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key expiration Date ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key Handle ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- !
! !
~ Key Data ~
+---------------------------------------------------------------+

o LKH ID (2 octets) -- This is the counter upon receipt of a
GROUPKEY-PUSH message. The current value position of this key in the sequence number must
be transmitted
binary tree structure used by LKH.

o Key Type (1 octet) -- This is the encryption algorithm for
which this key data is to group members as a part of be used. This value is specified in the Cat-1 SA SA payload.
A group member must keep a sliding receive window. The window must be
treated as in
Policy Token.

o Key Creation Date (4 octets) -- This is the ESP protocol [RFC2406] Section 3.4.3.

5.7 Proof time value of Possession when
this key data was originally generated.

Baugher, et. al. Standards Track - Expires July, 2002 26
The Proof of Possession Payload is used as part of group membership
authorization during a GDOI exchange. The Proof Domain of Possession Payload
is identical to an ISAKMP SIG payload. However, the usage Interpretation January, 2002

o Key Expiration Date (4 octets) -- This is entirely
different as the GCKS, GCKS delegate or Member signs a prf (i.e., RFC
2409 keyed MAC) of the concatenated nonces, Ni and Nr.

5.8 Nonce

The data portion of the Nonce payload (i.e., Ni_b and Nr_b included in the HASHs) MUST be a time value between 8 and 128 bytes.

6.0 Application Scenarios

This section considers two uses of GDOI
when this key is no longer valid for data broadcast and video-
on-demand applications. In these applications, a "content provider"
may be a studio, such as one of use.

o Key Handle (4 octets) -- This is the seven major U.S. movie studios, or randomly generated value
to uniquely identify a regional, national or international broadcast station. There key.

o Key Data (variable length) -- This is
also a "distributor," who the actual encryption
key data, which is dependent on the Key Type algorithm for its
format.

5.6 Sequence Number Payload

The Sequence Number Payload (SEQ) provides delivery an anti-replay protection
for GROUPKEY-PUSH messages. Its use is similar to homes and business. A
"distributor" may be a cable, telco, terrestrial broadcast network or
direct-to-home satellite operator. There are more than a dozen major
network distributors the Sequence Number
field defined in the U.S. that serve digital data to homes and
businesses. These distributors increasingly provide data services
such a multimedia stream and file delivery broadcasted to groups of
subscribers (e.g., using single source IP multicast) or delivered on
demand to a single subscriber.

A typical data broadcast may be a multicast file transfer or a stream
of a live sports event that is sent as part of a subscription or a
pay-per-view session. A typical video-on-demand application may be a
movie that is streamed or downloaded to an authenticated customer who
belongs to a subscription group, for example. IPsec ESP protocol [RFC2406].

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Sequence Number !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The customer
authentication may use a smart card, pass phrases, network
authentication, tamper-resistant software, and other means. These
means Sequence Number Payload fields are beyond defined as follows:

o Next Payload (1 octet) - Identifier for the scope payload type of this document though the ID and GID
next payload fields convey the needed authorization information in the GDOI
Phase 1 and GROUPKEY-PULL exchanges. Each application scenario message. If the current payload is
discussed the last in a separate section below.

6.1 Data Broadcast

In
the message, then this scenario, a wide-area broadcaster is sending a multicast data
feed. This feed is from a live sporting event that is streamed from field will be zero.

o RESERVED (1 octet) - Unused, set to zero.

o Payload Length (2 octets) - Length in octets of the event location. This broadcaster is also current
payload, including the content provider who
sends generic payload header.

o Sequence Number (4 octets) - This field contains a
monotonically increasing counter value for the feed, which group. It is received
initialized to zero by authorized customers of
metropolitan-area network distributors. The network distributor also
has a GCKS that acts on its behalf the GCKS, and has distributed KEKs to incremented in each
subsequently-transmitted message. Thus the
Group first packet sent for a
given Rekey SA will have a Sequence Number of customers who are authorized to receive the sporting-event
feed. Our network distributor delivers 1. The GDOI
implementation keeps a sequence counter as an attribute for the broadcast data encrypted
by Rekey
SA and increments the TEK, which is sent via IP Multicast in counter upon receipt of a GROUPKEY-PUSH
message. The customers who have the KEK or KEK array for current value of the network-
distributor's Group will sequence number must be able transmitted
to decrypt group members as a part of the GROUPKEY-PUSH messages
that contain Registration SA SA payload. A
group member must keep a sliding receive window. The window must be
treated as in the TEK for ESP protocol [RFC2406] Section 3.4.3.

5.7 Proof of Possession

The Proof of Possession Payload is used as part of group membership
authorization during a GDOI exchange. The Proof of Possession Payload

Baugher, et. al. Standards Track - Expires July, 2002 27
The GDOI Domain of Interpretation January, 2002

is identical to an ISAKMP SIG payload. However, the sporting event. In this way, usage is entirely
different.

The GCKS, GCKS delegate or member signs a prf (i.e., RFC 2409 keyed
MAC) of the network
distributor controls access to following values:
POP_HASH = prf("pop" | Ni | Nr)

The "pop" prefix ensures that the TEK by its customers independently signature of the broadcaster, who encrypts each stream once POP payload
cannot be used for re-distribution
through any number of network distributors.

At other purpose in the end GDOI protocol.

5.8 Nonce

The data portion of the data broadcast, each network distributor will have
its GCKS instruct Group members to destroy Nonce payload (i.e., Ni_b and Nr_b included
in the Category-3 SA HASHs) MUST be a value between 8 and its
TEK. This is done through a GROUPKEY-PUSH message.

6.2 Video-on-demand

In this scenario, a movie studio has mastered a movie file, and sends
it to network distributors who offer video-on-demand (VOD) service to
their customers. The content provider may choose to encrypt the file
or not. In this scenario, the network distributor has a GCKS that
acts on its behalf and has distributed KEKs to the Group of customers
who are authorized to download VOD movie files or view VOD streams.

There are many applications where the encryption needs to be unique to
the receiving device of the Group Member. So the network distributor
encrypts the file (after first decrypting it if it were previously
encrypted by the content provider). Thus the movie file is encrypted
at the point of distribution in QuickTime format, for example, in a
manner such that it can be decrypted and played by a QuickTime player.
Such a player fulfills the role of "Security Protocol" in Figure 3.
In contrast to the previous example, both the TEK and the KEK are
under the control of the network distributor owing to the need of
unique encryption of the VOD feed. The previous scenario, however,
allowed the GCKS to control the TEK and the network distributor to
control of the KEK. In some VOD applications, it may make sense for
the content provider to control the KEK and the network distributor to
control the TEK if the content provider owns the customer relationship
and the TEK is always distributed encrypted in the KEK. The use of
the KEK group secret eliminates the need for point-to-point key
establishment procedures for a 1:1 VOD session.

6.3 Summary

GDOI securely establishes keys for unicast and multicast data. As
further illustrated in the two scenaria, GDOI is suitable to manage
keys for on-demand unicast and multicast streams as well as file
download. Besides supporting 1:N and 1:1 groups, GDOI should be
effective in securing M:N applications, such as teleconferencing,
using LKH-style membership management [RFC2627]. Use of LKH-style
membership management is specified in the appendix.

7.0 Security Considerations

GDOI 128 bytes.

7.0 Security Considerations

GDOI is a security association (SA) protocol for groups of senders
and receivers. This protocol must use uses best-known practices for defense
against man-in-middle, connection hijacking, replay, reflection, and
denial-of-service (DOS) attacks. Further work is needed to establish
whether this draft version of GDOI uses best-known practices for key
management.

GDOI may inherit the problems of its ancestors, ISAKMP [RFC2408] and
Internet Key Exchange [RFC2409]. Some problems remain to be
addressed in ISAKMP and IKE [FS00]. GDOI should benefit, however,
from improvements to its ancestor protocols just as it benefits from
years of experience and work embodied in those protocols. Further work is
needed to establish whether GDOI uses ISKAMP and IKE in a good way. protocols

Of course, GDOI supports secure groups and differs from ISAKMP and
IKE in authorization, policy, SA structure, and exchanges. The SA
structure is more complex than ISAKMP and IKE. Complexity is bad for
a Security Protocol because it makes correctness analysis more
difficult than in a simpler protocol and may lead to implementation
problems. The distribution of keying material using multicast
techniques, moreover, is novel. Novelty is bad for a key management
protocol because it can contain unexpected results and problems. Further work
is needed to determine that this version of GDOI successfully employs
novel techniques such as multicast key distribution without
compromising Group security (as defined by Group policy).

8.0 IANA Considerations

8.1 ISAKMP DOI

A new ISAKMP DOI number needs to be assigned to GDOI. RFC 2407
indicates that the namespace for DOI values is in STD-2, although
that does not yet exist such as section there. The present document
is in accordance with the "Supported Security Protocols" section in
[RFC2408].

8.2 Payload Types

New ISAKMP Next Payload types need to be allocated for GDOI payload
types. No ISAKMP registry for payload types currently exists, but the
Private Use payload type namespace can be further partitioned for the
GDOI DOI. See Section 5.0 for the payloads defined in this document.

Baugher, et. al. Standards Track - Expires July, 2002 28
The GDOI Domain of Interpretation January, 2002

8.3 New Namespaces

The present document describes many new namespaces for use in the
GDOI payloads. Those may be found in subsections under Section 5.0. A
new GDOI registry should be created for these namespaces.

8.3 UDP Port
A new UDP port is required for GDOI.

9.0 Acknowledgements

The authors thank Ran Canetti, Cathy Meadows and Andrea Colegrove.
Ran has advised the authors on secure group cryptography, which has
led to changes in the exchanges and payload definitions. Cathy
identified several problems in a previous version versions of this draft, document,
including a replay attack against the proof of possession exchange,
as well as man-in-the-middle attacks which could occur if the nonce size
was not bounded. several man-in-the-middle. Andrea has contributed to the
group policy section of this draft.

10.0 References

[CP00] R. Canetti, B. Pinkas, A taxonomy

[AES-MODES] "Recommendation for Block Cipher Modes of multicast security issues,
http://www.ietf.org/internet-drafts/draft-irtf-smug-taxonomy-01.txt,
Work in Progress, August Operation",
United States of American, National Institute of Science and
Technology, NIST Special Publication 800-38A 2001 Edition, December
2001.

[FIPS46-3] "Data Encryption Standard (DES)", United States of
American, National Institute of Science and Technology, Federal
Information Processing Standard (FIPS) 46-3, October 1999.

[FIPS81] "DES Modes of Operation", United States of American,
National Institute of Science and Technology, Federal Information
Processing Standard (FIPS) 81, December 1980.

[FIPS186-2] "Digital Signature Standard (DSS)", United States of
American, National Institute of Science and Technology, Federal
Information Processing Standard (FIPS) 186-2, January 2000.

[FIPS197] "Advanced Encryption Standard (AES)", United States of
American, National Institute of Science and Technology, Federal
Information Processing Standard (FIPS) 197, November 2001.

[FS00] N. Ferguson and B. Schneier, A Cryptographic Evaluation of
IPsec, CounterPane, http://www.counterpane.com/ipsec.html.

[GKMARCH] M.Baugher, R.Canetti, L.Dondeti, Group Key Management
Architecture, http://search.ietf.org/internet-drafts/draft-ietf-msec-
gkmarch-00.txt, Work in Progress, June 2000.

[GSAKMP] H. Harney, A. Colegrove, E. Harder, U. Meth, R. Fleischer,
Group Secure Association Key Management Protocol,
http://search.ietf.org/internet-drafts/draft-ietf-msec-gsakmp-sec-
00.txt, June 2000, Work in Progress.

[HBH] H. Harney, M. Baugher, T. Hardjono, GKM Building Block: Group
Security Association (GSA) Definition,
http://www.ietf.org/internet-drafts/draft-irtf-smug-gkmbb-gsadef-
00.txt, Work in Progress 2000.

[HCBD] T. Hardjono, R. Canetti, M. Baugher, P. Dinsmore, Secure IP
Multicast: Problem areas, Framework, and Building Blocks,
http://www.ietf.org/internet-drafts/draft-irtf-smug-framework-00.txt,
Work in Progress 1999.

[IPSEC-REG] http://www.iana.org/assignments/ipsec-registry

[ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry

[MARKS] B. Briscoe, MARKS: Zero Side Effect Multicast Key Management
using Arbitrarily Revealed Key Sequences, Proceedings of NGC'99,
rbriscoe@bt.co.uk.

[AMESP] R. Canetti, P. Rohatgi, Pau-Chen Cheng, Multicast Data
Security Transformations: Requirements, Considerations, and Prominent
Choices, http://search.ietf.org/internet-drafts/draft-irtf-smug-data-
transforms.txt, Work In Progress, 2000.

[NAI] http://www.nai.com/media/pdf/products/tns/6_PGP_VPN_001.pdf

[OFT] D. Balenson, D. McGrew, A. Sherman, Key Management for Large
Dynamic Groups: One-Way Function Trees and Amortized Initialization,
http://www.ietf.org/internet-drafts/draft-balenson-groupkeymgmt-oft-
00.txt, February 1999, Work in Progress.

Baugher, et. al. Standards Track - Expires July, 2002 29
The GDOI Domain of Interpretation January, 2002

[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP:
A Transport Protocol for Real-Time Applications, January 1996.

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

[RFC2094] Harney, H., and Muckenhirn, C., "Group Key Management
Protocol (GKMP) Architecture," RFC 2094, July 1997.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.

[RFC2327] M. Handley, V. Jacobson, SDP: Session Description Protocol,
April 1998.

[RFC2367] D. McDonald, C. Metz, B. Phan, PF_KEY Key Management API,
Version 2, July 1998.

[RFC2401] S. Kent, R. Atkinson, Security Architecture for the
Internet Protocol, November 1998

[RFC2406] S. Kent, R. Atkinson, IP Encapsulating Security Payload
(ESP), November 1998.

[RFC2407] D. Piper, The Internet IP Domain of Interpretation for
ISAKMP, November 1998.

[RFC2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, Internet
Security Association and Key Management Protocol, November 1998.

[RFC2409] D. Harkins, D. Carrel, The Internet Key Exchange (IKE),
November, 1998.

[RFC2412] H. Orman, The OAKLEY Key Determination Protocol, November
1998.

[RFC2522] P. Karn, W. Simpson, Photuris: Session-Key Management
Protocol, March 1999.

[RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for
Multicast: Issues and Architectures, September 1998.

[SKEME] H. Krawczyk, SKEME: A Versatile Secure Key Exchange Mechanism
for Internet, ISOC Secure Networks and Distributed Systems Symposium,
San Diego, 1996.

[SRTP] R.Blom, E.Carrara, D.McGrew, M.Nasland, K.Norrman, D. Oran, The
Secure Real Time Transport Protocol, http://www.ietf.org/internet-
drafts/draft-ietf-avt-srtp-00.txt, February 2001, Work in Progress.

[RSA] RSA Laboratories, "PKCS #1 v2.0: RSA Encryption Standard",
October 1998.

[STS] Diffie, P. van Oorschot, M. J. Wiener, Authentication and
Authenticated Key Exchanges, Designs, Codes and Cryptography, 2, 107-
125 (1992), Kluwer Academic Publishers.

Authors Address: Addresses

Mark Baugher
Cisco Systems
5510 SW Orchid Street
Portland, OR 97219, USA

Baugher, et. al. Standards Track - Expires July, 2002 30
The GDOI Domain of Interpretation January, 2002

(503) 245-4543
mbaugher@cisco.com

Thomas Hardjono
VeriSign
401 Edgewater Place, Suite 280
Wakefield, MA 01880
Tel: 781-245-6996
Email: thardjono@verisign.com

Hugh Harney
Sparta
9861 Broken Land Parkway
Columbia, MD 21046
(410) 381-9400 x203
hh@sparta.com

Brian Weis
Cisco Systems
170 W. Tasman Drive,
San Jose, CA 95134-1706, USA
(408) 526-4796
bew@cisco.com

Appendix A: Sample GDOI definitions for MESP and AMESP

Among the Security Protocols that may use the GDOI are MESP and AMESP,
which together are a protocol framework for group secrecy, group
authentication, and group source authentication [AMESP]. This
framework is to support a variety of algorithms for source
authentication and operate at the internetwork, transport or
applications layers. The MESP and AMESP protocols do not provide
source authentication; they provide a framework for source
authentication algorithms such as TESLA, which is a group source
authentication algorithm that is suitable for transport/application
layer service. Thus, if source authentication service is desired for
MESP and AMESP, then one or more group source authentication
algorithms must be defined along with MESP and AMESP. We choose to
use TESLA for this example. As mentioned above (section 5.4.2), the
GDOI definitions for group Security Protocols such as MESP and AMESP
are to have separate documents from the GDOI document. This appendix,
therefore, offers an example for Security Protocol GDOI documents.

In the model of Figure 3, the MESP/AMESP Security Protocol
implementation invokes GDOI to establish necessary security
associations for its services. The needed information is communicated
in the SA TEK payload and MESP/AMESP SA TEK attributes. These are
defined in A.1 and A.2. MESP/AMESP, moreover, specifies source-
specific information for multicast group senders so there may be
information contained in the SA TEK that is specific to a sender. The
sender-specific information is sent in a set of Extended Attributes
that are particular to the algorithm that is used. These are defined
in A.3. In both the single-sender and multiple-sender cases, the
GROUPKEY-PUSH message containing the SA TEK payload may originate from
the GCKS or from another source such as the sender or senders to the
multicast group (section 4.3).

A.1 SA TEK bindings

A GDOI implementation must initialize the SA TEK payload information
for MESP/AMESP. The reader may refer to the SA TEK payload section
5.4 for the MESP/AMESP bindings, which follow.
o SPI size is 4 octets
o SPI is a pseudo-random number created by the GCKS

A.2 MESP/AMESP SA TEK Attributes

The following attributes may be present in an MESP/AMESP SAT Payload.
These attributes are followed by attributes for the TESLA source
authentication algorithm. The attributes must follow the format
defined in ISAKMP [RFC2408] section 3.3. In the table, attributes that
are defined as TV are marked as Basic (B); attributes that are defined
as TLV are marked as Variable (V).

ID Class Value Type
-------- ----- ----
RESERVED 0
GS_ORDER 1 B
GS_PROTOCOL 2 B
GS_XFORM_TYPE 3 B
GS_XFORM_KEY_LENGTH 4 B
GS_XFORM_KEY_LIFETIME 5 B
GA_ORDER 6 B
GA_PROTOCOL 7 B
GA_TRANSFORM 8 B
SrA_ORDER 9 B
SrA_PROTOCOL 10 B
SrA_ALGORITHM 11 B
RESERVED 12-63
AUTHENTICATION ALGORITHM 64-128
PRIVATE USE 129-255

A.2.1 GS_ORDER

This is the order in which the transform is applied relative to the
other transforms. The ordering is from outer (1) to inner. If
GS_ORDER is zero then group secrecy is not employed. If it is one
(1), then GS is the first transform applied by the receiver. If
GS_ORDER is greater than GA_ORDER and SrA_ORDER, then GS is the first
transform applied by the sender. GDOI does nothing with this ordering
beyond communicating it to the MESP/AMESP implementation across the
interface shown in Figure 3 between GDOI and the Security Protocol.

A.2.2 GS_PROTOCOL

This is set to one (1) if MESP is used or two (2) if AMESP is used.
GDOI does nothing with this layering information beyond communicating
it to the MESP/AMESP implementation across the interface shown in
Figure 3 between GDOI and the Security Protocol.

A.2.3 GS_TRANSFORM

Transform Type Value
-------------- -----
RESERVED 0
GS_XFORM_DES 1
GS_XFORM_3DES 2
GS_XFORM_TWOFISH 3
GS_XFORM_AES 4
RESERVED 5-127
Private Use 128-255

A.2.4 GS_TRANSFORM_KEY_LENGTH

The length of the key in bits.

A.2.5 GS_TRANSFORM_KEY_LIFETYPE

The GS_TRANSFORM_KEY_LIFETIME specifies the maximum time for which the
key is valid. The GCKS may refresh the key at any time before the end
of the valid period. The value is a four (4) octet number defining a
valid time period in seconds.

A.2.6 GA_ORDER

See A.2.1.

A.2.7 GA_PROTOCOL

See A.2.2.

A.2.8 GA_TRANSFORM

Transform Type Value
-------------- -----
RESERVED 0
GA_XFORM_DES_MAC 1
GA_XFORM_HMAC_MD5 2
GA_XFORM_HMAC_SHA1 3
RESERVED 4-127
Private Use 128-255

A.2.9 SrA_ORDER

See A.2.1.

A.2.10 SrA_PROTOCOL

See A.2.2.

A.2.11 SrA_ALGORITHM

Algorithm Type Value
-------------- -----
RESERVED 0
SrA_TESLA 1
RESERVED 2-127
Private Use 128-255

A.3 TESLA SA TEK Attributes

The attributes for the source authentication algorithm follow the
MESP/AMESP SA TEK attributes. These are for TESLA.

ID Class Value Type
-------- ----- ----
RESERVED 0
SOURCE_ID 64 B
DIRECT_SYNCHRONIZATION 65 B
SENDERS_CERT_TYPE 66 B
SENDERS_CERT 67 V
HMAC_TYPE 68 B
KEY_CHAIN_PRF 69 B
INTERVAL_TIME 70 V
INTERVAL_NUMBER 71 V
INTERVAL_DURATION 72 V
KEY_DISCLOSURE_DELAY 73 V
KEY_CHAIN_COMMITMENT_VALUE 74 V
KEY_CHAIN_EXPIRATION_VALUE 75 V

A.3.1 SOURCE_ID

This is 32-bit number that uniquely identifies the source.

A.3.2 DIRECT_SYNCHRONIZATION

This is set to one if Direct Synchronization is desired and zero
otherwise.

A.3.3 SENDERS_CERT_TYPE

ID Class Value Type
-------- ----- ----
RESERVED 0
X.509 1 B
SPKI 2 B
PGP 3 B
RESERVED 4-127
Private Use 128-255

A.3.4 SENDERS_CERT

This is the sender's certificate.

A.3.5 HMAC_TYPE

This is the hashed message authentication code used for TESLA
messages.

HMAC Type Value
--------- -----
RESERVED 0
TESLA_HMAC_MD5 1
TESLA_HMAC_SHA1 2
TESLA_HMAC_RIPEMD160 3
RESERVED 4-127
Private Use 128-255

A.3.6 KEY_CHAIN_PRF

The PRF used for computing the key chain.

KEY_CHAIN_PRF Value
--------- -----
RESERVED 0
TESLA_PRF_MD5 1
TESLA_PRF_SHA1 2
TESLA_PRF_RIPEMD160 3
RESERVED 4-127
Private Use 128-255

A.3.7 INTERVAL_TIME

The beginning time of the current interval.

A.3.8 INTERVAL_NUMBER

The identifier of the current interval.

A.3.9 INTERVAL_DURATION

The fixed interval of time (Tint) during which a message source sends
zero or more packets may be set once for the session or may be
dynamically changed during the session. If group policy dictates that
the time interval is to be invariant, then INTERVAL_DURATION is the
number of seconds of the time interval. If INTERVAL_DURATION is not
present, then the time interval will be dynamically set by the source
authentication protocol and may vary over the lifetime of the session.

A.3.10 KEY_DISCLOSURE_DELAY

KEY_DISCLOSURE_DELAY is the number of intervals (d) before an
authentication key is disclosed. KEY_DISCLOSURE_DELAY is used if the
number of intervals must be fixed for a given session or if the sender
chooses not to vary this interval during the session. Otherwise, if
the KEY_DISCLOSURE_DELAY attribute is not present, then the key
disclosure delay may be set dynamically by the source authentication
protocol.

A.3.11 KEY_CHAIN_COMMITMENT_VALUE

The PRF value for the start of a new key chain.

A.3.12 KEY_CHAIN_EXPIRATION_VALUE

The INTERVAL_NUMBER that will be the last interval of the current key
chain.

Appendix B: LKH Data Key Download Definitions

This section contains attribute definitions used by a GCKS to transmit
a LKH KEK array to group members. These definitions are compatible
with the GSAKMP protocol [GSAKMP].

B.1 LKH Key Data (KD) Payload definitions

The following attributes are used to pass an LKH KEK array in the KD
payload. The attributes must follow the format defined in ISAKMP
[RFC2408] section 3.3. In the table, attributes which are defined as
TV are marked as Basic (B); attributes which are defined as TLV are
marked as Variable (V).

KEK Class Value Type
--------- ----- ----
RESERVED 0
KEK_LKH 1 V

If an LKH key packet is included in the KD payload, there must be only
one present.

B.1.1 KEK_LKH

This attribute consists of a header block, followed by one or more LKH
keys.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Version ! Leaf ID ! Number of ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ LKH Keys ! !
+-+-+-+-+-+-+-+-+ LKH Keys !
~ ~
+---------------------------------------------------------------+

The KEK_LKH attribute fields are defined as follows:

o LKH version (1 octet) - Contains the version of the LKH
protocol which the data is formatted in.
o Leaf ID (2 octets) -- This is the Leaf Node ID of the LKH
sequence contained in this Key Packet Data block.
o Number of LKH Keys (2 octets) -- This value is the number of
distinct LKH keys in this sequence.

Each LKH Key is defined as follows:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH ID ! Key Type ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key Creation Date ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key expiration Date ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key Handle ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- !
! !
~ Key Data ~
+---------------------------------------------------------------+

o LKH ID (2 octets) -- This is the position of this key in the
binary tree structure used by LKH.
o Key Type (1 octet) -- This is the encryption algorithm for
which this key data is to be used. This value is specified in the
Policy Token.
o Key Creation Date (4 octets) -- This is the time value of when
this key data was originally generated.
o Key Expiration Date (4 octets) -- This is the time value of
when this key is no longer valid for use.
o Key Handle (4 octets) -- This is the randomly generated value
to uniquely identify a key.
o Key Data (variable length) -- This is the actual encryption key
data, which is dependent on the Key Type algorithm for its format.

Appendix C: Sample GDOI Definitions for SRTP

As described above, Security Protocols may use GDOI to establish their
security associations (Section 5.4.2). Designers of the security
protocol should develop a draft document that describes the
information needs of their security protocol for security association
(SA) attributes and cryptographic policy. This appendix outlines a
specification for GDOI support of SRTP [SRTP].

SRTP, Secure Real Time Transport Protocol, provides authentication,
integrity, and confidentiality services for Real Time Transport
Protocol [RFC1889]. Thus SRTP is an application-layer security
protocol that operates above the TCP/IP services (sockets) interface.
SRTP communicates with GDOI using an API [we will investigate use of
PF_KEY for IPC communication]. Through the API, SRTP requests SA
establishment and GDOI updates SRTP's security association database
(SAD) for maintenance of its cryptographic context [SRTP]. The KDC or
the SRTP sender acting on behalf of the KDC provides the cryptographic
policy and other attributes through the SA TEK payload
and SRTP SA TEK attributes.

C.1 SRTP Namespace: SA TEK Bindings

A GDOI implementation must initialize the SA TEK payload information
for SRTP. The reader may refer to the SA TEK payload section 5.4 for
the description of SA TEK bindings, which follow.
o SPI size is 2 octets
o SPI the RTP 32-bit sequence number that is sent on the wire.
The receiver(s) will immediately compute the "real" SPI as the "packet
index" of SPI + rollover-counter * 2^32 and use this value with the
SSRC and Transport address to identify the SRTP cryptographic context.
Thus, a cryptographic context is identified by the RTP packet index,
the SSRC and the Transport Address. This packet index is the first
number in a sequence of RTP packets that will use the given
cryptographic context. For a given SSRC and Transport Address, a new
cryptographic context is identified by a packet index number in which
all RTP packets that equal or exceed that packet index will use the
new cryptographic context. A compliant SRTP implementation,
therefore, must compute and check the packet index to see if it
matches a new cryptographic context for a given SSRC, Transport
Address pair. At any given time, there should be at most two
cryptographic contexts available for a given SSRC, Transport Address
pair - this is how new cryptographic contexts are installed and the
key is changed for an RTP session.

C.2 SRTP Namespace: SA TEK Attributes

The following attributes are encoded according to Section 3.3, RFC
2408 [RFC2408].

ID Class Type Length
-------- ----- ------
RESERVED 0
SSRC 1 V
DESTINATION_ADDRESS 2 V
DESTINATION_RTP_PORT 3 V
DESTINATION_RTCP_PORT 4 V
ROLLOVER_COUNTER 5 V
CIPHER 6 V
CIPHER_MODE 7 V
CIPHER_KEY_LENGTH 8 V
SALT_KEY_LENGTH 9 V
AUTHENTICATION_ALGORITHM 10 B
REPLAY_WINDOW_SIZE 11 V
SRTCP_INDEX 12 V
RESERVED 13-128

C.2.1 SSRC
A 32-bit unsigned integer that identifies the SSRC of the sender.

C.2.2 DESTINATION_ADDRESS
The network address on which RTP and RTCP packets are received and
sent.

C.2.3 DESTINATION_RTP_PORT
The port number on which RTP packets are received.

C.2.4 DESTINATION_RTCP_PORT
The port number on which RTCP packets are received and sent.

C.2.5 ROLLOVER_COUNTER
The 32-bit counter that is incremented each time the sequence number
(SRTP SPI) rolls over.

C.2.6 CIPHER
The algorithm used to encipher and decipher SRTP payloads. AES is the
default.

Algorithm Type Value
-------------- -----
RESERVED 0
AES 1
RESERVED 2-127
Private Use 128-255

C.2.7 CIPHER_MODE
The mode of the cipher used to encipher and decipher SRTP payloads.
Counter_Mode_AES is the default.

Cipher Mode Value
-------------- -----
RESERVED 0
Counter_Mode_AES 1
f8_Mode_AES 2
RESERVED 3-127
Private Use 128-255

C.2.8 CIPHER_KEY_LENGTH
The length of the encryption key. 128 is the default for AES.

C.2.9 SALT_KEY_LENGTH
The length of key used for salt. 128-bit is the default for AES
Counter Mode.

C.2.10 AUTHENTICATION_ALGORITHM
The type of authentication used for SRTP.

Authentication Value
-------------- -----
RESERVED 0
UMAC 1
RESERVED 2-127
Private Use 128-255

C.2.11 WINDOW_SIZE
Replay window size defaults to 64 when not specified.

C.2.12 SRTCP_INDEX
The value of the SRTCP index which will be used in the next SRTCP
packet.

Baugher, et. al. Standards Track - Expires July, 2002 31
----