idnits 2.17.00 (12 Aug 2021) /tmp/idnits5908/draft-ietf-msec-gspt-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1425 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 105 has weird spacing: '...ntifies three...' == Line 400 has weird spacing: '...ts with resea...' == Line 871 has weird spacing: '...f IPsec confi...' == Line 908 has weird spacing: '...ys, etc n/a...' == Line 978 has weird spacing: '...issions emp...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2003) is 6725 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PAGE 1' is mentioned on line 52, but not defined == Missing Reference: 'HCBD00' is mentioned on line 120, but not defined == Missing Reference: 'PAGE 2' is mentioned on line 99, but not defined == Missing Reference: 'OFT' is mentioned on line 109, but not defined == Missing Reference: 'PAGE 3' is mentioned on line 148, but not defined == Missing Reference: 'PAGE 4' is mentioned on line 194, but not defined == Missing Reference: 'PAGE 5' is mentioned on line 242, but not defined == Missing Reference: 'PAGE 6' is mentioned on line 289, but not defined == Missing Reference: 'PAGE 7' is mentioned on line 342, but not defined == Missing Reference: 'PAGE 8' is mentioned on line 392, but not defined -- Looks like a reference, but probably isn't: '2' on line 433 == Missing Reference: 'PAGE 9' is mentioned on line 443, but not defined == Missing Reference: 'REF' is mentioned on line 451, but not defined == Missing Reference: 'PAGE 10' is mentioned on line 488, but not defined == Missing Reference: 'PAGE 11' is mentioned on line 534, but not defined == Missing Reference: 'PAGE 12' is mentioned on line 580, but not defined -- Looks like a reference, but probably isn't: '5' on line 609 -- Looks like a reference, but probably isn't: '6' on line 614 == Missing Reference: 'PAGE 13' is mentioned on line 631, but not defined == Missing Reference: 'PAGE 14' is mentioned on line 682, but not defined -- Looks like a reference, but probably isn't: '10' on line 730 == Missing Reference: 'PAGE 15' is mentioned on line 732, but not defined == Missing Reference: 'PAGE 16' is mentioned on line 782, but not defined == Missing Reference: 'PAGE 17' is mentioned on line 832, but not defined == Missing Reference: 'PAGE 18' is mentioned on line 880, but not defined == Missing Reference: 'PAGE 19' is mentioned on line 928, but not defined == Missing Reference: 'PAGE 20' is mentioned on line 976, but not defined -- Looks like a reference, but probably isn't: '7' on line 1051 == Missing Reference: 'PAGE 21' is mentioned on line 1027, but not defined == Missing Reference: 'PAGE 22' is mentioned on line 1077, but not defined == Missing Reference: 'PAGE 23' is mentioned on line 1126, but not defined == Missing Reference: 'PAGE 24' is mentioned on line 1177, but not defined == Missing Reference: 'PAGE 26' is mentioned on line 1220, but not defined == Unused Reference: 'BF99' is defined on line 1093, but no explicit reference was found in the text == Unused Reference: 'BMS99' is defined on line 1097, but no explicit reference was found in the text == Unused Reference: 'BR93' is defined on line 1102, but no explicit reference was found in the text == Unused Reference: 'Bris99' is defined on line 1106, but no explicit reference was found in the text == Unused Reference: 'CP99' is defined on line 1110, but no explicit reference was found in the text == Unused Reference: 'DVW92' is defined on line 1114, but no explicit reference was found in the text == Unused Reference: 'FS00' is defined on line 1118, but no explicit reference was found in the text == Unused Reference: 'HCBD99' is defined on line 1121, but no explicit reference was found in the text == Unused Reference: 'HCD99' is defined on line 1127, but no explicit reference was found in the text == Unused Reference: 'HH99a' is defined on line 1132, but no explicit reference was found in the text == Unused Reference: 'HH99b' is defined on line 1136, but no explicit reference was found in the text == Unused Reference: 'Kraw96' is defined on line 1140, but no explicit reference was found in the text == Unused Reference: 'RFC1889' is defined on line 1144, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 1153, but no explicit reference was found in the text == Unused Reference: 'RFC2407' is defined on line 1156, but no explicit reference was found in the text == Unused Reference: 'RFC2408' is defined on line 1159, but no explicit reference was found in the text == Unused Reference: 'RFC2409' is defined on line 1162, but no explicit reference was found in the text == Unused Reference: 'RFC2412' is defined on line 1165, but no explicit reference was found in the text == Unused Reference: 'RFC2522' is defined on line 1168, but no explicit reference was found in the text == Unused Reference: 'SDNS88' is defined on line 1174, but no explicit reference was found in the text == Unused Reference: 'WL98' is defined on line 1178, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BF99' -- Possible downref: Non-RFC (?) normative reference: ref. 'BMS99' -- Possible downref: Non-RFC (?) normative reference: ref. 'BR93' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bris99' -- Possible downref: Non-RFC (?) normative reference: ref. 'CP99' -- Possible downref: Non-RFC (?) normative reference: ref. 'DVW92' -- Possible downref: Non-RFC (?) normative reference: ref. 'FS00' -- Possible downref: Non-RFC (?) normative reference: ref. 'HCBD99' -- Possible downref: Non-RFC (?) normative reference: ref. 'HCD99' -- No information found for draft-harney-msmp-sec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'HH99a' -- Possible downref: Non-RFC (?) normative reference: ref. 'HH99b' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kraw96' ** Obsolete normative reference: RFC 1889 (Obsoleted by RFC 3550) ** Downref: Normative reference to an Experimental RFC: RFC 2093 ** Downref: Normative reference to an Experimental RFC: RFC 2094 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2412 ** Downref: Normative reference to an Experimental RFC: RFC 2522 ** Downref: Normative reference to an Informational RFC: RFC 2627 -- Possible downref: Non-RFC (?) normative reference: ref. 'SDNS88' -- Possible downref: Non-RFC (?) normative reference: ref. 'WL98' Summary: 17 errors (**), 0 flaws (~~), 56 warnings (==), 23 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Research Task Force Thomas Hardjono (VeriSign) 2 INTERNET-DRAFT Hugh Harney (Sparta) 3 draft-ietf-msec-gspt-02.txt Pat McDaniel (U. Michigan) 4 Andrea Colgrove (Sparta) 5 Pete Dinsmore (NAI) 7 18 August 2003 Expires December 2003 9 The MSEC Group Security Policy Token 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as 27 "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document provides a definition for Group Security Policy, describes 37 the set of elements that make-up an instance of group policy for a given 38 group, and provides an explanation of the intended functions of each 39 element of a group security policy as expressed in the form of the 40 Policy Token or Policy Certificate. 42 1. Introduction 44 Group communications, also commonly called multicast, refers to 45 communications in a group where the messages can be sent by any member 46 and are received by all members. The applications and encryption can be 47 implemented in a variety of ways and at numerous levels on the network 48 stack. They range from mailing lists to conference calls to IP 49 Multicasting. Often the need for data protection arises, which requires 50 the group to handle the messages in a consistently secure manner. To 52 MSEC Policy Token [PAGE 1] 53 accomplish this, cryptographic mechanisms and security policy must be 54 shared and supported by the group as a whole. Because of this, special 55 problems arise in managing the cryptographic and policy material as it 56 changes or as the group changes. 58 2. Framework for Group Security Policy 60 Group Security Policy represents an important building block within the 61 Secure Multicast Group Framework of [HCBD00]. The Framework of [HCBD00] 62 is broad in the sense that it incorporates entities, functions and 63 interfaces encompassing all aspects of secure groups. 65 2.1 The Secure Multicast Group Framework 67 +---------------------------------------------------------+ 68 | CENTRALIZED \ DISTRIBUTED | 69 | DESIGNS \ DESIGNS | 70 | \ | 71 | \ | 72 | +------+ \ +------+ | 73 | |Policy|<-------\---------------------->|Policy| | 74 | | | \ | | | 75 | +------+ \ +------+ | 76 | ^ \ ^ | 77 | | \ | | 78 | | \ | | 79 | v \ v | 80 | +------+ \ +------+ | 81 | |Group |<-------------- \-------------> |Group | | 82 | |Ctrl/ |<---------+ \ |Ctlr/ | | 83 | |Key | | \ |Key | | 84 | |Server| V \ |Server| | 85 | +------+ +--------+ \ +------+ | 86 | ^ | | \ ^ | 87 | | |Receiver| \ | | 88 | | | | | | | 89 | v +--------+ | | | 90 | +------+ ^ | V | 91 | | | | | +--------+ | 92 | |Sender|<---------+ | | | | 93 | | |<--------------------- |------>|Receiver| | 94 | | | | | | | 95 | +------+ | +--------+ | 96 +---------------------------------------------------------+ 97 FIGURE 1: Secure Multicast Group Reference Framework 99 MSEC Policy Token [PAGE 2] 100 Figure 1 shows the Secure Multicast Group Reference Framework of 101 functional entities and the interfaces between them [HCBD00]. These 102 entities and interfaces implement a secure group, which is defined as a 103 group of principals that share a secret. Secure groups are needed by 104 unicast applications as well as multicast applications (single-source 105 and multiple-source). The framework of Figure 1 identifies three group 106 key management entities, namely the "Group Controller and Key Server" 107 (GCKS) and two types of Members ("Receiver" and "Sender"). The GCKS 108 entity embodies both the physical entity and functions of the group 109 controller and the key server [RFC2093, RFC2094, RFC2627, OFT]. The 110 Member belongs to one or more groups and may exist at different layers 111 (e.g. user, host, process). 113 These entities (namely the GCKS, Sender and Receivers) represents the 114 entities upon which Group Security Policy immediately applies. The 115 policies exist, among others, to regulate behavior of entities that 116 make-up a secure group. 118 2.2 Group Security Policy (GSP) Framework 120 The broad Reference Framework of [HCBD00] does not (and was not intended 121 to) provide a policy-specific view of group security. Hence, to that 122 extent a further refinement of the Reference Framework is provided in 123 the following (Figure 2). 125 In Figure 2, the Group Owner is the entity defined to initiate the group 126 and set the policies for the group. As such, the entity is the owner of 127 the group and of all the information that pertains to the group. 129 >From the perspective of verification of Policy Tokens, the Group Owner 130 is the root of all certificates that is used to verify Policy Tokens and 131 certificates that delegate authority to service entities such as GCKSs 132 or other intermediary entities. This function is tied closely to the 133 fact of the Group Owner being the source of all authorizations for group 134 actions carried-out by group members. The Group Owner being the source 135 of authorization, is derived from owning or having ultimate 136 responsibility for the data. 138 >From the perspective of access control to information about the group, 139 the Group Owner determines pieces of information that are accessible 140 service-entities (such as GCKS and Policy Repositories), group members 141 and external entities. To this end, the Group Owner also decides form 142 and content of group announcements made through the appropriate 143 announcement protocols. Such information may consists of certain parts 144 of the Policy Token or the entire Policy Token itself. Similarly, the 145 Group Owner determines the information pertaining to a group that is 146 stored in the Policy Repository. 148 MSEC Policy Token [PAGE 3] 149 +---------------------------------------------------------+ 150 | | 151 | +-------------+ | 152 | | Group | | 153 | |----------->|Announcement |------------| | 154 | | +-------------+ | | 155 | | | | 156 | | | | 157 | | | | 158 | | | | 159 | +-------+ +-------------+ | | 160 | | Group | -----> | Policy | | | 161 | | Owner | | Repository | | | 162 | +-------+ +-------------+ | | 163 | | | | | 164 | | | | | 165 | | | | | 166 | | V V | 167 | | +-------------+ +-------+ | 168 | |----------->| GCKS |------->|Member | | 169 | | | | | | 170 | +-------------+ +-------+ | 171 | | 172 +---------------------------------------------------------+ 173 Figure 2: Group Security Policy Framework 175 When a (candidate) member wishes to find-out about a given group, it 176 must learn about the existence of the group through the Group 177 Announcement facility. Each group is associated with a unique Group 178 Announcements and is identified in the Group Announcement through the 179 Group IG (GID). Furthermore, announcements for different groups may 180 carry different amounts of information regarding the groups in question. 182 2.3 Announcement of Group Policy Information 184 An important aspect of secure group communications is the availability 185 of enough information for potential newcomers to decide as to whether 186 they have sufficient permissions and suitable resources (e.g. crypto 187 ability) to join the group. 189 The level of availability of such information is highly-dependent on the 190 specific application employing secure groups. In some applications, all 191 the required permissions and resources maybe pre-published in a 192 publicly-available location, protected using the group owner's digital 194 MSEC Policy Token [PAGE 4] 195 signature. In other applications, perhaps only limited information is 196 published (e.g. required certificate-class of newcomer) to allow 197 newcomers to decide whether or not to pursue further the act of joining 198 the group. 200 In this document, we do not address the issue of which parts of the 201 Group Policy Token are announced or be published to prospective 202 newcomers. 204 3. Elements of Group Security Policy 206 Security-related policies for groups of users and for group 207 communications are inherently more complex compared to policies for 208 pair-wise (unicast) secure communications between two end-points. This 209 complexity arises due to the fact that multi-party interaction allows 210 for a number of situations and conditions to arise which are simply non- 211 existent in the two-party interaction. Furthermore, in multi-party 212 communications an error or a security breach cause by one party may have 213 impact on the other parties in the group. In the two-party scenario, 214 errors or security breaches may be dealt with simply by terminating the 215 communication and restarting it. 217 The complex nature of group communications requires an equally complex 218 set of elements that make-up the Group Security Policy. These elements 219 (or categories in [polreq-draft]) specify the policies that are to be 220 followed by members of the group, and they consist of the following: 222 a. Policy Identification 224 A group must have some means by which it can identify an instance of 225 Group Security Policy in an unambiguous manner. Failure to correctly 226 identify the group policies, messages, and participants can lead to 227 incorrect and insecure operation. In the simplest form, an instance of 228 a Policy Token must be associated with a unique Group Identifier (GID) 229 expressly found inside the Policy Token. 231 b. Authorization for Group Actions 233 A Group Security Policy must identify the entities allowed to perform 234 actions that affect group members. Group authorization partially 235 determines the trust embodied by the group as a whole, by defining the 236 parties or entities that are allowed to participate in group activities. 237 Because of the wide range of expected environments, flexible 238 identification of entity authorizations is highly desirable. 239 Authorization given to an entity must be shown as being true and 240 authentic coming from another entity that bequeathed that authority. 242 MSEC Policy Token [PAGE 5] 243 c. Access Control to Group Information 245 Access control policy defines the entities that will have authorization 246 to hold the key protecting the group data. 248 d. Mechanisms for Group Security Services 250 Identification of the security services used to support group 251 communication is required. For example, policy must state the algorithms 252 used to derive session keys and the types of data transforms to be 253 applied to the group content. Each security service can have parameters 254 and policies specific to its implementation. Thus, for forward 255 compatibility with new approaches, service definitions should be 256 extensible. 258 Full specification of: 259 - the group establishment mechanism 260 - the data protection mechanism 261 - the group management mechanism 262 is necessary to establish that the entire group SA is adequate to 263 protect the data. Weakness in any one part will effect the security of 264 the other parts. 266 e. Verification of Group Security Policy 268 Each policy must present evidence of its validity. The means by which 269 the origin, integrity, and freshness of the policy is asserted (for 270 example, via digital signature) must be known by each group member prior 271 to its acquisition. In the simplest form, this consists of the Policy 272 Token being digitally-signed by the entity authorized to issue the Group 273 Security Policy. 275 4. Group Policy Token 277 The Group Policy Token is comprised of five fields corresponding to the 278 identification of the group, the authorizations in it, the access 279 control policies governing the group, the mechanisms supporting secure 280 communications, and the authentication of the contents of the token. 282 --------------------------------------------------------------------- 283 | | | | | | 284 |Token ID | Authorization | Access Control | Mechanisms | Signature | 285 | | | | | | 286 --------------------------------------------------------------------- 287 Figure 3: Group Policy Token Overall Structure 289 MSEC Policy Token [PAGE 6] 290 Each of the fields of the GSAKMP Policy Token is further expanded in 291 following sections. The specific data formats can be seen in the ASN.1 292 Policy Token Specification in Appendix A. 294 4.1 Token ID Field and Sub-Fields 296 The Token ID Field explicitly identifies the protocol family to which 297 the Group Policy Token belongs (e.g. GSAKMP, GDOI). The Token ID Field 298 consists of a Version number indicating Token version, Protocol ID 299 indicating GSAKMP, Group ID consisting of IP Addresses and serial 300 numbers, and a Timestamp. 302 --------------------------------------------------- 303 | | | | | 304 |Version | Group Protocol | Group ID | Timestamp | 305 | | | | | 306 --------------------------------------------------- 307 Figure 4: Token ID sub-fields 309 The timestamp sub field of the TokenID is of particular interest in the 310 prevention of replay attacks. A replay attack is when an adversary 311 inserts an authenticated message or portion of a message into a new run 312 of a protocol. The timestamp sub-field helps to prevent such an attack. 313 The receiver of a new token can verify that the timestamp is both 314 appropriate for the policy token and generated at a time later than the 315 timestamp on any previous Policy Tokens for that group. This will 316 prevent an adversary from successfully replaying an old token and having 317 it be accepted as a new one. Additionally, an optional expiration time 318 field will limit the validity window of the token. 320 4.2 Authorization Field and Sub-Fields 322 The authorization field allows group members to ensure that security 323 relevant actions are being performed by authorized group entities. This 324 ensures that a rogue group member does not mislead other group members 325 into an insecure action. 327 The Authorization Field identifies those who are authorized to act in 328 the special roles of Group Owner, GCKS, and Re-key GCKS. This 329 identification may be done explicitly as shown below, where the fields 330 contain actual identifiers, or implicitly, using sets of rules to define 331 the policy allowing one to assume the roles listed. For example, a 332 policy rule might state that anyone in a particular domain except two 333 people is authorized to act as a Key Server. Such a rule might be stated 334 as "include {/o=acme/ou=responsible}, not {/o=acme/ou=responsible/s=bob, 335 {/o=acme/ou=responsible/s= ted}." 337 The Re-Key GCKS is included to cater for situations in which a back-up 338 GCKS (other than then one the member initially joined to) is specified 339 to handle emergency situations (e.g. Primary GCKS crashed, network 340 partitions, etc). 342 MSEC Policy Token [PAGE 7] 343 Authorization Fields will fulfill various needs during the lifetime of a 344 group. Both new and current members will need to make use of the 345 authorization field to maintain the level of security of the 346 communications group. 348 For new or potential members, this field of the group's token should be 349 used as input into the decision for joining a particular group and for 350 the acceptance of keying material. Specifically, the rules should be 351 examined to determine whether they are stringent enough for the 352 potential member's security needs, and the member trusts the entities 353 that will be assuming the roles. In the rule-based example above, Bob 354 might be known to have particularly shoddy security practices. A new 355 member would be reassured that the secure distribution of the group's 356 encryption keys will not be managed by Bob. Furthermore, upon 357 acceptance of the invitation to join the group, the member will receive 358 the group communication keys. At that point, the member would need to 359 verify that the GCKS sending the keys fit the profile indicated by the 360 Authorization Field. The integrity of keys received from someone not 361 entitled to act as Key Server should be considered suspect. 363 The most common use of this field will be by current group members. 364 Current group members use the Authorization Field upon receipt of key 365 management or administrative messages. Before acting upon these 366 messages, it must be determined that the sender did indeed have the 367 necessary permissions to initiate a given action. For example, an 368 unauthorized re-key message might have the result of placing a member on 369 an incorrect key, thereby denying him access to the group's 370 communications. 372 ----------------------------------------- 373 | | | | 374 | Group Owner | GCKS | Re-Key GCKS | 375 | | | | 376 ----------------------------------------- 377 Figure 5: Authorization sub-fields 379 4.3 Access Control Field and Sub-Fields 381 Access to a group implies that a potential group member is given 382 permission to receive an appropriate subset of the group's keys. This is 383 explicitly stated in the policy token to ensure a common access decision 384 space. 386 The Access Field defines who is permitted to join the group. As with 387 authorizations, access controls can be defined by a combination of rules 388 and explicit names. The rules portion of the Access Field is broken 389 down into a set of permissions that determine access into a group and 390 the definition (or pointer to the definition) of those permissions for a 392 MSEC Policy Token [PAGE 8] 393 particular information domain. The Permissions are hierarchical in the 394 traditional military sense where access at a higher level encompasses 395 all the access of the lower levels plus new ones and dominance rules 396 apply. The Access List can also restrict access to those in a 397 particular knowledge group or groups. 399 As an example of how the Access Field might be filled, consider a 400 hypothetical group consisting of scientists with research and 401 development permissions working on the company's new product . 402 Each scientist could be given a permission rating. This permission 403 rating would be reflected in that scientist's personnel certificate. The 404 access rule in the policy token could make it mandatory for a potential 405 group member to have a permission rating greater than or equal to "R&D". 407 In addition to the permission based access decisions, it may be desired 408 to restrict access to the group to scientists who are members of a 409 specific work group. This work group could have a common element in 410 their Distinguished Name fields in their common PKI. For example, the 411 scientist may all be working in the Emerald City, in the land of Oz. The 412 DN access rule could be {/o=acme/ou=Emerald City/ou=Oz/*}. 414 ---------------------------- 415 | | | 416 | Permissions | Access | 417 | | | 418 ---------------------------- 419 Figure 6: Access Control sub-fields 421 4.4 Mechanism Fields and Sub-Fields 423 The security services and related mechanisms used to protect the data 424 must be consistent throughout the group to maintain uniform data 425 protection throughout the data flow. For example, if the 426 confidentiality of data is protected by the Advanced Encryption Standard 427 (AES) at one point and by the Data Encryption Standard (DES) at another, 428 the overall protection afforded the data is only the strength offered by 429 the weakest mechanism. The data mechanisms used to protect the various 430 phases of the group communications are specified in the Mechanisms Field 431 of the Group Policy Token. 433 The three Categories of SAs (REF[2]) are described in this field. 435 The Category-1 SA defines the information for a newcomer to join the 436 group by opening a secure channel to the GCKS. The secure channel 437 establishment requirements and parameters are described in the Category- 438 1 SA sub-field. 440 The Category-2 SA (or Re-Key SA) describes the Security Association that 441 will be used by the GCKS to perform a re-key of the group-key (TEK 443 MSEC Policy Token [PAGE 9] 444 and/or KEK vector) within the group. This sub-field is actually broken 445 down into further fields: Protected Key Management and Bypass. The 446 Protected Key Management SA identifies the security mechanisms set up 447 for key management messages. For cases in which Protected Key 448 Management messages cannot be correctly received and read by all 449 members, the Bypass SA will allow particular messages through without 450 confidentiality processing. Both of these correspond to the Category-2 451 SA (Re-Key SA) of the MSEC Key Management Architecture (GKM Arch [REF]). 453 The Category-3 SA (or Data Security SA) describes the protection 454 afforded Multicast Group Communications. The actual format of this 455 field is largely determined by the choice of security protocol for the 456 protection of data. Mechanism and mode choices for confidentiality and 457 authentication, key determination, key length, and rekey must all be 458 considered. Furthermore, agreed upon key validity intervals 459 (cryptoperiods) and possible data source authentication must also be 460 specified. 462 --------------------------------------------------------- 463 | | | | 464 | Category-3 SA | Category-1 SA | Category-2 SA | 465 | | | Protected Bypass | 466 | | | | 467 --------------------------------------------------------- 468 Figure 7: Mechanism Sub-Fields 470 4.5 Signature Field and Sub-Fields 472 The signature field contains the information that verifies the 473 authenticity of the group policy token. It clearly identifies the 474 signer of the token -- the Group Owner, the PKI information needed to 475 establish what is the proper certificate to use for the signature 476 verification, and the signature data. The signature covers all of the 477 fields of the Group Policy Token except for the Signature Field itself. 478 Because of this, any unauthorized change in the group policy token will 479 invalidate the signature. 481 -------------------------------------------------- 482 | | | | 483 | Signer ID | Certificate-Info | Signature-Data | 484 | | | | 485 -------------------------------------------------- 486 Figure 8: Signature Sub-Fields 488 MSEC Policy Token [PAGE 10] 489 5. Group Policy Token: Header and Payloads 491 5.1 Generic Payload Header 493 Each payload defined in the following sections begins with a generic 494 header, shown in Figure 3, which provides a payload ``chaining`` 495 capability and clearly defines the boundaries of a payload. The Generic 496 Payload Header fields are defined as follows: 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 501 ! Next Payload ! RESERVED ! Payload Length ! 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 504 Figure 3: Generic Payload Header 506 Next Payload (1 octet) - Identifier for the payload type of the next 507 payload in the message. If the current payload is the last in 508 the message, then this field will be 0. This field provides the 509 ``chaining`` capability. 511 RESERVED (1 octet) - Unused, set to 0. 513 Payload Length (2 octets) - Length in octets of the current payload, 514 including the generic payload header. 516 5.2 Policy Token Payload 518 The Policy Token Payload contains group specific information that 519 describes the group security relevant behaviors, access control 520 parameters, and security mechanisms. This information may contain a 521 digital signature(s) to prove authority and integrity of the 522 information. Figure 4 shows the format of the payload. 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 527 ! Next Payload ! RESERVED ! Payload Length ! 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 529 ! ID Type ! Policy Token Data ~ 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 532 Figure 4: Policy Token Payload Format 534 MSEC Policy Token [PAGE 11] 535 The Policy Token Payload fields are defined as follows: 537 Next Payload (1 octet) - Identifier for the payload type of the next 538 payload in the message. If the current payload is the last in the 539 message, then this field will be 0. 541 RESERVED (1 octet) - Unused, set to 0. 543 Payload Length (2 octets) - Length in octets of the current payload, 544 including the generic payload header. 546 ID Type (1 octet) - Specifies the type of Policy Token being used. 547 Table 12 identifies the types of policy tokens. 549 Table 1: Policy Token Types 551 ID_Type Value 552 ______________________ 553 Group 0 554 Auxiliary 1 555 Reserved 2-63 556 Unassigned 64-255 558 Policy Token Data (variable length) - Contains Policy Token 559 information. The values for this field are group specific and the 560 format is specified by the ID Type field. 562 The payload type for the Policy Token Payload is one (1). 564 6. Example of Group Policy Tokens 566 The following section describes an example of a Group Policy Token. The 567 full token is provided first, though the reader is encouraged first to 568 read the parts specific to each of the categories of SAs. 570 6.1 Description of Example 572 The this example the group security protocol (namely GSAKMP) creates an 573 association between multiple entities connected by the Internet. The 574 intent of the group security protocol is to use existing protocol- 575 services that are standardized for the Internet to facilitate setting up 576 these secure groups. IPsec is one of the standard secure services that 577 can be used, though others (e.g. S/MIME or even SSL) can be used as a 578 unicast security association mechanism. 580 MSEC Policy Token [PAGE 12] 581 Additionally, the Group Policy Token defines the policy for protecting 582 the multicast data traffic (Category-3 SA). Once again, IPsec can be 583 used to protect these messages, as can S/MIME. 585 In this particular example, IPsec is used as the underlying security 586 association protocol for both unicast (Cat-1) and multicast messages 587 (Cat-2 and Cat-3). 589 To configure IPsec, interaction will occur with the Security Policy 590 Database (SPD) and the Security Association Database (SAD). Since the 591 group security protocol exists above the IPsec network layer encryption 592 engine, configuration must include that of the appropriate databases 593 controlling IPsec. This is to ensure that IPsec processes its messages 594 appropriately. 596 The current example requires a unicast SA to protect some of the 597 exchanges. It also requires a bypass of IPsec processing for a subset 598 of messages. 600 Each group can have unique IPsec processing requirements for the unicast 601 and multicast messages pertaining to that particular group. These group 602 unique configurations must be conveyed to the IPsec controlling 603 databases in a way that will allow correct IPsec processing for each 604 groups' message. Special attention must be paid to the IPsec selector 605 fields. The standard source and destination pair selectors are not 606 adequate for multicast groups where multiple groups share the same 607 destination address. 609 The example assumes the presence of IKE [5] as a unicast SA 610 establishment protocol for IPsec. 612 6.2 The IPsec Architecture 614 The IPsec architecture document [6] identifies two databases used by 615 IPsec - Security Policy Database (SPD) and Secure Association Database 616 (SAD). The former specifies the policies that determine the disposition 617 of all IP traffic (inbound or outbound) from a host, security gateway, 618 or BITS or BITW IPsec implementation. The latter database contains 619 parameters that are associated with each (active) security association. 620 The information in these databases allows the IPsec protocol to process 621 incoming and outgoing packets. 623 6.2.1 SPD Inputs 625 Purpose of the SPD (copied from RFC 2401): 627 "A security association is a management construct used to enforce 628 a security policy in the IPsec environment. Thus an essential 629 element of SA processing is an underlying Security Policy Database 631 MSEC Policy Token [PAGE 13] 632 (SPD) that specifies what services are to be offered to IP 633 datagrams and in what fashion. The form of the database and its 634 interface are outside the scope of this specification. However, 635 this section does specify certain minimum management functionality 636 that must be provided, to allow a user or system administrator to 637 control how IPsec is applied to traffic transmitted or received by 638 a host or transiting a security gateway. 640 The SPD must be consulted during the processing of all traffic 641 (INBOUND and OUTBOUND), including non-IPsec traffic. In order to 642 support this, the SPD requires distinct entries for inbound and 643 outbound traffic. One can think of this as separate SPDs (inbound 644 vs. outbound). In addition, a nominally separate SPD must be 645 provided for each IPsec-enabled interface. 647 An SPD must discriminate among traffic that is afforded IPsec 648 protection and traffic that is allowed to bypass IPsec. This 649 applies to the IPsec protection to be applied by a sender and to 650 the IPsec protection that must be present at the receiver. For any 651 outbound or inbound datagram, three processing choices are 652 possible: discard, bypass IPsec, or apply IPsec. The first choice 653 refers to traffic that is not allowed to exit the host, traverse 654 the security gateway, or be delivered to an application at all. 655 The second choice refers to traffic that is allowed to pass 656 without additional IPsec protection. The third choice refers to 657 traffic that is afforded IPsec protection, and for such traffic 658 the SPD must specify the security services to be provided, 659 protocols to be employed, algorithms to be used, etc." 661 The critical elements of the SPD are 662 - Destination IP Address 663 - Source IP Address 664 - Name 665 - Data sensitivity level 666 - Transport Layer Protocol 667 - Source and Destination (e.g., TCP/UDP) Ports 668 - Specific IPsec processing 669 - Specific IPsec Algorithms (spi, service, algorithm, mode) 671 6.2.2 SAD Inputs 673 Purpose of the SAD (copied from RFC 2401): 675 "In each IPsec implementation there is a nominal Security 676 Association Database, in which each entry defines the parameters 677 associated with one SA. Each SA has an entry in the SAD. For 678 outbound processing, entries are pointed to by entries in the SPD. 679 Note that if an SPD entry does not currently point to an SA that 680 is appropriate for the packet, the implementation creates an 682 MSEC Policy Token [PAGE 14] 683 appropriate SA (or SA Bundle) and links the SPD entry to the SAD 684 entry (see Section 5.1.1). For inbound processing, each entry in 685 the SAD is indexed by a destination IP address, IPsec protocol 686 type, and SPI. The following parameters are associated with each 687 entry in the SAD. This description does not purport to be a MIB, 688 but only a specification of the minimal data items required to 689 support an SA in an IPsec implementation." 691 The critical elements of the SAD are 692 - SAD index 693 - Outer Header's Destination IP address 694 - IPsec Protocol 695 - SPI 696 - Sequence Number Counter 697 - Sequence Counter Overflow [only outbound] 698 - Anti-Replay Window: [only for inbound.] 699 - AH Authentication algorithm, keys, etc. [REQUIRED for AH 700 implementations] 701 - ESP Encryption algorithm, keys, IV mode, IV, etc. [REQUIRED for 702 ESP implementations] 703 - ESP authentication algorithm, keys, etc [REQUIRED for ESP 704 implementations] 705 - Lifetime of this Security Association: Required 706 - IPsec protocol mode: tunnel, transport or wildcard 707 - Path MTU: [REQUIRED for all implementations but used only 708 for outbound traffic] 710 6.3 Mapping from Policy Token for Ipsec 712 One of the major components of the MSEC Key Management Architecture is 713 the definition of three distinct categories of Secure Association 714 bundles. All three bundles together define a GSA. 716 The GKM BB addresses three distinct interactions that make up a GSA: 717 1. Cat-1: Unicast secure channel between key server and potential 718 group member 719 2. Cat-2: Key management messages over multicast communications (Key 720 server to members) 721 3. Cat-3: traffic data SA s (Sender to Receivers) 723 There are several messages that need to be configured into IPsec SPDs. 724 There is a need for some key management messages to bypass IPsec 725 processing. These messages are self-protecting or do not require 726 protection. During the process of establishing the group there are 727 unicast messages between the key servers and the members -- these 728 messages may be sensitive in nature and require IPsec processing. Once 729 a group has been established, there are messages that manage the group 730 as a single entity, some these messages (LKH rekey [10]) are self 732 MSEC Policy Token [PAGE 15] 733 protecting and do not need IPsec, but other management messages like 734 policy updating or group deletion may be sensitive and need IPsec 735 protection. Finally, the group key that is protecting the application 736 data, separate from GSAKMP data will need IPsec processing. In each of 737 these instances, the group policy token will carry the configuration 738 information needed to configure their SPD and SAD. 740 There is an enumerated example policy token that follows this section. 741 We have included the field numbers from that example into the following 742 SDP and SAD table entries to allow a mapping from the policy token to 743 the databases. 745 6.4 Bypass 747 At least two types of messages need to bypass IPsec processing - request 748 to join and rekey. The request to join message may be sent from the 749 member to the key server before any GSA or SA is created, so no 750 association may exist to encrypt this message. Another message that must 751 bypass IPsec is the group rekey message -- this message is self- 752 protecting and is sent to the entire group. The group rekey message may 753 be used to restore cryptographic synchronization in a group. Processing 754 this message through IPsec would negate its ability to restore 755 synchronization. 757 Bypass SPDs Incoming Outgoing 758 ---------------------- -------------- -------------- 759 Destination IP Address From (102) From (109) 760 Source IP Address From (101) From (108) 761 Name n/a n/a 762 Data sensitivity level n/a n/a 763 Transport Layer Protocol From (103) From (110) 765 Source and Destination Source: */Dest Source: */Dest 766 (e.g., TCP/UDP) Ports: from (104) from(111) 768 Specific IPsec processing: From (105) From (112) 769 Specific IPsec Algo 770 (spi, service, algo, mode): From (99) From (106) 772 6.5 Category-1 SA 774 During the initial Regsitration phase between a newcomer/group member 775 and the GCKS, sensitive information will be exchanged. 777 The group policy token example will specify the exact IPsec services 778 that are required between key server and group member. It will also 779 specify the key creation parameters that satisfy the group data security 780 requirements. 782 MSEC Policy Token [PAGE 16] 783 In this example, we assumed the use of IKE as the key creation and 784 negotiation protocol. The group policy token will specify the correct 785 IKE parameters for the group. IKE will create the pairwise key and 786 assign an appropriate SPI. 788 Two SPDs are required to completely specify this interaction -- one for 789 inbound messages in one for outbound messages. 791 Of special note: the standard selectors for IPsec are inadequate to 792 differentiate between multiple groups on a single multicast address. 793 One technique that can mitigate this problem is the assignment of a 4- 794 byte random number to a unique group on a multicast address. 796 Cat-1 SPDs Outgoing Incoming 797 ---------------------- -------------- -------------- 798 Destination IP Address From (79) From (58) 799 Source IP Address From (78) From (57) 800 Name From (82) From (61) 801 Data sensitivity level From (83) From (62) 802 Transport Layer Protocol From (80) From (59) 803 Source & Destination Ports Source: */ (81) Source: */Dest: (60) 804 Specific IPsec processing IPsec process IPsec process 805 Specific IPsec Algo 806 (spi, service, algo, mode): Spi: IKE Spi: from IKE 807 IPsec service: From (71,73-77) From: (50,52-56) 808 IKE attributes: From (84-91) From: (63-70) 810 Cat-1 SADs Outgoing Incoming 811 ---------------------- -------------- -------------- 812 SAD Index: 813 Outer Dest. IP addr * (w/ multicast Local 814 addr masked out) 815 Ipsec Protocol From (71) From (50) 816 SPI From IKE From IKE 817 Sequence Number Counter From IKE From IKE 818 Sequence Counter Overflow 819 [only outbound] From IKE From IKE 820 Anti-Replay Window 821 [only for inbound] From IKE From IKE 823 AH Authentication algo., 824 keys, etc. [REQUIRED 825 for AH implementations] n/a n/a 827 ESP Encryption algorithm, 828 keys, IV mode, IV, etc. 829 [REQUIRED for ESP 830 implementations] From (73), IKE keys From (52), IKE keys 832 MSEC Policy Token [PAGE 17] 833 ESP authentication alg., 834 keys, etc [REQUIRED for 835 ESP implementations] From (74), IKE keys From (53), IKE keys 837 Lifetime of this Security 838 Association: Required From (76) From (55) 840 IPsec protocol mode: 841 tunnel, transport or 842 wildcard From (75) From (54) 844 6.6 Category-2 SA 846 In the management of groups, the GCKS uses the Category-2 SA to send out 847 control messages, which may contain keying material (re-key message) or 848 simply consists of commands (group maintenance). 850 The rekey messages will change the group traffic encryption keys and 851 associated rekey arrays in response to some problem with the group 852 security. In the case of rekey messages, one cannot assume that a 853 single group traffic encryption key is available. Therefore, the rekey 854 messages are self-protecting and bypass IPsec processing. 856 Normal group maintenance messages perform actions that apply to the 857 entire group -- policy updates, group synchronization, and group 858 deletion. These messages may contain sensitive information and usually 859 are sent during times where the group is stable. Therefore, IPsec 860 processes these messages. 862 IPsec will bypass the rekey messages as defined in the bypass SPD above. 863 The group security protocol (ie. GSAKMP, GDOI) must maintain internal 864 configurations for processing the rekey messages. 866 For rekey messages the Selectors are taken from the Policy Token (3), 867 while the Services are taken from the Policy Token (92-98). 869 6.7 Category-3 SA 871 Category 3 is the final set of IPsec configurations (SPD and SAD 872 entries) used to protect the data traffic (nb. Hence also called "Data 873 Security SA"). Here, it is assumed that Ipsec will be used to protect 874 the data. 876 The group policy token will specify the IPsec parameters that are needed 877 to protect the data. A group Security Parameter Index (SPI) will be 878 created and distributed across the entire group. 880 MSEC Policy Token [PAGE 18] 881 Cat-3 SPDs Outgoing Incoming 882 ---------------------- -------------- -------------- 883 Destination IP Addr. From (32) From (45) 884 Source IP Addr. From (31) From (44) 885 Name From (34) From (47) 886 Data sensitivity level From (35) From (48) 887 Transport Layer Protocol From (33) From (46) 888 Src & Dest Ports Src: */Dest:* Src: */Dest:* mask 889 protocol bypass 890 Specific IPsec processing IPsec process IPsec process 891 Specific IPsec Algo From (24a) From (24a) 892 (spi, service, algo, mode) 893 - IPsec service - IPsec service 894 from (26,27,28) from (39,40,41) 895 - Key attributes: - Key attributes: 896 from protocol from protocol 898 Cat-3 SADs Outgoing Incoming 899 ---------------------- -------------- -------------- 900 Outer Dest. IP Addr. Multicast from (32) Multicast from (45) 901 Ipsec Protocol From (24) From (24) 902 SPI 903 Sequence Number Counter (only for 1-to-Many) (only for 1-to-many) 904 Sequence Counter Overflow 905 [only outbound] (only for 1-to-Many) (only for 1-to-many) 906 Anti-Replay Window 907 [only for inbound] (only for 1-to-Many) (only for 1-to-many) 908 AH Auth. Algo., keys, etc n/a n/a 910 ESP Encryption algorithm, 911 keys, IV mode, IV, etc. 912 [REQUIRED for ESP 913 implementations] From (26) From (39) 914 Keys from Cat-1 Keys from Cat-1 916 ESP authentication alg., 917 keys, etc [REQUIRED for 918 ESP implementations] From (27) From (40) 919 Keys from Cat-1 Keys from Cat-1 921 Lifetime of this Security 922 Association: Required From (29, 30) From (42, 43) 924 IPsec protocol mode: 925 tunnel, transport or 926 wildcard From (28) From (41) 928 MSEC Policy Token [PAGE 19] 929 Path MTU: [REQUIRED for ? ? 930 all implementations but 931 used only for outbound 932 traffic] 934 6.8 A Complete Group Policy Token 936 In the following, the complete group policy token is presented, parts 937 from which have been presented in then precious three subsections above. 939 TOKEN-ID FIELD 940 (1) Version v1.0 941 (2) Protocol p1.0 942 (3) GroupID IPv4, 224.0.1, 12345678 943 (4) Timestamp 20000316182632Z 944 (5) Expiration Date 20000616182632Z 946 AUTHORIZATION FIELD 947 (6) Group Owner Distinguished Name /C=US/ST=MD/L=Columbia/ 948 O=SPARTA,Inc./ 949 CN=Jane Owner 950 (7) Serial Number 87654321 951 (8) Certificate Type X.509v3-DSS-SHA1 952 (9) Key Length 1024 953 (10) Root CA C=US/ST=MD/L=Columbia/ 954 O=SPARTA,Inc./ 955 CN =John Root 957 (11) GCKS Distinguished Name C=US/ST=MD/L=Columbia/ 958 O=SPARTA,Inc./ 959 CN = Sally Member 961 (12) Certificate Type X.509v3-DSS-SHA1 962 (13) Key Length 1024 963 (14) Root CA C=US/ST=MD/L=Columbia/ 964 O=SPARTA,Inc./ 965 CN =John Root 967 (15) Rekey GCKS Distinguished Name C=US/ST=MD/L=Columbia/ 968 O=SPARTA,Inc./ 969 CN = Johnny Member 970 (16) Certificate Type X.509v3-DSS-SHA1 971 (17) Key Length 1024 972 (18) Root CA C=US/ST=MD/L=Columbia/ 973 O=SPARTA,Inc./ 974 CN =John Root 976 MSEC Policy Token [PAGE 20] 977 ACCESS CONTROL FIELD 978 (19) Permissions employee, projectA 979 (20) Access List Distinguished Name C=US/ST=MD/L=Columbia/ 980 O=SPARTA,Inc./CN = * 981 (21) Certificate Type X.509v3-DSS-SHA1 982 (22) Key Length 1024 983 (23) Root CA C=US/ST=MD/L=Columbia/ 984 O=SPARTA,Inc./ 985 CN =John Root 986 MECHANISMS FIELD 987 (24a) Cat-3 SA SPI 4847474747474747 ... 988 (24) Security Protocol ESP 989 (25) Processing Direction Outgoing 990 (26) ESP Algorithm ESP-DES 991 (27) ESP Authentication HMAC-SHA 992 (28) Encapsulation Mode Tunnel 993 (29) SA Lifetype kilobytes 994 (30) SA Lifetime 1000 995 (31) Source Addr * 996 (32) Destination Addr 224.0.1 (Multicast) 997 (33) Transport Protocol UDP 998 (34) GroupID 224.0.1, 12345678 999 (35) Security Label Reference [7] 1000 (36) Key Creation preplaced (via GSAKMP) 1001 (24a) SPI 4847474747474747 ... 1002 (37) Security Protocol ESP 1003 (38) Processing Direction Incoming 1004 (39) ESP Algorithm ESP-DES 1005 (40) ESP Authentication HMAC-SHA 1006 (41) Encapsulation Mode Tunnel 1007 (42) SA Lifetype kilobytes 1008 (43) SA Lifetime 1000 1009 (44) Source Addr * 1010 (45) Destination Addr 224.0.1, 12345678 1011 (46) Transport Protocol UDP 1012 (47) GroupID 224.0.1, 12345678 1013 (48) Security Label Reference [7] 1014 (49) Key Creation preplaced (via GSAKMP) 1016 (50) Cat-1 SA Security Protocol ESP 1017 (51) Processing Direction Incoming 1018 (52) ESP Algorithm ESP-DES 1019 (53) ESP Authentication HMAC-SHA 1020 (54) Encapsulation Mode Tunnel 1021 (55) SA Lifetype seconds 1022 (56) SA Lifelength 1000 1023 (57) Source Addr * (except multicast) 1024 (58) Destination Addr self 1025 (59) Transport Protocol TCP 1027 MSEC Policy Token [PAGE 21] 1028 (60) Destination Port 555 (GSAKMP) 1029 (61) GroupID 224.0.1, 12345678 1030 (62) Security Label Reference [7] 1031 (63) Key Creation IKE 1032 (64) IKE Encr. Algorithm DES-CBC 1033 (65) IKE Hash Algorithm SHA 1034 (66) IKE Auth. Method DSS-Signature 1035 (67) IKE Group Desc. MODP-1024 1036 (68) IKE Group Type MODP 1037 (69) IKE Group Prime 7 1038 (70) IKE Group Gen. 2 1039 (71) Security Protocol ESP 1040 (72) Processing Direction Outgoing 1041 (73) ESP Algorithm ESP-DES 1042 (74) ESP Authentication HMAC-SHA 1043 (75) Encapsulation Mode Tunnel 1044 (76) SA Lifetype seconds 1045 (77) SA Lifelength 1000 1046 (78) Source Addr self 1047 (79) Destination Addr * (except Multicast) 1048 (80) Transport Protocol TCP 1049 (81) Destination Port 555 (GSAKMP) 1050 (82) GroupID 224.0.1, 12345678 1051 (83) Security Label Reference [7] 1052 (84) Key Creation IKE 1053 (85) IKE Encr. Algorithm DES-CBC 1054 (86) IKE Hash Algorithm SHA 1055 (87) IKE Auth. Method DSS-Signature 1056 (88) IKE Group Desc. MODP-1024 1057 (89) IKE Group Type MODP 1058 (90) IKE Group Prime 7 1059 (91) IKE Group Gen. 2 1061 (92) Cat-2 SA Key Creation Method Diffie-Hellman 1062 (93) D-H n 779 1063 (94) D-H q 2 1064 (95) Key Encr. Algorithm Triple-DES-ECB 1065 (96) Rekey Method LKH 1066 (97) Signature Algorithm DSS 1067 (98) Hash SHA 1069 (99) Cat-2 Bypass Security Protocol IPsec None 1070 (100) Processing Direction Incoming 1071 (101) Source Addr * 1072 (102) Destination Addr * 1073 (103) Transport Protocol * 1074 (104) Destination Port 777 1075 (105) Processing BYPASS 1077 MSEC Policy Token [PAGE 22] 1078 (106) Security Protocol IPsec None 1079 (107) Processing Direction Outgoing 1080 (108) Source Addr self 1081 (109) Destination Addr * 1082 (110) Transport Protocol * 1083 (111) Destination Port 777 1084 (112) Processing BYPASS 1086 SIGNATURE FIELD 1087 (113) Signature Algorithm DSS 1088 (114) Hash SHA 1089 (115) Signature Data 948456945040... 1091 REFERENCES 1093 [BF99] B. Briscoe, I. Fairman, Nark: Receiver-based Multicast, Non- 1094 repudiation and Key Management, Proceedings of ACM E-Commerce'99, 1095 rbriscoe@bt.co.uk. 1097 [BMS99] D. Balenson, D. McGrew, A. Sherman, Key Management for Large 1098 Dynamic Groups: One-Way Function Trees and Amortized Initialization, 1099 http://www.ietf.org/internet-drafts/draft-balenson-groupkeymgmt-oft- 1100 00.txt, February 1999, Work in Progress. 1102 [BR93] M. Bellare, P. Rogaway, Entity Authentication and Key 1103 Distribution, Advances in Cryptology - Crypto '93 Proceedings, Springer- 1104 Verlag, 1993. 1106 [Bris99] B. Briscoe, MARKS: Zero Side Effect Multicast Key Management 1107 using Arbitrarily Revealed Key Sequences, Proceedings of NGC'99, 1108 rbriscoe@bt.co.uk. 1110 [CP99] R. Canetti and B. Pinkas, A taxonomy of multicast security 1111 issues, http://www.ietf.org/internet-drafts/draft-irtf-smug-taxonomy- 1112 01.txt, April 1999, Work in Progress. 1114 [DVW92] Diffie, P. van Oorschot, M. J. Wiener, Authentication and 1115 Authenticated Key Exchanges, Designs, Codes and Cryptography, 2, 107-125 1116 (1992), Kluwer Academic Publishers. 1118 [FS00] N. Ferguson and B. Schneier, A Cryptographic Evaluation of IPsec, 1119 CounterPane, http://www.counterpane.com/ipsec.html. 1121 [HCBD99] T. Hardjono, R. Canetti, M. Baugher, P. Disnmore, Secure IP 1122 Multicast: Problem areas, Framework, and Building Blocks, 1123 http://www.ietf.org/internet-drafts/draft-irtf-smug-framework-00.txt, 1124 Work in Progress 1999. 1126 MSEC Policy Token [PAGE 23] 1127 [HCD99] T. Hardjono, B. Cain, N. Doraswamy, A framework for group key 1128 management for multicast security, http://www.ietf.org/internet- 1129 drafts/draft-ietf-ipsec-gkmframework-01.txt, July 1999, Work in 1130 Progress. 1132 [HH99a] H. Harney, E. Harder, Multicast Security Management Protocol 1133 (MSMP) Requirements and Policy, draft-harney-msmp-sec-00.txt, March 1134 1999, Work in Progress. 1136 [HH99b] H. Harney, E. Harder, Group Secure Association Key Management 1137 Protocol, http://search.ietf.org/internet-drafts/draft-harney-sparta- 1138 gsakmp-sec-00.txt, April 1999, Work in Progress. 1140 [Kraw96] H. Krawczyk, SKEME: A Versatile Secure Key Exchange Mechanism 1141 for Internet, ISOC Secure Networks and Distributed Systems Symposium, 1142 San Diego, 1996. 1144 [RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A 1145 Transport Protocol for Real-Time Applications, January 1996. 1147 [RFC2093] Harney, H., and Muckenhirn, C., "Group Key Management Protocol 1148 (GKMP) Specification," RFC 2093, July 1997. 1150 [RFC2094] Harney, H., and Muckenhirn, C., "Group Key Management Protocol 1151 (GKMP) Architecture," RFC 2094, July 1997. 1153 [RFC2401] S. Kent, R. Atkinson, Security Architecture for the Internet 1154 Protocol, November 1998 1156 [RFC2407] D. Piper, The Internet IP Domain of Interpretation for ISAKMP, 1157 November 1998. 1159 [RFC2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, Internet 1160 Security Association and Key Management Protocol, November 1998. 1162 [RFC2409] D. Harkins, D. Carrel, The Internet Key Exchange (IKE), 1163 November, 1998. 1165 [RFC2412] H. Orman, The OAKLEY Key Determination Protocol, November 1166 1998. 1168 [RFC2522] P. Karn, W. Simpson, Photuris: Session-Key Management 1169 Protocol, March 1999. 1171 [RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for 1172 Multicast: Issues and Architectures, September 1998. 1174 [SDNS88] H. L. Rogers, An Overview of the CANEWARE Program, 10th 1175 National Security Conference, National Security Agency, 1988. 1177 MSEC Policy Token [PAGE 24] 1178 [WL98] C.K.Wong, S.S. Lam, Digital Signatures for Flows and Multicasts, 1179 Proceedings of IEEE ICNP'98, October 14-16, 1998. 1181 Authors Address: 1183 Thomas Hardjono 1184 VeriSign 1185 401 Edgewater Pl, Suite 280 1186 Wakefield, MA 01880, USA 1187 thardjono@verisign.com 1189 Hugh Harney 1190 SPARTA, Inc. 1191 Secure Systems Engineering Division 1192 9861 Broken Land Parkway, Suite 300 1193 Columbia, MD 21046-1170, USA 1194 +1 410 381 9400 (ext. 203) 1195 hh@columbia.sparta.com 1197 Patrick McDaniel 1198 Department of Electrical Engineering and Computer Science 1199 University of Michigan 1200 3115 EECS Building 1201 1301 Beal Avenue 1202 Ann Arbor, MI 48109 1203 pdmcdan@eecs.umich.edu 1205 Andrea Colgrove 1206 SPARTA, Inc. 1207 Secure Systems Engineering Division 1208 9861 Broken Land Parkway, Suite 300 1209 Columbia, MD 21046-1170, USA 1210 +1 410 381 9400 (ext. 203) 1211 ac@columbia.sparta.com 1213 Peter Dinsmore 1214 NAI Labs 1215 3060 Washington Road, 1216 Glenwood, MD 21738 1217 (443) 259-2346 1218 Pete_Dinsmore@NAI.com 1220 MSEC Policy Token [PAGE 26]