Internet Research Task Force Mark Baugher(PassEdge) INTERNET-DRAFT Thomas Hardjono (Nortel) Brian Weis (Cisco) September 2000 Group Domain of Interpretation for ISAKMP 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 ------------------------------------------------------------------------