Internet Research Task Force Mark Baugher(PassEdge)
INTERNET-DRAFT Thomas Hardjono (Nortel)
Brian Weis (Cisco)
September 2000
Group Domain of Interpretation for ISAKMP
<draft-irtf-smug-gdoi-00.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 "Group DOI," 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 draft document should be addressed to
smug@cs.umass.edu.
Baugher, Hardjono, Weis [PAGE 1]
INTERNET DRAFT September 2000
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....................................9
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 Group ISAKMP Phase 2 Exchange.................................11
3.1 ACL-based Versus Credential-based Authorization.............11
3.2 Messages....................................................11
3.2.1 Perfect Forward Secrecy.................................13
3.2.2 ISAKMP Header Initialization............................14
4.0 Key Management Datagram.......................................14
4.1 Perfect Forward Secrecy.....................................15
4.2 Forward and Backward Access Control.........................15
4.3 Delegation of Key Management................................15
4.4 ISAKMP Header Initialization................................15
5.0 Payloads and Defined Values...................................16
5.1 Identification Payload......................................16
5.1.1 ID_KEY_ID...............................................16
5.2 Security Association Payload................................16
5.2.1 Situation...............................................17
5.2.2 Payloads following the SA payload.......................18
5.3 SA KEK payload..............................................18
5.3.1 KEK Attributes..........................................19
5.3.2 KEK_MANAGEMENT_ALGORITHM................................20
5.3.3 KEK_ALGORITHM...........................................20
5.3.4 KEK_KEY_LENGTH..........................................20
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..........................................21
5.3.9 POP_ALGORITHM...........................................21
5.3.10 POP_KEY_LENGTH.........................................22
5.3.11 KE_OAKLEY_GROUP........................................22
5.4 SA TEK Payload..............................................22
5.4.1 PROTO_IPSEC_ESP.........................................24
5.4.2 Other Security Protocols................................24
5.5 Key Download Payload........................................25
5.5.1 Key Download Types......................................27
5.5.1.1 TEK.................................................27
5.5.1.2 KEK.................................................28
5.5.1.3 LKH.................................................28
5.5.1.4 OFT.................................................28
5.6 Sequence Number Payload.....................................29
5.7 Proof of Possession.........................................29
Baugher, Hardjono, Weis [PAGE 2]
INTERNET DRAFT September 2000
6.0 Application Scenarios.........................................29
6.1 Data Broadcast..............................................30
6.2 Video-on-demand.............................................30
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............34
A.1 SA TEK bindings.............................................35
A.2 MESP/AMESP SA TEK Attributes................................35
A.2.1 GS_ORDER................................................35
A.2.2 GS_PROTOCOL.............................................36
A.2.3 GS_TRANSFORM............................................36
A.2.4 GS_TRANSFORM_KEY_LENGTH.................................36
A.2.5 GS_TRANSFORM_KEY_LIFETYPE...............................36
A.2.6 GA_ORDER................................................36
A.2.7 GA_PROTOCOL.............................................36
A.2.8 GA_TRANSFORM............................................37
A.2.9 SrA_ORDER...............................................37
A.2.10 SrA_PROTOCOL...........................................37
A.2.11 SrA_ALGORITHM..........................................37
A.3 TESLA SA TEK Attributes.....................................37
A.3.1 SOURCE_ID...............................................37
A.3.2 DIRECT_SYNCHRONIZATION..................................37
A.3.3 SENDERS_CERT_TYPE.......................................38
A.3.4 SENDERS CERT............................................38
A.3.5 HMAC TYPE...............................................38
A.3.6 INTERVAL_DURATION.......................................38
A.3.7 KEY_DISCLOSURE_DELAY....................................38
Baugher, Hardjono, Weis [PAGE 3]
INTERNET DRAFT September 2000
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 single-source and multiple-source
multicast applications (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 Controller and
Key Server" (GCKS) and two types of Members ("Receiver" and "Sender").
Baugher, Hardjono, Weis [PAGE 4]
INTERNET DRAFT September 2000
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 (eg. user, host, process).
1.2 The GKM Building Block
The Group ISAKMP security model uses a Group Security Association (GSA)
having three security association (SA) types. 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
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 Category-2 SA uses Key
Management datagrams that are sent multicast or unicast from the GCKS to
Baugher, Hardjono, Weis [PAGE 5]
INTERNET DRAFT September 2000
all group members. Group ISAKMP Key Management messages carry keying
material, policy and attributes for creating new Category-2 and
Category-3 SAs. In Group ISAKMP, the GCKS or its delegate 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 keys 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 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 data at the
internetwork or application layers and may be sent by a multicast or
unicast service (section 6). 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 introduces an SA structure called a "group security
association".
There are several new payloads:
1) Group SA (a further defined ISAKMP SA payload, or Policy Token in
GSAKMP)
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) There is a Phase 2 exchange for the Category-2 SA
2) There is a Key Management datagram for creating new Category-2 and
Category-3 SAs.
The Phase 2 exchange creates a secure means of downloading keying
material, policy, and attributes for the group, and it establishes a
group KEK or KEK array at the Member. The Phase 2 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
Baugher, Hardjono, Weis [PAGE 6]
INTERNET DRAFT September 2000
announcement scheme (such as SDP, see 1.4) and initiates the pull.
The Key Management datagram is "pushed" from the GCKS to the Members.
The KEK or KEK array protects the Key Management message, which creates
a new Category-3 or Category-2 SA. When the Key Management datagram
carries a KEK array, it creates a new Category-2 SA. When the Key
Management carries a 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. 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 Key Management message is not used to create Category-2
SAs for the particular Group. Use of LKH-style membership management is
an option in Group ISAKMP.
1.4 Functional Block Diagram
+----------------------------------------------------------+
| |
| +-------------+ +------------+ |
| |AUTHORIZATION| |ANNOUNCEMENT| |
| +------^------+ +------|-----+ +--------+ |
| | | +---->| CERTS | |
| | | | +--------+ |
| +----v----+ +----v--v-+ +--------+ |
| | | | |<->| SAD | |
| | GROUP <-------------> GROUP | +--------+ |
| | ISAKMP | | ISAKMP | +--------+ |
| | ------+ | |<->| SPD | |
| +---------+ | +-^-------+ +--------+ |
| +--------+ | | | | |
| | CERTS |----->+ | | +-------------------+ |
| +--------+ | | +--------------------+ | |
| +--------+ | +-V-------+ +--------+ | | |
| | SAD <----->+ | |<->| SAD <-+ | |
| +--------+ | |SECURITY | +--------+ | |
| +--------+ | |PROTOCOL | +--------+ | |
| | SPD <----->+ | |<->| SPD <----+ |
| +--------+ +---------+ +--------+ |
| |
| (A) GCKS (B) MEMBER |
+----------------------------------------------------------+
Figure 3: Group ISAKMP Functional Block Diagram
As described in the previous section, Group ISAKMP is a group security
Baugher, Hardjono, Weis [PAGE 7]
INTERNET DRAFT September 2000
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 Group ISAKMP. Members may be senders
or receivers of multicast data [HCBD]. There are two functional blocks
in Figure 3 labeled "Group ISAKMP," 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. Sections 3 and 4 of
this document describe how the Group ISAKMP Exchanges use the SAD, SPD,
and CERTS blocks and support AUTHORIZATION functions in the GCKS.
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 a Group ISAKMP 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 (Sections 3 and 4).
The goal of the exchanges described in Sections 3 and 4 is to establish
a GSA through updates to the SAD and SPD of Group ISAKMP 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.
Baugher, Hardjono, Weis [PAGE 8]
INTERNET DRAFT September 2000
2.0 Motivation for Using ISAKMP
The ISAKMP protocol [RFC2408] is a key management framework for
transferring key and authentication data independent of the key
generation process. ISAKMP defines a set of key 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 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, Weis [PAGE 9]
INTERNET DRAFT September 2000
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 public key
encryption algorithm. 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 key exchange 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 IKE Phase 1 is applicable for protection of
Group ISAKMP 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, which is defined
below.
Baugher, Hardjono, Weis [PAGE 10]
INTERNET DRAFT September 2000
3.0 Group ISAKMP Phase 2 Exchange
The goal of the Phase 2 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 Phase 2; there may be multiple Phase 2
exchanges for a given Phase 1 SA. The Phase 2 exchange downloads the
Group key encrypting key (KEK) or KEK array under the protection of the
Category 1 SA. As described above, the Category 1 SA is an IKE Phase 1
SA [RFC2407, RFC2409], which protects the Phase 2 exchange.
The level of security of the Phase 2 exchange is particular to a Group
beyond some base level of protection offered by ISAKMP. Some Group
policies may dictate that the Phase 2 exchange has perfect forward
secrecy, or PFS [DVW92], a particular crypto-suite, or a particular
authentication mechanism, etc. Thus the Phase 2 exchange supports
optional parameters for PFS (KE payload) and policy (SA payload).
3.1 ACL-based Versus Credential-based Authorization
The Phase 2 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
Phase 2 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 Phase 2 exchange includes an
authenticated key exchange (AKE) to do 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 Phase 2 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 the ID payload). The GCKS authenticates this identity
as part of the Phase 2 exchange.
3.2 Messages
The Group ISAKMP Phase 2 uses many IKE definitions. IKE phase 1
Baugher, Hardjono, Weis [PAGE 11]
INTERNET DRAFT September 2000
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 Group ISAKMP Phase 2 HASH payloads. As with
the IKE Phase 2 HASH payload generation [RFC 2409 section 5.5], each
Group ISAKMP Phase 2 message hashes a uniquely-defined set of values.
Nonces perform two functions in the HASH in that they permute the HASH
and provide some protection against replay attacks. Replay protection
is important to Group ISAKMP, especially to protect the GCKS from
attacks that a key management server will attract.
The Group ISAKMP Phase 2 uses nonces to guarantee "liveliness", or that
someone is not replaying a recent IKE Phase 2 message. The replay
attack is only useful in the context of the current Phase 1. If a Phase
2 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.
As shown below, nonces require an additional message in the protocol
exchange to ensure that the GCKS does not add a group member to a group
until the peer proves liveliness. The Phase 2 Member-Initiator expects
to find its nonce, Ni, in the HASH of a returned message. And the Phase
2 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)
* Protected by IKE Phase 1 SA, encryption occurs after HDR
HDR is an ISAKMP header payload that uses the Phase 1 cookies and a
Baugher, Hardjono, Weis [PAGE 12]
INTERNET DRAFT September 2000
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 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 Key
Management datagrams (section 4) and provides replay protection against
attacks from non Group-Members. The GCKS Responder informs the Member
of the cryptographic and authorization policies of the Group in the SA
payload, which describes the DOI, Situation, 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 Key Management messages (described in section 4).
As described above, the Member may establish an identity in the Phase 2
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. POP_I is an ISAKMP SIG payload
containing the signed nonce, Ni, when the Member passes a CERT, signed
by the Group Owner to prove its authorization. POP_R contains the
signed nonce, Nr, when the GCKS passes a CERT, signed by the Group
owner, to prove its authority to provide keys for a particular Group.
Recall that Group and Group owner are identified through the
announcement application described in 1.4.
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 recovers
the KD by repeating this operation as in the Oakley IEXTKEY procedure
[RFC2412].
Baugher, Hardjono, Weis [PAGE 13]
INTERNET DRAFT September 2000
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 Phase 2 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 Phase 2 exchange.
Flags, Message ID, and Length are according to ISAKMP [RFC2408, Section
3.1]
4.0 Key Management Datagram
Following the model described in [HBH00], Group ISAKMP sends control
information securely using group communications, i.e. using IP multicast
distribution of a Key Management message, which can also be "pushed"
using unicast delivery. The Key Management message replaces a Category-
2 SA KEK or KEK array, or creates a new Category-3 SA (see 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 sequence counter, which is initialized
in message 4 of section 3.1. If the SA defines an SA TEK payload, this
also informs the member if that new Category-3 SAs have been created,
with keying material carried in KD (Section 5.5).
Baugher, Hardjono, Weis [PAGE 14]
INTERNET DRAFT September 2000
4.1 Perfect Forward Secrecy
The Key Management message is protected by the Group KEK though in all
cases, the Key Management message carries new key downloads, among other
information. A freshly generated secret must protect the key download
for the Key Management message to have PFS. This issue is for further
study.
4.2 Forward and Backward Access Control
An unrelated notion to PFS is called "Forward Access Control" [HBH].
There is also "backward access control." Both have been called "perfect
forward security" and "perfect backward security" in the literature
[RFC2627, HH, OFT]. Group ISAKMP 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). The
Situation field declares whether forward or backward access control is
required for the Group (Section 5.2.1).
4.3 Delegation of Key Management
Group ISAKMP supports delegation of Key Management 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 Key Management
datagram.
Flags, Message ID, and Length are according to ISAKMP [RFC2408, Section
3.1]
Baugher, Hardjono, Weis [PAGE 15]
INTERNET DRAFT September 2000
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
5.1 Identification Payload
The Identification Payload is used to identify a group identity that
will later be associated with Security Association for the group. A
group identity may map to a specific IP multicast group, or may specify
a more general identifier which represents a set of related multicast
streams.
Group ISAKMP DOI 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 Group
DOI it is used to negotiate security attributes for both Category-2 and
Category-3 SAs. In the Group DOI, this payload may also be called a GSA
Payload.
Baugher, Hardjono, Weis [PAGE 16]
INTERNET DRAFT September 2000
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 Group
ISAKMP Phase 2 or the Key Management datagram 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.
o DOI (4 octets) - Is the GDOI, which is value 1960 pending
assignment by the IANA.
o Situation (4 octets) - The GDOI situation for this Group defined
in 5.2.1 below.
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 Situation
Situation is the GDOI bit mask for security level for one or more
security levels given below.
Situation Value
--------- -----
SIT_GROUP_SECRECY 0x01
SIT_SOURCE_AUTH 0x02
SIT_FORWARD_ACCESS_CONTROL 0x04
SIT_BACKWARD_ACCESS_CONTROL 0x08
Baugher, Hardjono, Weis [PAGE 17]
INTERNET DRAFT September 2000
All Group ISAKMP Situations have SIT_GROUP_SECRECY set. SIT_SOURCE_AUTH
indicates that the Security Protocol (e.g., MESP or AMESP) can
successfully authenticate a packet source that is sending to the group.
SIT_GROUP_SECRECY, however, authenticates packet sources solely by a
symmetric key as is done in IPSEC ESP with SKEYID [RFC2406].
SIT_FORWARD_ACCESS_CONTROL and SIT_BACKWARD_ACCESS_CONTROL require that
the Group support an LKH-style Key Management datagram [RFC2627, OFT],
which means that the GCKS application program can change the (root) KEK
to a subset of the group using the Key Management datagram. Thus, every
Security Protocol operating within a particular SIT_FORWARD_ACCESS or
SIT_BACKWARD_ACCESS Group MUST support changes to the TEK during
operation.
ISAKMP enforces Group policy regarding authentication and access control
for the Group's KEK and any of the Group's Security Protocol SAs. That
is, the Situation of any SA must match the Group Situation. For
example, if SIT_SOURCE_AUTH is set in the SA Situation bitmask, then it
must be in force for each SA it establishes. Thus, PROTO_IPSEC_ESP
cannot be established if the SA requires SIT_SOURCE_AUTH but PROTO_MESP
or PROTO_AMESP could be established since these protocols support source
authentication.
5.2.2 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.
Allowing multiple TEKs 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.
Thus zero or one SA KEK payloads and zero or more SA TEK payloads follow
the SA payload. In either case, there is at least one SA KEK payload or
one TEK payload following the SA payload.
5.3 SA KEK payload
The SA KEK (SAK) payload contains security attributes for the KEK method
Baugher, Hardjono, Weis [PAGE 18]
INTERNET DRAFT September 2000
for a group. If the group does not use a KEK it MUST NOT be sent in a
message.
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 ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ KEK Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The SAK Payload fields are defined as follows:
o Next Payload (1 octet) - Identifies the next payload for the Group
ISAKMP Phase 2 or the Key Management datagram message. The only valid
next payload types for this message are a SAT Payload or 0 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 form the
Initiator Cookie, and the second 8 octets form the Responder Cookie.
o KEK Attributes - 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 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).
Baugher, Hardjono, Weis [PAGE 19]
INTERNET DRAFT September 2000
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
POP_ALGORITHM 8 B
POP_KEY_LENGTH 9 B
KE_OAKLEY_GROUP 10 B
The following attributes may only be included in a Group ISAKMP Phase 2
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.
Algorithm Type Value
-------------- -----
RESERVED 0
KEK_ALG_DES 1
KEK_ALG_3DES 2
KEK_ALG_TWOFISH 3
RESERVED 4-127
Private Use 128-255
5.3.4 KEK_KEY_LENGTH
Baugher, Hardjono, Weis [PAGE 20]
INTERNET DRAFT September 2000
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,
which implies 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.
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 POP_ALGORITHM
The POP_ALGORITHM class specifies the POP payload algorithm. Defined
values are specified in the following table.
Baugher, Hardjono, Weis [PAGE 21]
INTERNET DRAFT September 2000
Algorithm Type Value
-------------- -----
RESERVED 0
POP_ALG_RSA 1
POP_ALG_DSS 2
POP_ALG_ECDSS 3
RESERVED 4-127
Private Use 128-255
5.3.10 POP_KEY_LENGTH
The POP_KEY_LENGTH class specifies the length of the POP payload key.
5.3.11 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 Phase 2 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! 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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol-ID ! SPI Size ! SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ TEK Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
The SAT Payload fields are defined as follows:
o Next Payload (1 octet) - Identifies the next payload for the Group
ISAKMP Phase 2 or the Key Management datagram message. The only valid
next payload types for this message are another SAT Payload or 0 to
indicate there are no more security association attributes.
o RESERVED (1 octet) - Must be zero.
Baugher, Hardjono, Weis [PAGE 22]
INTERNET DRAFT September 2000
o Payload Length (1 octet) - Length of this payload, including the
associated SAK and SAT payloads.
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 0 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 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 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 0 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 Protocol-ID (1 octet) - Value specifying the Security Protocol
Baugher, Hardjono, Weis [PAGE 23]
INTERNET DRAFT September 2000
used to encapsulate packets matching the SRC and DST Identification
specified in this payload. The following table defines values for the
Security Protocol
Protocol ID Value
----------- -----
RESERVED 0
PROTO_IPSEC_ESP 4
PROTO_MESP 5
PROTO_AMESP 6
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 for the TEK.
o TEK Attributes รป Attributes regarding the TEK SPI and keys. Valid
attributes are described in the following sections describing the
Protocol ID semantics.
5.4.1 PROTO_IPSEC_ESP
Protocol ID PROTO_IPSEC_ESP is specified in the IPSEC DOI [RFC2407,
section 4.4.4]. The GDOI supports all IPSEC DOI SA Attributes for
PROTO_IPSEC_ESP including the Group Description [RFC2407, section 4.5]
when a KE payload is exchanged in the Phase 2. 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.
Thus, PROTO_IPSEC_ESP supports the SIT_GROUP_SECRECY Situation but not
the SIT_SOURCE_AUTH. PROTO_IPSEC_ESP, therefore, cannot be used for a
Group that had the SIT_SOURCE_AUTH bit set in the SA Situation. If
SIT_FORWARD_ACCESS_CONTROL or SIT_BACKWARD_ACCESS_CONTROL bits are set
in the SA Situation, then the PROTO_IPSEC_ESP implementation must
support update of the TEK during operation of the SA.
TEK Attributes for PROTO_IPSEC_ESP are specified in RFC2407 Section 4.5.
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,
applications, 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].
In order for these and future Security Protocols to use Group ISAKMP,
they must be defined in the context of the GDOI.
Baugher, Hardjono, Weis [PAGE 24]
INTERNET DRAFT September 2000
The following information needs to be provided for a Security Protocol
with the aim of defining the SA TEK payload with needed information.
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 implementation of Group ISAKMP 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
has been included, 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
Baugher, Hardjono, Weis [PAGE 25]
INTERNET DRAFT September 2000
message, then this field will be 0.
o RESERVED (1 octet) - Unused, set to 0.
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 Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
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 definitions for LKH and OFT are for further study.
o RESERVED (1 octet) - Unused, set to 0.
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
Baugher, Hardjono, Weis [PAGE 26]
INTERNET DRAFT September 2000
SPI previously sent in an SAK or SAT Payload.
o Key Packet Data (variable length) -- Contains Key information.The
format of this field is specific depending on the value of the KD Type
field. The following sections describe the format of each KD Type.
5.5.1 Key Download Types
The following describes the key packets for each key download type.
5.5.1.1 TEK
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. A
Category-2 KD must include at least one TEK.
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.1 TEK_ALGORITHM_KEY
The TEK_ALGORITHM_KEY class specifies the encryption key for this SPI.
The encryption algorithm that will use this key was specified in the SAT
payload.
5.5.1.1.2 TEK_INTEGRITY_KEY
The TEK_INTEGRITY_KEY class specifies the encryption key for this SPI.
The encryption algorithm that will use this key was specified in the SAT
payload.
5.5.1.1.3 TEK_SOURCE_AUTH_KEY
The TEK_SOURCE_AUTH_KEY class specifies the encryption key for this SPI.
Baugher, Hardjono, Weis [PAGE 27]
INTERNET DRAFT September 2000
The encryption algorithm which will use this key was specified in the
SAT payload.
5.5.1.2 KEK
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
POP_ALGORITHM_KEY 3 V
If the KEK key packet is included, there must be only one present in the
KD payload.
5.5.1.2.1 KEK_ALGORITHM_KEY
The KEK_ALGORITHM_KEY class specifies the encryption key for this SPI.
The encryption algorithm which will use this key was specified in the
SAK payload.
5.5.1.2.2 SIG_ALGORITHM_KEY
The SIG_ALGORITHM_KEY class specifies the encryption key for this SPI.
The encryption algorithm which will use this key was specified in the
SAK payload.
5.5.1.2.3 POP_ALGORITHM_KEY
The POP_ALGORITHM_KEY class specifies the encryption key for this SPI.
The encryption algorithm which will use this key was specified in the
SAK payload.
5.5.1.3 LKH
The LKH key packet is comprised of attributes representing different
leaves in the LKH key tree. The format of those attributes are TBD.
5.5.1.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, Weis [PAGE 28]
INTERNET DRAFT September 2000
5.6 Sequence Number Payload
The Sequence Number Payload (SEQ) provides an anti-replay protection for
Key Management messages. It's 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 0.
o RESERVED (1 octet) - Unused, set to 0.
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. It is initialized to 0 by the GCKS, and
incremented in each subsequence transmitted message. Thus the first
packet sent for a given Cat-2 SA will have a Sequence Number of 1. 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 or GCKS delegate signs a nonce.
6.0 Application Scenarios
This section considers two uses of Group ISAKMP for data broadcast and
video-on-demand applications. In data broadcast applications, a
"content provider" may be a studio, such as one of the seven major U.S.
Baugher, Hardjono, Weis [PAGE 29]
INTERNET DRAFT September 2000
movie studios. In video-on-demand applications, the "content provider"
may be a regional, national or international broadcast station. For
both video on demand and data broadcast, there is 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. 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 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 information in the Group
ISAKMP Phase 1 and Phase 2 exchanges. Each application scenario is
discussed in a separate section below.
6.1 Data Broadcast
In this scenario, a broadcaster is sending a multicast data feed. This
feed may be data from, say a sporting event or source of a multicast
file transfer. This broadcaster is the content provider who sends the
feed, which may be received by authorized customers of network
distributors. The network distributor 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 a TEK, which also may be broadcast in a
Phase 3 Key Management message. The customers who have the KEK or KEK
array for the network-distributor's Group will be able to decrypt the
Key Management 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 Key Management datagram.
6.2 Video-on-demand
In this scenario, a movie studio has mastered a file that contains a
popular movie. This content provider encrypts the file and sends it to
network distributors who offer video-on-demand (VOD) service to their
customers. Each 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.
The movie file may be encrypted at the mastering step in QuickTime
format, for example, in a manner such that it can be decrypted and
Baugher, Hardjono, Weis [PAGE 30]
INTERNET DRAFT September 2000
played by a QuickTime player. Such a player fulfills the role of
"Security Protocol" in Figure 3. In contrast to the previous example,
the content is encrypted at the source and sent encrypted to network
distributors, whose authorized customers may receive the content. The
studio provides the TEK for the file to the network-distributor's GCKS.
The GCKS may obtain the TEK by various means including Group ISAKMP, if
it acts as a Member of the Group to which the studio downloads TEKs for
the movie. The network distributor's GCKS in turn redistributes the TEK
encrypted in a Group KEK in a Group ISAKMP Key Management message. In
this way, the network distributor controls access to the TEK by its
customers independently of the studio, which encrypts the file once for
re-distribution through any number of network distributors. The use of
the 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
mange 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, however,
is not specified for this draft document.
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.
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. 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
Baugher, Hardjono, Weis [PAGE 31]
INTERNET DRAFT September 2000
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 Hugh Harney, Ran Canetti and Cathy Meadows. Hugh has
provided supplemental information and has answered numerous questions to
help us fit the GSAKMP into the ISAKMP framework. 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, which the authors hope have been
corrected in the present version.
9.0 References
[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.
[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-00.txt, April 1999, 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,
Baugher, Hardjono, Weis [PAGE 32]
INTERNET DRAFT September 2000
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
[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.
Baugher, Hardjono, Weis [PAGE 33]
INTERNET DRAFT September 2000
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
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 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
Baugher, Hardjono, Weis [PAGE 34]
INTERNET DRAFT September 2000
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 Key Management
Datagram 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
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
Baugher, Hardjono, Weis [PAGE 35]
INTERNET DRAFT September 2000
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.
A.2.3 GS_TRANSFORM
Transform Type Value
-------------- -----
RESERVED 0
GS_XFORM_DES 1
GS_XFORM_3DES 2
GS_XFORM_TWOFISH 3
RESERVED 4-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_TRASFORM_KEY_LIFETIME 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.
A.2.6 GA_ORDER
See A.2.1.
A.2.7 GA_PROTOCOL
See A.2.2.
Baugher, Hardjono, Weis [PAGE 36]
INTERNET DRAFT September 2000
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
INTERVAL_DURATION 69 V
KEY_DISCLOSURE_DELAY 70 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
Baugher, Hardjono, Weis [PAGE 37]
INTERNET DRAFT September 2000
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_RIPEND128 3
RESERVED 4-127
Private Use 128-255
A.3.6 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.7 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.
INTERNET DRAFT September 2000
Baugher, Hardjono, Weis [PAGE 38]
--------------------------------------------------------------------
------------------------------------------------------------------------
Thomas Hardjono email1: thardjono@yahoo.com
email2: hardjono@nortelnetworks.com
Tel: +1-978-288-4538
------------------------------------------------------------------------
