INTERNET DRAFT January 2001
Internet Research Task Force Mark Baugher(PassEdge)
INTERNET-DRAFT Thomas Hardjono (Nortel)
Hugh Harney (Sparta)
Brian Weis (Cisco)
January 4, 2001
Group Domain of Interpretation for ISAKMP
<draft-irtf-smug-gdoi-01.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 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 ISAKMP Domain of Interpretation (DOI) for
secure group communications. The "GDOI," or "Group ISAKMP," borrows
definitions from GSAKMP [HH], incorporates the Phase 1 SA of the
Internet DOI [RFC2407, RFC2409], and proposes new payloads and
exchanges according to the ISAKMP standard [RFC2408, p.14]. Group
ISAKMP manages group security associations, which are used by security
protocols running at the IP [RFC2406] or application layers [AMESP].
These security associations protect one or more key-encrypting keys,
traffic-encrypting keys, or data shared by group members.
Comments on this document should be addressed to smug@cs.umass.edu.
Baugher, Hardjono, Harney, Weis [PAGE 1]
INTERNET DRAFT January 2001
Table of Contents
1.0 Introduction....................................................4
1.1 SMuG Framework and Building Blocks............................4
1.2 The GKM Building Block........................................5
1.3 Exchanges & Payloads..........................................6
1.4 Functional Block Diagram......................................7
2.0 Motivation for Using ISAKMP.....................................8
2.1 Disadvantages of using ISAKMP.................................9
2.2 Advantages of using ISAKMP....................................9
2.3 Overview of IKE..............................................10
2.4 Use of IKE Phase 1 as a Secure Channel.......................10
3.0 GROUPKEY-PULL Exchange.........................................11
3.1 ACL-based Versus Credential-based Authorization..............11
3.2 Messages.....................................................12
3.2.1 Perfect Forward Secrecy..................................13
3.2.2 ISAKMP Header Initialization.............................14
3.3 Use of Data Security Protocols for the Secure Channel........14
4.0 GROUPKEY-PUSH Message..........................................14
4.1 Perfect Forward Secrecy (PFS)................................15
4.2 Forward and Backward Access Control..........................15
4.3 Delegation of Key Management.................................15
4.4 ISAKMP Header Initialization.................................16
5.0 Payloads and Defined Values....................................16
5.1 Identification Payload.......................................17
5.1.1 ID_KEY_ID................................................17
5.2 Security Association Payload.................................17
5.2.1 Payloads following the SA payload........................18
5.3 SA KEK payload...............................................18
5.3.1 KEK Attributes...........................................20
5.3.2 KEK_MANAGEMENT_ALGORITHM.................................20
5.3.3 KEK_ALGORITHM............................................20
5.3.4 KEK_KEY_LENGTH...........................................21
5.3.5 KEK_KEY_LIFETIME.........................................21
5.3.6 SIG_HASH_ALGORITHM.......................................21
5.3.7 SIG_ALGORITHM............................................21
5.3.8 SIG_KEY_LENGTH...........................................22
5.3.9 KE_OAKLEY_GROUP..........................................22
5.4 SA TEK Payload...............................................22
5.4.1 PROTO_IPSEC_ESP..........................................23
5.4.2 Other Security Protocols.................................24
5.5 Key Download Payload.........................................25
5.5.1 TEK Download Type........................................27
5.5.2 KEK Download Type........................................28
5.5.3 LKH......................................................28
5.5.4 OFT......................................................28
5.6 Sequence Number Payload......................................29
5.7 Proof of Possession..........................................29
6.0 Application Scenarios..........................................30
Baugher, Hardjono, Harney, Weis [PAGE 2]
INTERNET DRAFT January 2001
6.1 Data Broadcast...............................................30
6.2 Video-on-demand..............................................31
6.3 Summary......................................................31
7.0 Security Considerations........................................31
8.0 Acknowledgements...............................................32
9.0 References.....................................................32
Authors Address:...................................................34
Appendix A: Sample GDOI definitions for MESP and AMESP.............35
A.1 SA TEK bindings................................................35
A.2 MESP/AMESP SA TEK Attributes...................................35
A.2.1 GS_ORDER...................................................36
A.2.2 GS_PROTOCOL................................................36
A.2.3 GS_TRANSFORM...............................................37
A.2.4 GS_TRANSFORM_KEY_LENGTH....................................37
A.2.5 GS_TRANSFORM_KEY_LIFETYPE..................................37
A.2.6 GA_ORDER...................................................37
A.2.7 GA_PROTOCOL................................................37
A.2.8 GA_TRANSFORM...............................................37
A.2.9 SrA_ORDER..................................................37
A.2.10 SrA_PROTOCOL..............................................37
A.2.11 SrA_ALGORITHM.............................................38
A.3 TESLA SA TEK Attributes........................................38
A.3.1 SOURCE_ID..................................................38
A.3.2 DIRECT_SYNCHRONIZATION.....................................38
A.3.3 SENDERS_CERT_TYPE..........................................38
A.3.4 SENDERS_CERT...............................................39
A.3.5 HMAC_TYPE..................................................39
A.3.6 KEY_CHAIN_PRF..............................................39
A.3.7 INTERVAL_TIME..............................................39
A.3.9 INTERVAL_DURATION..........................................39
A.3.10 KEY_DISCLOSURE_DELAY......................................40
Appendix B: LKH Data Key Download Definitions......................40
B.1 LKH Key Data (KD) Payload definitions..........................40
B.1.1 KEK_LKH....................................................40
Baugher, Hardjono, Harney, Weis [PAGE 3]
INTERNET DRAFT January 2001
1.0 Introduction
Sections 1.1 through 1.4 of this memo provide background and overview
material for Group ISAKMP.
1.1 SMuG Framework and Building Blocks
+----------------------------------------------------------------+
| CENTRALIZED \ DISTRIBUTED |
| DESIGNS \ DESIGNS |
| \ |
| \ |
| +------+ \ +------+ |
| Problem |Policy|<-------\---------------------->|Policy| |
| Area 1 |Server| \ |Server| |
| +------+ \ +------+ |
| ^ \ ^ |
| | \ | |
| | \ | |
| v \ v |
| +------+ \ +------+ |
| |Group |<-------------- \-------------> |Group | |
| Problem |Ctrl/ |<---------+ \ |Ctlr/ | |
| Area 2 |Key | | \ |Key | |
| |Server| V \ |Server| |
| +------+ +--------+ \ +------+ |
| ^ | | \ ^ |
| | |Receiver| \ | |
| | | | | | |
| v +--------+ | | |
| +------+ ^ | V |
| | | | | +--------+ |
| Problem |Sender|<---------+ | | | |
| Area 1 | |<--------------------- |------>|Receiver| |
| | | | | | |
| +------+ | +--------+ |
+----------------------------------------------------------------+
FIGURE 1: IRTF SMuG Secure Group Reference Framework
Figure 1 shows the IRTF Secure Multicast Group Reference Framework of
functional entities and the interfaces between them [HCBD]. These
entities and interfaces implement a secure group, which is defined as a
group of principals that share a secret. Secure groups are needed by
unicast applications as well as multicast applications (single-source
and multiple-source, see section 6). With respect to Figure 1, the
current work falls under the Key Management Problem Area (Problem Area
2) of the SMuG Framework document. The framework of Figure 1
identifies three group key management entities, namely the "Group
Baugher, Hardjono, Harney, Weis [PAGE 4]
INTERNET DRAFT January 2001
Controller and Key Server" (GCKS) and two types of Members ("Receiver"
and "Sender"). The GCKS entity embodies both the physical entity and
functions of the group controller and the key server [RFC2093, RFC2094,
RFC2627, OFT]. The Member belongs to one or more groups and may exist
at different layers (e.g. user, host, process).
1.2 The GKM Building Block
The GDOI security model uses a Group Security Association (GSA). An SA
is shared state between a Member and GCKS or among Members; this shared
state is a key and its policy and attributes. The GSA is an
aggregation of three types of SAs called Category-1 SA, Category-2 SA
and Category-3 SA [HBH]. This is shown in Figure 2.
+------------------------------------------------------------+
| |
| +------------------+ |
| | | |
| | GCKS | |
| | SA1 SA1 | |
| | / SA2 \ | |
| +---/-----|----\---+ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| +-------------/------+ | +------\-------------+ |
| | SA1 | | | SA1 | |
| | SA2-----+----SA2 | |
| | MEMBER SENDER | | MEMBER RECEIVER | |
| | SA3----------SA3 | |
| +--------------------+ +--------------------+ |
| |
| |
+------------------------------------------------------------+
Figure 2: GKM-BB GSA Structure and 3 Categories of SAs
The Category-1 SA protects the establishment of the Category-2 SA
keying material, policy, and attributes. The Category-1 SA is an IKE
Phase 1 SA for (bi-directional) unicast communications between the GCKS
and a particular Group Member (be it a Sender or Receiver).
The Category-2 SA protects the Category-3 SA keying material, policy,
and attributes. The Category-2 SA keying material is a key encrypting
key (KEK) or array of KEKs [RFC2093, RFC2094]. Readers familiar with
the LKH or OFT algorithms will recognize that the KEK array may be part
of a tree, which is a path from a leaf (representing a Member of a
Group) to the root [RFC2627, HH, OFT]. The GCKS or its delegate
Baugher, Hardjono, Harney, Weis [PAGE 5]
INTERNET DRAFT January 2001
creates new Category-2 SAs for the purposes of adding or removing
members to a LKH or OFT [RFC2627, OFT], or it is used to refresh an SA
prior to the expiration of its lifetime. As such, the Category-2 SA is
not negotiated, but pre-determined and initialized securely from the
GCKS to the relevant members.
The Category-3 SA protects the data of a Security Protocol (see section
1.4). Like the Category-2 SA, this SA is not negotiated and is
delivered securely from the GCKS (or delegated principal) to the
members. The Category-3 keying material is a "Traffic Encrypting Key"
(TEK), which protects the transmission of data messages
(unidirectional) from the Sender to other group members.
The Category-3 SA is the object of Group ISAKMP key management
procedures, which ultimately establish a TEK that protects unicast or
multicast data at the internetwork or application layers. Group ISAKMP
procedures, moreover, use multicast delivery only as an option as all
keying material may be delivered to members over the Category-1 as an
option (sections 5.2 and 5.3).
1.3 Exchanges & Payloads
Group ISAKMP adapts some GSAKMP exchanges and payload definitions to
ISAKMP and specializes the Security Association structure.
There are several 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)
5) Sequence number (SEQ)
6) Proof of Possession (POP)
There are two new exchanges.
1) A Phase 2 exchange creates Category-2 and Category-3 SAs.
The new Phase 2 exchange, called "GROUPKEY-PULL," downloads KEK
and/or TEK keying material, policy, and attributes for the Group
Member. The GROUPKEY-PULL exchange uses "pull" behavior since the
Member initiates the retrieval of these parameters from the GCKS. The
Member is aware of the Group through some announcement scheme (such as
SDP, see 1.4) and initiates the pull.
2) A datagram creates or modifies Category-2 and Category-3 SAs.
The GROUPKEY-PUSH datagram is "pushed" from the GCKS to the Members.
The KEK or KEK array protects the GROUPKEY-PUSH message, which creates
a new Category-3 or Category-2 SA. When the GROUPKEY-PUSH carries a
Baugher, Hardjono, Harney, Weis [PAGE 6]
INTERNET DRAFT January 2001
TEK, it creates a new Category-3 SA. Multiple Category-3 SAs can be
specified through the SAT. The GCKS or Delegate creates each Category-
3 SA with a TEK (carried in KD) on behalf of a Security Protocol, which
secures a new data session (e.g., IP multicast file transfer). A
Security Protocol uses the TEK and "owns" the Category-3 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 [RFC2627, HH, OFT].
Alternatively, membership may expire when the KEK expires [MARKS] and
the GROUPKEY-PUSH message is not used to create Category-2 SAs for the
particular Group. Use of LKH-style membership management is an option
in the GDOI.
1.4 Functional Block Diagram
+----------------------------------------------------------+
| |
| +-------------+ +------------+ |
| |AUTHORIZATION| |ANNOUNCEMENT| |
| +------^------+ +------|-----+ +--------+ |
| | | +---->| CERTS | |
| | | | +--------+ |
| +----v----+ +----v--v-+ +--------+ |
| | | | |<->| SAD | |
| | GDOI <-------------> GDOI | +--------+ |
| | | | | +--------+ |
| | ------+ | |<->| SPD | |
| +---------+ | +-^-------+ +--------+ |
| +--------+ | | | | |
| | CERTS |----->+ | | +-------------------+ |
| +--------+ | | +--------------------+ | |
| +--------+ | +-V-------+ +--------+ | | |
| | SAD <----->+ | |<->| SAD <-+ | |
| +--------+ | |SECURITY | +--------+ | |
| +--------+ | |PROTOCOL | +--------+ | |
| | SPD <----->+ | |<->| SPD <----+ |
| +--------+ +---------+ +--------+ |
| |
| (A) GCKS (B) MEMBER |
+----------------------------------------------------------+
Figure 3: GDOI Functional Block Diagram
As described in the previous section, Group ISAKMP is a group security
association (GSA) management protocol [HBH] run between the GCKS and
Member principals. The GKCS may use a delegated principal, which has a
CERT signed by the GCKS. Figure 3 shows the functional block diagram
(FBD) of the GCKS and Member for the GDOI. Members may be senders or
Baugher, Hardjono, Harney, Weis [PAGE 7]
INTERNET DRAFT January 2001
receivers of multicast data [HCBD]. There are two functional blocks in
Figure 3 labeled "GDOI," and there is an arc between them depicting the
Group ISAKMP message exchange. The message exchange is the GSA
establishment protocol, the subject of this document.
Figure 3 shows that a complete Group ISAKMP functional specification
includes much more than the message exchange. Some of these functional
blocks and the arcs between them are peculiar to an operating system
(OS) or vendor product, such as vendor specifications for products that
support updates to the IPSec [RFC2401] Security Association Database
(SAD) and Security Policy Database (SPD) [e.g., NAI, see also RFC2367].
Various vendors also define the functions and interface of certificate
stores, "CERTS" in Figure 3. AUTHORIZATION is subject to Group Policy
[HH], but how this is done is specific to the GCKS implementation;
Group ISAKMP supports alternative authorization designs, as described
in Section 3.
Beside the AUTHORIZATION block in Figure 3, there is an ANNOUNCEMENT
block. The announcement function is how a Member receives announcements
of secure groups and sessions. Session Description Protocol (SDP) is
one form that the announcements might take [RFC2327]. The announcement
function may be implemented in a session-directory tool, an electronic
program guide (EPG), or by other means. The announcement function
directs Group ISAKMP using an application-programming interface (API),
which is peculiar to the host OS in its specifics. A generic API for
Group ISAKMP is for further study, but this function is necessary to
allow Group (KEK) and Session (TEK) key establishment to be done in a
way that is scalable to the particular application. A GCKS application
program will use the API to initiate the procedures described in
Sections 3, 4 and 5 of this document in which members join secure
groups and receive session keys.
The goal of the exchanges described in Sections 3 and 4 is to establish
a GSA through updates to the SAD and SPD of a GDOI implementation and a
particular Security Protocol. The "Security Protocol" of Figure 3 may
span internetwork and application layers [AMESP] or simply use IPSec,
such as the Encapsulating Security Payload, ESP [RFC2406]. Group
ISAKMP should support updates to an IPSec SAD for the purposes of
keying ESP [RFC2406]. Section 6 considers how Group ISAKMP may be used
to establish a GSA in different Group environments.
Section 7 discusses the Security Considerations of Group ISAKMP. The
appendices describe support for specific multicast Security Protocols
and algorithms.
2.0 Motivation for Using ISAKMP
The ISAKMP protocol [RFC2408] is a key management framework for
Baugher, Hardjono, Harney, Weis [PAGE 8]
INTERNET DRAFT January 2001
transferring key and authentication data independent of the key
generation process. ISAKMP defines a set of protocol exchanges that set
up a secure channel for key management, as well as the exchange of key
and authentication data.
Generalized payloads for exchanging key generation and authentication
data are defined by ISAKMP. These payloads are combined with a 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 all layers of the network stack, although in practice it
is commonly used at the network layer.
2.1 Disadvantages of using ISAKMP
A generalized protocol such as ISAKMP has a tendency towards
complexity. This complicates security reviews of the protocol [FS00].
Protocol complexity may also lead to implementation errors.
2.2 Advantages of using ISAKMP
The IKE protocol [RFC2409] is a widely-deployed key exchange protocol
based upon the ISAKMP. It is primarily used as a key exchange protocol
for IPSEC, but can be used for other security protocols as well.
IPSEC protocols have been deployed in the majority of all
internetworking devices as well as end-user host products. As IPSEC
support has grown, support for the IKE protocol has proliferated as
well. As a measure of IPSec deployment, 70 vendors participated in the
IKE interoperability testing at the most recent VPN interoperability
conference.
There are many advantages to making use of this existing support for
ISAKMP as a key management framework and IKE for the secure channel
that is our Category-1 SA of Figure 2:
a. Re-using much of the existing key management protocol promotes a
single key management framework.
b. Systems that provide network-layer protection of unicast data will
have 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.
Baugher, Hardjono, Harney, Weis [PAGE 9]
INTERNET DRAFT January 2001
2.3 Overview of IKE
IKE is logically divided into two exchanges, referred to as Phase 1 and
Phase 2. A Phase 1 exchange must be completed before any Phase 2
exchanges are attempted. Once the Phase 1 exchange has completed, there
is no limit to the number of Phase 2 exchanges that can take place, and
there may be simultaneous Phase 2 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 the Diffie-Hellman or public
key encryption algorithms. At the end 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 two peers negotiate Security Associations on behalf of
IPSEC (or other security protocols if another DOI has been defined).
IKE Phase 1 provides 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 a per-message authentication
obtained with the use of an HMAC protocol which signs hashes taken over
the Phase 2 payloads and other relevant data.
c. Replay protection. If the Phase 2 protocol uses nonces, they can
be included in the hashed data for 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 the keying material exchanged during Phase 1.
2.4 Use of IKE Phase 1 as a Secure Channel
The secure channel defined by an IKE Phase 1 protects GDOI keying
material. It can directly provide confidentiality and integrity. IKE
exchanges protect against man-in-the middle, connection hijacking,
reflection and replay attacks. IKE offers some protection against
denial-of-service attacks as well. Group ISAKMP uses the IKE Phase 1 to
protect a new Phase 2 exchange called "GROUPKEY-PULL", which is defined
below.
Baugher, Hardjono, Harney, Weis [PAGE 10]
INTERNET DRAFT January 2001
3.0 GROUPKEY-PULL Exchange
The goal of the GROUPKEY-PULL exchange is to establish a Category-2
and/or Category-3 SAs at the Member for a particular Group (see Figure
2). An IKE Phase 1 SA protects the GROUPKEY-PULL; there may be
multiple GROUPKEY-PULL exchanges for a given Phase 1 SA. The GROUPKEY-
PULL exchange downloads the Group key encrypting key (KEK) or KEK array
under the protection of the Category 1 (IKE Phase 1) SA.
The level of security of the GROUPKEY-PULL exchange is particular to a
Group beyond some base level of protection offered by ISAKMP. Some
Group policies may dictate that the GROUPKEY-PULL exchange has perfect
forward secrecy, or PFS [DVW92], a particular crypto-suite, or a
particular authentication mechanism, etc. Thus the GROUPKEY-PULL
exchange supports optional parameters for PFS (KE payload) and policy
(SA payload).
3.1 ACL-based Versus Credential-based Authorization
The GROUPKEY-PULL exchange supports two authorization models. If the
GCKS authorizes access to the Group KEK using a mechanism such as an
access control List (ACL), then a single Member identity may suffice
and the GROUPKEY-PULL exchange will not include additional certificate
(CERT) and authentication data. If the GCKS uses a more sophisticated
credential-based authorization mechanism, then the Member may have a
separate identity for each Group and the GROUPKEY-PULL exchange
does this securely [DVW92].
In ACL-based authorization, the GCKS keeps a list of members for every
Group, and the identity of the Member is contained in the Phase 1 IKE
ID payload. The GCKS forwards the ID payloads from the Member to the
authorization application program (see Figure 3) to check the ACL
before downloading the KD payload (section 5.5) to the Member. There
are no cryptographic data passed in the GROUPKEY-PULL exchange for ACL-
based Authorization beyond SA and KD 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
[Kraw96]. The public key infrastructure (PKI) eliminates the need, for
example, to keep lists of potentially large populations of users. In
the credential-based authorization model, a much smaller list of
signing authorities will be kept by the GCKS authorization application.
The Member can use up to one CERT payload for each KEK or KEK array it
requests (through a Phase 2 ID payload). The GCKS authenticates this
identity as part of the GROUPKEY-PULL exchange.
Baugher, Hardjono, Harney, Weis [PAGE 11]
INTERNET DRAFT January 2001
3.2 Messages
The GROUPKEY-PULL uses many IKE definitions. IKE phase 1 computes
SKEYID_a for use in authenticating subsequent exchanges from the DH
keying material exchanged in Phase 1. SKEYID_a is the "key" in the
keyed hash used in the GROUPKEY-PULL HASH payloads. As with the IKE
HASH payload generation [RFC 2409 section 5.5], each GROUPKEY-PULL
message hashes a uniquely-defined set of values. Nonces permute the
HASH and provide some protection against replay attacks. Replay
protection is important to protect the GCKS from attacks that a key
management server will attract.
The GROUPKEY-PULL uses nonces to guarantee "liveliness", or that
someone is not replaying a recent GROUPKEY-PULL message. The replay
attack is only useful 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 the nonce is ever evaluated. In order for
either peer to get the benefit of the replay protection it must
postpone as much processing as possible until it receives the message
in the protocol that proves the peer is live. For example, the
Responder must not compute the shared Diffie-Hellman number (if KE
payloads were included) or install the new SAs until it receives a
message with Nr included properly in the HASH payload.
Nonces require an additional message in the protocol exchange to ensure
that the GCKS does not add a group member until it proves liveliness.
The GROUPKEY-PULL Member-Initiator expects to find its nonce, Ni, in
the HASH of a returned message. And the GROUPKEY-PULL GKCS Responder
expects to see its nonce, Nr, in the HASH of a returned message before
providing Group-keying material as 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,
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 is constructed from prf(Ni | Nr)
* Protected by IKE Phase 1 SA, encryption occurs after HDR
Baugher, Hardjono, Harney, Weis [PAGE 12]
INTERNET DRAFT January 2001
HDR is an ISAKMP header payload that uses the Phase 1 cookies and a
message identifier (M-ID) as in IKE [RFC2409]. Note that nonces are
included in the first two exchanges, with the GCKS returning only the
SA policy payload before liveliness is proven. The HASH payloads
[RFC2409] prove that the peer has the Phase 1 secret (SKEYID_a) and the
nonce for the exchange identified by message id, M-ID. Once liveliness
is established, the last message completes the real processing of
downloading the KD payload.
In addition to the Nonce and HASH payloads, the Member Initiator
identifies the Group it wishes to join through the ISAKMP ID payload.
The GCKS Responder informs the Member of the current value of the
sequence number in the SEQ payload; the sequence number orders the
GROUPKEY-PUSH datagrams (section 4). The GCKS Responder informs the
Member of the cryptographic policies of the Group in the SA payload,
which describes the DOI, KEK and/or TEK keying material, and
authentication transforms. The SPIs are also determined by the GCKS and
downloaded in the SA payload chain (see section 5.2). The KEK SA
contains the ISAKMP cookie pair for the Category-2 SA, which is not
negotiated but downloaded. The TEK SA contains an SPI as defined in
section 5.3 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 are defined in the SA
payload, KD will contain the TEKs. This is useful if there is an
initial set 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
GROUPKEY-PULL exchange in an optional CERT payload that is separate
from the Phase 1 identity. When the Member Responder passes a new
CERT, a proof of possession (POP) payload accompanies it. The POP
payload demonstrates that the Member or GCKS principal has used the
very secret that authenticates that principal (i.e., the principal's
private key that corresponds to the public key used in the CERT
payload). POP_I is an ISAKMP SIG payload containing a hash of the
concatenated nonces Ni and Nr signed by the Member, when the Member
passes a CERT, signed by the Group Owner to prove its authorization.
POP_R contains the hash of the concatenated nonces Ni and Nr signed by
the GCKS, when the GCKS passes a CERT, signed by the Group owner, to
prove its authority to provide keys for a particular Group. The use of
the nonce pair for the POP payload, transformed through the IKE prf, is
designed to withstand compromise of the Category 1 (IKE Phase 1) key.
3.2.1 Perfect Forward Secrecy
If PFS is desired and the optional KE payload is used in the exchange,
then both sides compute a DH secret and use it to protect the new
keying material contained in KD. The GCKS Responder will xor the DH
secret with the KD payload and send it to the Member Initiator, which
Baugher, Hardjono, Harney, Weis [PAGE 13]
INTERNET DRAFT January 2001
recovers the KD by repeating this operation as in the Oakley IEXTKEY
procedure [RFC2412].
3.2.2 ISAKMP Header Initialization
Cookies are used in the ISAKMP header as a weak form of denial of
service protection. The Group ISAKMP GROUPKEY-PULL exchange uses
cookies according to ISAKMP and IKE [RFC2527, RFC2408, RFC2409].
Next Payload identifies an ISAKMP or Group-ISAKMP 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 240 for the Group-ISAKMP GROUPKEY-PULL
exchange.
Flags, Message ID, and Length are according to ISAKMP [RFC2408, Section
3.1]
3.3 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], Group ISAKMP sends control
information securely using group communications, i.e. using IP
multicast distribution of a GROUPKEY-PUSH message (which can also be
"pushed" using unicast delivery). The GROUPKEY-PUSH message replaces a
Category-2 SA KEK or KEK array, and/or creates a new Category-3 SA (see
Baugher, Hardjono, Harney, Weis [PAGE 14]
INTERNET DRAFT January 2001
section 1.3).
Member GCKS or Delegate
------ ----------------
<---- HDR*, SEQ, SA, KD, [CERT,] SIG
* Protected by the Category-2 SA KEK; encryption occurs after HDR
HDR is defined below. The SEQ payload is defined in the Payloads
section. The SA defines the policy (e.g. crypto suite) and attributes
(e.g. SPI) for a Category-2 and/or Category-3 SAs. The GCKS or
Delegate optionally provides a CERT payload for verification of the
SIG, which is a signature of a hash of the entire message before
encryption (including the header and excluding the SIG payload itself).
KD is the key download payload as described in the Payloads section.
If the SA defines an LKH-style KEK array or single KEK, KD contains a
KEK or KEK array for a new Category-2 SA, which has a new cookie pair.
When the KD payload carries a new KEK SA (section 5.3), a Category-2 SA
is replaced with a new SA having the same 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 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 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, HH, CP00, OFT].
4.3 Delegation of Key Management
Baugher, Hardjono, Harney, Weis [PAGE 15]
INTERNET DRAFT January 2001
Group ISAKMP supports delegation of GROUPKEY-PUSH datagrams through the
delegation capabilities of the PKI. However, Group ISAKMP does not
explicitly specify how the GCKS identifies delegates, but leaves this
to the PKI that is used by a particular Group ISAKMP implementation.
4.4 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 SA to differentiate the secure groups managed by a GCKS.
Thus, Group ISAKMP uses the cookie fields as an SPI. Use of the cookie
as an anti-clogging token [RFC2522, RFC2408] is for further study.
Next Payload identifies an ISAKMP or Group-ISAKMP 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 Group-ISAKMP GROUPKEY-PUSH
message.
Flags, Message ID, and Length are according to ISAKMP [RFC2408, Section
3.1]
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.
Next Payload Type Value
----------------- -----
Security Association (SA) 1
Identification (ID) 5
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 pending the receipt of an assigned number
from the Internet Assigned Names Authority (IANA).
Next Payload Type Value
----------------- -----
SA KEK Payload (SAK) 130
SA TEK Payload (SAT) 131
Key Download (KD) 132
Sequence Number (SEQ) 133
Proof of Possession (POP) 134
Baugher, Hardjono, Harney, Weis [PAGE 16]
INTERNET DRAFT January 2001
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 GDOI uses the Identification Payload defined in [RFC2407].
The following fields in the header MUST be zero (0): Protocol ID, and
Port.
5.1.1 ID_KEY_ID
In the context of the Group ISAKMP DOI, 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 and Category-3 SAs. In the GDOI, this payload may also be called a
GSA Payload.
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Situation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! 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 (1 octet) is the length of this payload according
to IKE.
Baugher, Hardjono, Harney, Weis [PAGE 17]
INTERNET DRAFT January 2001
o DOI (4 octets) - Is the GDOI, which is value 196 pending
assignment by the IANA.
o Situation (4 octets) - Must be zero.
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
SA, the GCKS would not need to send a KEK SA payload to the group
member since all SA updates would be performed using the Category-1 SA.
Alternatively, group policy might use a Category-2 SA but choose to
download a KEK to the group member only as part of the Category-1 SA.
Therefore, the KEK policy (in the SA KEK payload) would not be
necessary as part of the Category-2 SA message SA payload.
Specifying multiple SATs allows multiple sessions to belong to 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 and parameters specific to the GROUPKEY-PULL
operation.
Baugher, Hardjono, Harney, Weis [PAGE 18]
INTERNET DRAFT January 2001
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! !
~ 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 (1 octet) - Length of this payload, including the
associated SAK and SAT payloads.
o SPI (16 octets) - Security Parameter Index for the KEK. The SPI
must be the ISAKMP Header cookie pair where the first 8 octets become
the "Initiator Cookie" field of the GROUPKEY-PUSH message ISAKMP HDR,
and the second 8 octets become the "Responder Cookie" in the same HDR.
As described above, these cookies are assigned by the GCKS.
o POP Algorithm (2 octets) - The POP payload 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
POP_ALG_RSA 1
POP_ALG_DSS 2
POP_ALG_ECDSS 3
RESERVED 4-127
Private Use 128-255
o POP Key Length (2 octets) - Length of the POP payload key. If no
POP algorithm is defined in the KEK policy this field must be zero.
o KEK Attributes - Contains KEK policy attributes associated with
Baugher, Hardjono, Harney, Weis [PAGE 19]
INTERNET DRAFT January 2001
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 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 B
KE_OAKLEY_GROUP 10 B
The following attributes may only be included 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). Defined values are specified in the
following table.
KEK Management 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 in the following table.
Baugher, Hardjono, Harney, Weis [PAGE 20]
INTERNET DRAFT January 2001
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 the KEK Algorithm key length (in
bits).
5.3.5 KEK_KEY_LIFETIME
The KEK_KEY_LIFETIME class specifies the maximum time for which the KEK
is valid. The GCKS may refresh the KEK 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.
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 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
The SIG_ALGORITHM class specifies the SIG payload signature algorithm.
Defined values are specified in the following table.
Baugher, Hardjono, Harney, Weis [PAGE 21]
INTERNET DRAFT January 2001
Algorithm Type Value
-------------- -----
RESERVED 0
SIG_ALG_RSA 1
SIG_ALG_DSS 2
SIG_ALG_ECDSS 3
RESERVED 4-127
Private Use 128-255
5.3.8 SIG_KEY_LENGTH
The SIG_KEY_LENGTH class specifies the length of the SIG payload key.
5.3.9 KE_OAKLEY_GROUP
The KE_OAKLEY_GROUP class defines the OAKLEY Group used to compute the
PFS secret in the optional KE payload of the GDOI GROUPKEY-PULL
exchange. This attribute uses the Internet DOI definitions [RFC2407].
5.4 SA TEK Payload
The SA TEK (SAT) payload contains security attributes for a single TEK
SA associated with 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 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol-ID ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ TEK Protocol-Specific Payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The SAT 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 another SAT Payload or zero to indicate
there are no more security association attributes.
o RESERVED (1 octet) - Must be zero.
o Payload Length (1 octet) - Length of this payload, including the
associated SAK and SAT payloads.
o Protocol-ID (1 octet) - Value specifying the Security Protocol.
The following table defines values for the Security Protocol
Baugher, Hardjono, Harney, Weis [PAGE 22]
INTERNET DRAFT January 2001
Protocol ID Value
----------- -----
RESERVED 0
PROTO_IPSEC_ESP 4
PROTO_MESP 5
PROTO_AMESP 6
RESERVED 7-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:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SRC ID Type ! SRC ID Prot ! SRC ID Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
!SRC ID Data Len! SRC Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST ID Type ! DST ID Prot ! DST ID Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
!DST ID Data Len! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! RFC 2407 SA Attributes !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The SAT Payload fields are defined as follows:
o SRC ID Type (1 octet) - Value describing the identity information
found in the SRC Identification Data field. Defined values are
specified in RFC2407 Section 4.6.2.1. Set to zero for multiple-source
multicast groups that use a common TEK for all senders.
o SRC ID Prot (1 octet) - Value describing an IP protocol ID (e.g.,
UDP/TCP). A value of zero means that the SRC Id Prot field should be
ignored. Set to zero for multiple-source multicast groups that use a
common TEK for all senders.
o SRC ID Port (2 octets) - Value specifying a port associated with
the source Id. A value of zero means that the SRC ID Port field should
be ignored. Set to zero for multiple-source multicast groups that use a
common TEK for all senders.
o SRC ID Data Len (1 octet) - Value specifying the length of the
SRC Identification Data field. Set to zero for multiple-source
Baugher, Hardjono, Harney, Weis [PAGE 23]
INTERNET DRAFT January 2001
multicast groups that use a common TEK for all senders.
o SRC Identification Data (variable length) - Value, as indicated
by the SRC ID Type. Set to 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 in RFC2407 Section 4.6.2.1
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 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 Group
ISAKMP.
5.4.2 Other Security Protocols
Besides ESP, Group ISAKMP 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 be provided to the GDOI.
Baugher, Hardjono, Harney, Weis [PAGE 24]
INTERNET DRAFT January 2001
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 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 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 SA with an optional KE payload,
The Key Download Payload will be xor'ed with the new 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.
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Number of Key Packets ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Key Packets ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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.
Baugher, Hardjono, Harney, Weis [PAGE 25]
INTERNET DRAFT January 2001
o RESERVED (1 octet) - Unused, set to zero.
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
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.
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.
Baugher, Hardjono, Harney, Weis [PAGE 26]
INTERNET DRAFT January 2001
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
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 KD payload, the
group member can expect to receive the TEK as part of a Category-2 SA.
At least one TEK must be included in each Category-2 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.
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.
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.
Baugher, Hardjono, Harney, Weis [PAGE 27]
INTERNET DRAFT January 2001
5.5.2 KEK Download Type
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.
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
The LKH key packet is comprised of attributes representing different
leaves in the LKH key tree. The format of those attributes are
described in Appendix B.
5.5.4 OFT
The OFT key packet is comprised of attributes representing different
leaves in the OFT key tree. The format of those attributes are TBD.
Baugher, Hardjono, Harney, Weis [PAGE 28]
INTERNET DRAFT January 2001
5.6 Sequence Number Payload
The Sequence Number Payload (SEQ) provides an anti-replay protection
for GROUPKEY-PUSH messages. Its use is similar to the Sequence Number
field defined in the 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 Sequence Number 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.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
o Sequence Number (4 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 of 1. The GDOI implementation keeps a sequence counter as an
attribute for Cat-2 SA and increments the counter upon receipt of a
GROUPKEY-PUSH message. The current value of the sequence number must be
transmitted to group members as a part of the Cat-1 SA SA payload. A
group member must keep a sliding receive window. The window must be
treated as in the 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 Group ISAKMP exchange. The Proof of Possession
Payload is identical to an ISAKMP SIG payload. However, the usage 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.
Baugher, Hardjono, Harney, Weis [PAGE 29]
INTERNET DRAFT January 2001
6.0 Application Scenarios
This section considers two uses of Group ISAKMP for data broadcast and
video-on-demand applications. In these applications, a "content
provider" may be a studio, such as one of the seven major U.S. movie
studios, or a regional, national or international broadcast station.
There is also a "distributor," who provides delivery 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 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. The customer authentication may
use a smart card, pass phrases, network authentication, tamper-
resistant software, and other means. These means are beyond the scope
of this document though the ID and GID payload fields convey the needed
authorization information in the GDOI Phase 1 and GROUPKEY-PULL
exchanges. Each application scenario is discussed in a separate
section below.
6.1 Data Broadcast
In this scenario, a wide-area broadcaster is sending a multicast data
feed. This feed is from a live sporting event that is streamed from
the event location. This broadcaster is also the content provider who
sends the feed, which is received by authorized customers of
metropolitan-area network distributors. The network distributor also
has a GCKS that acts on its behalf and has distributed KEKs to the
Group of customers who are authorized to receive the sporting-event
feed. Our network distributor delivers the broadcast data encrypted by
the TEK, which is sent via IP Multicast in a GROUPKEY-PUSH message.
The customers who have the KEK or KEK array for the network-
distributor's Group will be able to decrypt the GROUPKEY-PUSH messages
that contain the TEK for the sporting event. In this way, the network
distributor controls access to the TEK by its customers independently
of the broadcaster, who encrypts each stream once for re-distribution
through any number of network distributors.
At the end of the data broadcast, each network distributor will have
its GCKS instruct Group members to destroy the Category-3 SA and its
TEK. This is done through a GROUPKEY-PUSH message.
Baugher, Hardjono, Harney, Weis [PAGE 30]
INTERNET DRAFT January 2001
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
Group ISAKMP securely establishes keys for unicast and multicast data.
As further illustrated in the two scenaria, Group ISAKMP is suitable to
manage keys for streams as well as file download. Besides supporting
1:N and 1:1 groups, Group ISAKMP 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
Group ISAKMP is a security association (SA) protocol for groups of
senders and receivers. This protocol must use 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 Group ISAKMP uses
best-known practices for key management.
Baugher, Hardjono, Harney, Weis [PAGE 31]
INTERNET DRAFT January 2001
Group ISAKMP 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]. Group ISAKMP 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 Group ISAKMP uses ISKAMP
and IKE in a good way.
Of course, Group ISAKMP 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 Group ISAKMP successfully
employs novel techniques such as multicast key distribution without
compromising Group security (as defined by Group policy).
8.0 Acknowledgements
The authors thank Ran Canetti and Cathy Meadows. 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 of this draft, including a replay attack against
the proof of possession exchange.
9.0 References
[CP00] R. Canetti, B. Pinkas, A taxonomy of multicast security issues,
http://www.ietf.org/internet-drafts/draft-irtf-smug-taxonomy-01.txt,
Work in Progress, August 2000.
[DVW92] Diffie, P. van Oorschot, M. J. Wiener, Authentication and
Authenticated Key Exchanges, Designs, Codes and Cryptography, 2, 107-
125 (1992), Kluwer Academic Publishers.
[FS00] N. Ferguson and B. Schneier, A Cryptographic Evaluation of
IPsec, CounterPane, http://www.counterpane.com/ipsec.html.
[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.
Baugher, Hardjono, Harney, Weis [PAGE 32]
INTERNET DRAFT January 2001
[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.
[HH] H. Harney, E. Harder, Group Secure Association Key Management
Protocol, http://search.ietf.org/internet-drafts/draft-harney-sparta-
gsakmp-sec-02.txt, June 2000, Work in Progress.
[Kraw96] H. Krawczyk, SKEME: A Versatile Secure Key Exchange Mechanism
for Internet, ISOC Secure Networks and Distributed Systems Symposium,
San Diego, 1996.
[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.
[QuickTime] Inside MacIntosh: QuickTime, Apple Computer, Inc., 1993.
[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.
[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
Baugher, Hardjono, Harney, Weis [PAGE 33]
INTERNET DRAFT January 2001
[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.
Authors Address:
Mark Baugher
PassEdge
20400 NW Amberwood Drive
Beaverton, OR 97006, USA
(503) 466-8406
mbaugher@passedge.com
Thomas Hardjono
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821, USA
(978) 288-4538
thardjono@baynetworks.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
Baugher, Hardjono, Harney, Weis [PAGE 34]
INTERNET DRAFT January 2001
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 Group ISAKMP 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 Group ISAKMP 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
Baugher, Hardjono, Harney, Weis [PAGE 35]
INTERNET DRAFT January 2001
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. Group ISAKMP does nothing with this ordering
beyond communicating it to the MESP/AMESP implementation across the
interface shown in Figure 3 between Group ISAKMP 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.
Group ISAKMP does nothing with this layering information beyond
communicating it to the MESP/AMESP implementation across the interface
shown in Figure 3 between Group ISAKMP and the Security Protocol.
Baugher, Hardjono, Harney, Weis [PAGE 36]
INTERNET DRAFT January 2001
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.
Baugher, Hardjono, Harney, Weis [PAGE 37]
INTERNET DRAFT January 2001
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.
Baugher, Hardjono, Harney, Weis [PAGE 38]
INTERNET DRAFT January 2001
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.
Baugher, Hardjono, Harney, Weis [PAGE 39]
INTERNET DRAFT January 2001
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 [HH].
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
Baugher, Hardjono, Harney, Weis [PAGE 40]
INTERNET DRAFT January 2001
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.
Baugher, Hardjono, Harney, Weis [PAGE 41]
INTERNET DRAFT January 2001
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.
Baugher, Hardjono, Harney, Weis [PAGE 42]
