idnits 2.17.1 draft-ietf-msec-policy-token-sec-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 1433. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1455. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** An RFC 3978, Section 5.1 paragraph was found, but not on the first page, as required. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 163: '...he specified policy, the Token MUST be...' RFC 2119 keyword, line 164: '...The signed token MUST be in accordance...' RFC 2119 keyword, line 173: '...e the signature, MUST be that of the G...' RFC 2119 keyword, line 175: '...ignedAttrs field MUST be present. In ...' RFC 2119 keyword, line 176: '...rs, the signing-time attribute MUST be...' (30 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (January 2006) is 6675 days in the past. Is this intentional? 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: 'RFC3740' is mentioned on line 112, but not defined -- Looks like a reference, but probably isn't: '0' on line 1332 -- Looks like a reference, but probably isn't: '1' on line 1333 -- Looks like a reference, but probably isn't: '2' on line 1207 -- Looks like a reference, but probably isn't: '3' on line 1208 == Unused Reference: 'HCLM00' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'RFC 3711' is defined on line 431, but no explicit reference was found in the text == Unused Reference: 'RFC 3740' is defined on line 435, but no explicit reference was found in the text == Unused Reference: 'HCM01' is defined on line 438, but no explicit reference was found in the text == Unused Reference: 'HHMCD01' is defined on line 442, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3825 (ref. 'RFC 3852') (Obsoleted by RFC 6225) == Outdated reference: A later version (-02) exists of draft-ietf-msec-gspt-00 Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 INTERNET-DRAFT A Colegrove 4 H Harney 5 draft-ietf-msec-policy-token-sec-06.txt SPARTA, Inc. 6 Expires: July 23, 2006 January 2006 8 Group Security Policy Token v1 10 Status of this memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note 19 that other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at 24 any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 The Group Security Policy Token is a structure used to 36 specify the security policy and configurable parameters 37 for a cryptographic group, such as a secure multicast 38 group. Because the security of a group is comprised of 39 the totality of multiple security services, mechanisms, and 40 attributes throughout the communications infrastructure, 41 an authenticatable representation of the features that 42 must be supported throughout the system is needed to ensure 43 consistent security. This document specifies the structure 44 of such a token. 46 Contents 48 1 Introduction 5 50 2 Token Creation and Receipt 6 51 3 The Policy Token 6 52 3.1 Token Identifiers . . . . . . . . . . . . . . . . . . . . . 8 53 3.2 Registration Policy . . . . . . . . . . . . . . . . . . . . 8 54 3.3 Rekey Policy . . . . . . . . . . . . . . . . . . . . . . . 9 55 3.4 Group Data Policy . . . . . . . . . . . . . . . . . . . . . 10 57 4 Security Considerations 10 58 5 IANA Considerations 10 60 6 References 11 61 6.1 Normative References . . . . . . . . . . . . . . . . . . . 11 62 6.2 Non-Normative References . . . . . . . . . . . . . . . . . 12 64 7 Acknowledgments 12 65 A APPENDIX A -- Core Policy Token ASN.1 Module 13 67 B APPENDIX B -- GSAKMPv1 Base Policy 15 68 B.1 GSAKMPv1 Registration Policy . . . . . . . . . . . . . . . 15 69 B.1.1 Authorization . . . . . . . . . . . . . . . . . . . . . 15 70 B.1.2 AccessControl . . . . . . . . . . . . . . . . . . . . . 17 71 B.1.3 JoinMechanisms . . . . . . . . . . . . . . . . . . . . 17 72 B.1.3.1 alaCarte . . . . . . . . . . . . . . . . . . . . 18 73 B.1.3.2 suite . . . . . . . . . . . . . . . . . . . . . . 19 74 B.1.4Transport . . . . . . . . . . . . . . . . . . . . . . . 20 75 B.2 GSAKMPv1 Registration ASN.1 Module . . . . . . . . . . . . 20 76 B.3 GSAKMPv1 De-Registration Policy . . . . . . . . . . . . . . 23 77 B.4 GSAKMPv1 De-Registration ASN.1 Module . . . . . . . . . . . 24 78 B.5 GSAKMPv1 Rekey Policy . . . . . . . . . . . . . . . . . . . 24 79 B.5.1 Rekey Authorization . . . . . . . . . . . . . . . . . . 25 80 B.5.2 Rekey Mechanisms . . . . . . . . . . . . . . . . . . . 25 81 B.5.3 Rekey Event Definition . . . . . . . . . . . . . . . . 26 82 B.5.4 Rekey Methods . . . . . . . . . . . . . . . . . . . . . 27 83 B.5.4.1 Rekey Method NONE . . . . . . . . . . . . . . . . 27 84 B.5.4.2 Rekey Method GSAKMP LKH . . . . . . . . . . . . . 27 85 B.5.5 Rekey Interval . . . . . . . . . . . . . . . . . . . . 28 86 B.5.6 Rekey Reliability . . . . . . . . . . . . . . . . . . . 28 87 B.5.6.1 Rekey Reliability Mechanism None . . . . . . . . 28 88 B.5.6.2 Rekey Reliability Mechanism Resend . . . . . . . 28 89 B.5.6.3 Rekey Reliability Mechanism Post . . . . . . . . 29 90 B.5.7 Distributed Operation Policy . . . . . . . . . . . . . 29 91 B.5.7.1 No Distributed Operation . . . . . . . . . . . . 29 92 B.5.7.2 Autonomous Distributed Mode . . . . . . . . . . . 30 93 B.6 GSAKMPv1 Rekey Policy ASN.1 Module . . . . . . . . . . . . 30 94 C APPENDIX C -- Data SA Policy 33 95 C.1 Generic Data Policy . . . . . . . . . . . . . . . . . . . . 33 96 C.2 Generic Data Policy ASN.1 Module . . . . . . . . . . . . . 34 98 D APPENDIX D -- Change History (To Be Removed from RFC) 34 99 D.1 Changes from Group Policy Token v-00 to v-01, December 2004 34 100 D.2 Changes from Group Policy Token v-01 to v-02, March 2005 . 35 101 D.3 Changes from Group Policy Token v-02 to v-03, July 2005 . . 35 102 D.4 Changes from Group Policy Token v-03 to v-04, September 2005 35 103 D.5 Changes from Group Policy Token v-04 to v-05, December 2005 35 104 D.6 Changes from Group Policy Token v-05 to v-06, January 2006 35 106 Authors Addresses 37 107 Full Copyright Statement 37 109 IPR Considerations 37 110 1 Introduction 112 The Multicast Group Security Architecture [RFC3740] defines the 113 security infrastructure to support secure group communications. The 114 Policy Token assumes this architecture in its definition. It defines 115 the enforceable security parameters for a Group Secure Association. 117 The Policy Token is a verifiable data construct signed by the group 118 owner, the entity with the authorization to create security policy. 119 The group controllers in a group will use the policy token to ensure 120 that the mechanisms used to secure the group are correct and to 121 enforce the access control rules for joining members. The group 122 members, who may contribute data to the group or access data from the 123 group, will use the policy token to ensure that the group is owned by 124 a trusted authority. Also, the members may want to verify that the 125 access control rules are adequate to protect the data that the member 126 is submitting to the group. 128 The Policy Token is specified in ASN.1 [X.208] and is to be DER 129 [X.660] encoded. This specification ability allows the token to 130 easily import group definitions that span different applications and 131 environments. ASN.1 allows the token to specify branches that can 132 be used by any multicast security protocol. Any group can use this 133 policy token structure to specify the use of multiple protocols in 134 securing the group. 136 Care was taken in this specification to provide a core level of token 137 specificity that would allow ease of extensibility and flexibility 138 in supporting mechanisms. This was done by using the following 139 abstracted construct: 141 Mechanism ::= SEQUENCE { 142 mechanismIdentifier OBJECT IDENTIFIER, 143 mechanismParameters OCTET STRING 144 } 146 This construct will allow the use of group mechanisms specified in 147 other documents with the Policy Token. 149 The Policy Token is structured to reflect the MSEC Architecture 150 layers for a Group Security Association. Each of the architectural 151 layers is identified and given a branch in the "Core" token. 152 This allows a high degree of flexibility for future protocol 153 specifications at each architectural layer without the need to change 154 the "Core" policy token, which can then act as a single point of 155 reference for defining secure groups using any mix of protocols for 156 any number of environments. 158 2 Token Creation and Receipt 160 At the time of group creation or whenever the policy of the group is 161 updated, the Group Owner will create a new policy token. 163 To ensure authenticity of the specified policy, the Token MUST be 164 signed by the Group Owner. The signed token MUST be in accordance 165 with the CMS [RFC 3852] SignedData type. 167 The content of the SignedData is the token itself. It is represented 168 with the ContentType object identifier of 170 id-ct-msec-token OBJECT IDENTIFIER ::= {TBD} 172 The CMS sid value of the SignerInfo, which identifies the public key 173 needed to validate the signature, MUST be that of the Group Owner. 175 The signedAttrs field MUST be present. In addition to the minimally 176 required fields of signedAttrs, the signing-time attribute MUST be 177 present. 179 Upon receipt of a Policy Token, the recipient MUST check that 181 - the Group Owner, as identified by the sid in the SignerInfo, is 182 the expected entity 184 - the signing-time value is more recent than the signing-time value 185 seen in a previously received Policy Token for that group, or the 186 Policy Token is the first token seen by the recipient for that 187 group. 189 - the processing of the signature successfully validates in 190 accordance with RFC 3852 192 - the specified security and communication mechanisms (or at least 193 one mechanism of each choice) are supported and are in compliance 194 with the recipient's local policy. 196 3 The Policy Token 198 The structure of the Policy Token is as follows: 200 Token ::= SEQUENCE { 201 tokenInfo TokenID, 202 registration SEQUENCE OF Registration, 203 rekey SEQUENCE OF GroupMngmtProtocol, 204 data SEQUENCE OF DataProtocol 205 } 207 tokenInfo provides information about the instance of the Policy 208 Token (PT). 210 registration provides a list of acceptable registration and 211 deregistration policy and mechanisms that may be used to manage 212 member-initiated joins and departures from a group. A NULL 213 sequence indicates that the group does not support registration 214 and deregistration of members. A member MUST be able to support 215 at least one set of Registration mechanisms in order to join 216 the group. When multiple mechanisms are present, a member MAY 217 use any of the listed methods. The list is ordered in terms of 218 Group Owner preference. A member MUST choose the highest listed 219 mechanism that local policy supports. 221 rekey provides the rekey protocols that will be used in managing 222 the group. The member MUST be able to accept one of the types 223 of rekey messages listed. The list is ordered in terms of 224 Group Owner preference. A member MUST choose the highest listed 225 mechanism that local policy supports. 227 data provides the applications used in the communications between 228 group members. When multiple applications are provided, the 229 order of the list implies the order of encapsulation of the data. 230 A member MUST be able to support all the listed applications and 231 if any choices of mechanisms are provided per application, the 232 member MUST support at least one of the mechanisms. 234 For the registration, rekey, and data fields, implementations 235 encountering unknown protocol identifiers MUST handle this gracefully 236 by providing indicators that an unknown protocol is among the 237 sequence of permissible protocols. If the unknown protocol is the 238 only allowable protocol in the sequence, then the implementation 239 cannot support that field, and the member cannot join the group. 240 It is a matter of local policy whether a join is permitted when an 241 unknown protocol exists among the allowable, known protocols. 243 Protocols in addition to registration, rekey, and data SHOULD NOT 244 be added to subsequent versions of this Token unless the MSEC 245 architecture changes. 247 Each data field of the PT is specified further in the following 248 sections. 250 3.1 Token Identifiers 252 tokenInfo explicitly identifies a version of the Policy Token for a 253 particular group. It is defined as 255 TokenID ::= SEQUENCE { 256 tokenDefVersion INTEGER (1), 257 groupName OCTET STRING, 258 edition INTEGER OPTIONAL 259 } 261 tokenDefVersion is the version of the Group Policy Token 262 Specification. This specifications (v1) is represented as one 263 (1). Changes to the structure of the Group Security Policy Token 264 will require an update to this field. 266 groupName is the identifier of the group and MUST be unique relative 267 to the Group Owner. 269 edition is an optional INTEGER indicating the sequence number of the 270 PT. If edition is present, group entities MUST accept a PT only 271 when the value is greater than the last value seen in a valid PT 272 for that group. 274 The type LifeDate is also defined to provide standard methods of 275 indicating timestamps and intervals in the Tokens. 277 LifeDate ::= CHOICE { 278 gt GeneralizedTime, 279 utc UTCTime, 280 interval INTEGER 281 } 283 3.2 Registration Policy 285 The registration SA is defined in the MSEC Architecture. During 286 registration, a prospective group member and the group controller 287 will interact to give the group member access to the keys and 288 information it needs to join the group and participate in the group 289 data SA. 291 The deregistration piece allows a current group member to notify the 292 GC/KS that it will no longer be participating in the data SA. 294 Registration ::= SEQUENCE { 295 register GroupMngmtProtocol, 296 de-register GroupMngmtProtocol 297 } 299 The protocol for registration and de-registration are each specified 300 as 302 GroupMngmtProtocol ::= CHOICE { 303 none NULL, 304 supported Protocol 305 } 307 Protocol ::= SEQUENCE { 308 protocol OBJECT IDENTIFIER, 309 protocolInfo OCTET STRING 310 } 312 For example, register might be specified as the GSAKMP [HMCG] 313 registration protocol. The OBJECT IDENTIFIER TBS would be followed 314 by the parameters used in GSAKMP registration as specified in 315 appendix B.1. 317 3.3 Rekey Policy 319 The Rekey SA is defined in the MSEC Architecture. During the Rekey 320 of a group, several changes can potentially be made: 322 - refresh/change group protection keys, 324 - update the Policy Token, 326 - change the group membership. 328 During Rekey, the membership of the group can be modified as well as 329 refreshing the group traffic protection keys and updating the Policy 330 Token. 332 This field is also specified as a sequence of protocols that will be 333 used by the GC/KS. 335 3.4 Group Data Policy 337 The Data SA is the ultimate consumer of the group keys. The data 338 field will indicate the keys and mechanisms that are to be used in 339 communications between group members. There are several protocols 340 that could make use of group keys, ranging from simple security 341 applications that only need key for encryption and/or integrity 342 protection to more complex configurable security protocols such as 343 IPsec and SRTP. The sequencing of the Data SA mechanisms are from 344 "inside" to "outside". That is, the first Data SA defined in a 345 policy token must act on the raw data. Any data SA specified after 346 that will be applied in turn. 348 DataProtocol ::= Protocol 350 4 Security Considerations 352 This document specifies the structure for a Group Policy Token. As 353 such, the structure as received by a group entity must be verifiably 354 authentic. This Policy Token uses CMS to apply authentication 355 through digital signatures. The security of this scheme relies 356 upon a secure CMS implementation, choice of signature mechanism 357 of appropriate strength for the group using the Policy Token, 358 and secure, sufficiently strong keys. Additionally, it relies 359 upon knowledge of a well-known Group Owner as the root of policy 360 enforcement. 362 Furthermore, while the Group Owner may list alternate mechanisms 363 for various functions, the group is only as strong as the weakest 364 accepted mechanisms. As such, the Group Owner is responsible for 365 providing only acceptable security mechanisms. 367 5 IANA Considerations 369 The following object identifiers should be assigned: 371 - id-ct-msec-token OBJECT IDENTIFIER ::= TBD 373 - id-securitySuiteOne OBJECT IDENTIFIER ::= TBD 375 - id-GSAKMPv1RegistrationProtocol OBJECT IDENTIFIER::= TBD 377 - id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= TBD 378 - id-GSAKMPv1Rekey OBJECT IDENTIFIER::= TBD 380 - id-rekeyNone OBJECT IDENTIFIER ::= TBD 382 - id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= TBD 384 - id-reliabilityNone OBJECT IDENTIFIER ::= TBD 386 - id-reliabilityResend OBJECT IDENTIFIER ::= TBD 388 - id-reliabilityPost OBJECT IDENTIFIER ::= TBD 390 - id-subGCKSSchemeNone OBJECT IDENTIFIER ::= TBD 392 - id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= TBD 394 - id-genericDataSA OBJECT IDENTIFIER ::= TBD 396 The Group Security Policy Token can be extended through 397 specification. Extensions in the form of objects can be registered 398 through IANA. Extensions requiring changes to the protocol structure 399 will require an update to the tokenDefVersion field of the TokenID 400 (see section 3.1). 402 6 References 404 The following references were used in the preparation of this 405 document. 407 6.1 Normative References 409 [HMCG] H. Harney, U. Meth, A. Colegrove, and G. Gross, "GSAKMP", 410 draft-ietf-msec-gsakmp-sec-10.txt, RFC Editor Queue, May 2005. 412 [RFC 3280] R. Housley, W. Polk, W. Ford, D. Solo, Internet X.509 413 Public Key Infrastructure Certificate and Certificate Revocation List 414 (CRL) Profile, RFC 3280, April 2002. 416 [RFC 3852] R. Housley, Cryptographic Message Syntax, RFC 3825, July 417 2004. 419 [X.208] Recommendation X.209, Specification of Abstract Syntax 420 Notation One (ASN.1), 1988. 422 [X.660] Recommendation X.660, Information Technology ASN.1 Encoding 423 Rules: Specification of Basic Encoding Rules (BER), Canonical 424 Encoding Rules (CER), and Distinguished Encoding Rules (DER), 1997. 426 6.2 Non-Normative References 428 [HCLM00] H. Harney, A. Colegrove, P. Lough, and U. Meth, "GSAKMP 429 Token Specification", draft-ietf-msec-tokenspec-sec-00.txt. 431 [RFC 3711] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. 432 Norrman, "The Secure Real-Time Transport Protocol (SRTP)", RFC 3711, 433 March 2004. 435 [RFC 3740] T. Hardjono and B. Weis, "The Multicast Group Security 436 Architecture", RFC 3740, March 2004. 438 [HCM01] H. Harney, A. Colegrove, P. McDaniel, "Principles of Policy 439 in Secure Groups", Proceedings of Network and Distributed Systems 440 Security 2001 Internet Society, San Diego, CA, February 2001 442 [HHMCD01] , Thomas Hardjono, Hugh Harney, Pat McDaniel, Andrea 443 Colgrove, Pete Dinsmore, Group Security Policy Token: Definition and 444 Payloads', draft-ietf-msec-gspt-00.txt, Expired. 446 7 Acknowledgments 448 The following individuals deserve recognition and thanks for their 449 contributions which have greatly improved this specification: Uri 450 Meth whose knowledge of GSAKMP and tokens was greatly appreciated 451 as well as his help in getting this document submitted; Peter Lough, 452 Thomas Hardjono, Patrick McDaniel, and Pete Dinsmore for their work 453 on earlier versions of policy tokens; George Gross for the impetus to 454 have a well-specified, extensible policy token; and Rod Fleischer for 455 catching implementation issues. 457 A APPENDIX A -- Core Policy Token ASN.1 Module 459 PolicyToken -- {TBD} 461 DEFINITIONS IMPLICIT TAGS ::= 463 BEGIN 465 Token ::= SEQUENCE { 466 tokenInfo TokenID, 467 registration SEQUENCE OF Registration, 468 rekey SEQUENCE OF GroupMngmtProtocol, 469 data SEQUENCE OF DataProtocol 470 } 472 ------------------------------------------------------------ 473 -- Token ID 475 TokenID ::= SEQUENCE { 476 tokenDefVersion INTEGER (1), -- Group Security Policy Token v1 477 groupName OCTET STRING, 478 edition INTEGER OPTIONAL 479 } 481 LifeDate ::= CHOICE { 482 gt GeneralizedTime, 483 utc UTCTime, 484 interval INTEGER 485 } 487 ------------------------------------------------------------ 488 -- Registration 490 Registration ::= SEQUENCE { 491 register GroupMngmtProtocol, 492 de-register GroupMngmtProtocol 493 } 495 ------------------------------------------------------------ 496 -- GroupMngmtProtocol 498 GroupMngmtProtocol ::= CHOICE { 499 none NULL, 500 supported Protocol 501 } 503 Protocol ::= SEQUENCE { 504 protocol OBJECT IDENTIFIER, 505 protocolInfo OCTET STRING 507 } 509 ------------------------------------------------------------ 510 -- DataProtocol 512 DataProtocol ::= Protocol 514 ------------------------------------------------------------ 516 END 518 B APPENDIX B -- GSAKMPv1 Base Policy 520 This appendix provides the data structures needed for when GSAKMP 521 exchanges are used as the GroupMngmtProtocol for the registration, 522 de-registration, and/or rekey SAs. This GSAKMP Base Policy 523 specification assumes familiarity with GSAKMP. 525 B.1 GSAKMPv1 Registration Policy 527 When GSAKMP is used in the Group Management Protocol for 528 registration, the following object identifier is used in the core 529 token. 531 id-GSAKMPv1RegistrationProtocol OBJECT IDENTIFIER::= {TBD} 533 The registration policy for GSAKMP provides 1) information on 534 authorizations for group roles; 2) access control information for 535 group members; 3) the mechanisms used in the registration process, 536 and 4) information on what transport the GSAKMP registration exchange 537 will use. 539 GSAKMPv1RegistrationInfo ::= SEQUENCE { 540 joinAuthorization JoinAuthorization, 541 joinAccessControl SEQUENCE OF AccessControl, 542 joinMechanisms JoinMechanisms, 543 transport Transport 544 } 546 B.1.1 Authorization 548 joinAuthorization provides information on who is allowed to be a 549 Group Controller/Key Server (GC/KS) and a sub-GC/KS. It also 550 can indicate if there are limitations on who can send data in a 551 group. 553 JoinAuthorization ::= SEQUENCE { 554 gCKS GCKSName, 555 subGCKS SEQUENCE OF GCKSName OPTIONAL, 556 senders SenderAuthorization 557 } 559 The authorization information is in the form of an access control 560 list indicating entity name and acceptable certification authority 561 information for the entity's certificate. 563 GCKSName ::= SEQUENCE OF UserCAPair 565 UserCAPair ::= SEQUENCE { 566 groupEntity GSAKMPID, 567 cA CertAuth 568 } 570 groupEntity is defined by type and value. The types are indicated 571 by integers that correspond to the GSAKMP Identification types. 572 When a portion of a defined name type is filled with an "*", this 573 indicates a wildcard, representing any valid choice for a field. 574 This allows the specification of an authorization rule that is a 575 set of related names. 577 GSAKMPID ::= SEQUENCE { 578 typeValue INTEGER, 579 typeData OCTET STRING 580 } 582 The certificate authority is identified by the X.509 [RFC 3280] key 583 identifier. 585 CertAuth ::= KeyIdentifier 587 Senders within a group can either be all - indicating no sender 588 restrictions or can be an explicit list of those members authorized 589 to send data. 591 SenderAuthorization ::= CHOICE { 592 all [0] NULL, 593 limited [1] EXPLICIT SEQUENCE OF UserCAPair 594 } 596 B.1.2 AccessControl 598 joinAccessControl provides information on who is allowed to be a 599 Group Member. The access control list is implemented as a set 600 of permissions that the member must satisfy and a list of name 601 rules and the certificate authority that each must satisfy. 602 Additionally, a list of exclusions to the list may be provided. 604 AccessControl ::= SEQUENCE { 605 permissions [1] EXPLICIT SEQUENCE OF Permission OPTIONAL, 606 accessRule [2] EXPLICIT SEQUENCE OF UserCAPair, 607 exclusionsRule [3] EXPLICIT SEQUENCE OF UserCAPair OPTIONAL 608 } 610 The permissions initially available are an abstract set of numeric 611 levels that may be interpreted internal to a community. 613 Permission ::= CHOICE { 614 simplePermission [1] SimplePermission 615 } 617 SimplePermission ::= ENUMERATED { 618 one(1), 619 two(2), 620 three(3), 621 four(4), 622 five(5), 623 six(6), 624 seven(7), 625 eight(8), 626 nine(9) 627 } 629 B.1.3 JoinMechanisms 631 Allowable GSAKMP mechanism choices for a particular group are 632 specified in joinMechanisms. Any set of JoinMechanism is acceptable 633 from a policy perspective. 635 JoinMechanisms ::= SEQUENCE OF JoinMechanism 637 Each set of mechanisms used in the GSAKMP Registration may be 638 specified either as an explicitly defined set or as a pre-defined 639 security suite. 641 JoinMechanism ::= CHOICE { 642 alaCarte [0] Mechanisms, 643 suite [1] SecuritySuite 644 } 646 B.1.3.1 alaCarte 648 In an explicitly defined -- or alaCarte -- set, a mechanism 649 is defined for the signature, the key exchange algorithm, the 650 key wrapping algorithm, the type of acknowledgment data, and 651 configuration data for the setting of timeouts. 653 Mechanisms ::= SEQUENCE { 654 signatureDef SigDef, 655 kEAlg KEAlg, 656 keyWrap KeyWrap, 657 ackData AckData, 658 opInfo OpInfo 659 } 661 The signature definition requires specification of the signature 662 algorithm for message signing. The INTEGER that defines the choice 663 corresponds to the GSAKMP Signature type. 665 SigDef ::= SEQUENCE { 666 sigAlgorithmID INTEGER, 667 hashAlgorithmID INTEGER 668 } 670 The INTEGER corresponding to hashAlgorithm will map to the GSAKMP 671 Nonce Hash type values. This algorithm is used in computing the 672 combined nonce. 674 The key exchange algorithm requires an integer to define the GSAKMP 675 key creation type and may require additional per type data. 677 KEAlg ::= SEQUENCE { 678 keyExchangeAlgorithmID INTEGER, 679 keyExchangeAlgorithmData OCTET STRING OPTIONAL 680 } 682 The keyWrap is the algorithm that is used to wrap the group key(s) 683 and the policy token (if included). The integer corresponds to the 684 GSAKMP encryption type. 686 KeyWrap ::= INTEGER 688 Data may potentially be returned in a GSAKMP Key Download ACK/Failure 689 message. The type of data required by a group is specified by 690 AckData. No such field is currently supported or required. 692 AckData ::= CHOICE { 693 none [0] NULL 694 } 696 OpInfo provides configuration data for the operation of GSAKMP 697 registration. timeOut indicates the elapsed amount of time 698 before a sent message is considered to be misrouted or lost. It 699 is specified as the timestamp type LifeDate, previously defined 700 in the core token. terse informs a GC/KS whether the group 701 should be operated in terse (TRUE) or verbose (FALSE) mode. 703 OpInfo ::= SEQUENCE { 704 timeOut LifeDate, 705 terse BOOLEAN 706 } 708 B.1.3.2 suite 710 If the choice of mechanism for the join is a predefined security 711 suite, then it is identified by OBJECT IDENTIFIER (OID). Other 712 security suites may be defined elsewhere by specification and 713 registration of an OID. 715 SecuritySuite ::= OBJECT IDENTIFIER 717 The OID for security suite 1, as defined within the GSAKMPv1 718 specification is 720 id-securitySuiteOne OBJECT IDENTIFIER ::= {TBD} 722 B.1.4 Transport 724 transport indicates what protocol GSAKMP should ride over. The 725 choice of udpRTJtcpOther indicates that the GSAKMP Request to 726 Join message is carried by UDP and all other group establishment 727 messages are carried by TCP. 729 Transport ::= CHOICE { 730 tcp [0] NULL, 731 udp [1] NULL, 732 udpRTJtcpOther [2] NULL 733 } 735 B.2 GSAKMPv1 Registration ASN.1 Module 737 GSAKMPv1RegistrationSA -- {TBD} 739 DEFINITIONS IMPLICIT TAGS ::= 741 BEGIN 742 EXPORTS 743 GCKSName; 745 IMPORTS 746 LifeDate 747 FROM PolicyToken {TBD} 749 KeyIdentifier 750 FROM PKIX1Implicit88 { iso(1) identified-organization(3) 751 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 752 id-mod(0) id-pkix1-implicit(19) }; 754 -- id-GSAKMPv1RegistrationProtocol OBJECT IDENTIFIER::= {TBD} 756 GSAKMPv1RegistrationInfo ::= SEQUENCE { 757 joinAuthorization JoinAuthorization, 758 joinAccessControl SEQUENCE OF AccessControl, 759 joinMechanisms JoinMechanisms, 760 transport Transport 762 } 764 JoinAuthorization ::= SEQUENCE { 765 gCKS GCKSName, 766 subGCKS SEQUENCE OF GCKSName OPTIONAL, 767 senders SenderAuthorization 768 } 770 GCKSName ::= SEQUENCE OF UserCAPair 772 UserCAPair ::= SEQUENCE { 773 groupEntity GSAKMPID, 774 cA CertAuth 775 } 777 CertAuth ::= KeyIdentifier 779 SenderAuthorization ::= CHOICE { 780 all [0] NULL, 781 limited [1] EXPLICIT SEQUENCE OF UserCAPair 782 } 784 AccessControl ::= SEQUENCE { 785 permissions [1] EXPLICIT SEQUENCE OF Permission OPTIONAL, 786 accessRule [2] EXPLICIT SEQUENCE OF UserCAPair, 787 exclusionsRule [3] EXPLICIT SEQUENCE OF UserCAPair OPTIONAL 788 } 790 Permission ::= CHOICE { 791 simplePermission [1] SimplePermission 792 } 794 SimplePermission ::= ENUMERATED { 795 one(1), 796 two(2), 797 three(3), 798 four(4), 799 five(5), 800 six(6), 801 seven(7), 802 eight(8), 803 nine(9) 804 } 806 GSAKMPID ::= SEQUENCE { 807 typeValue INTEGER, 808 typeData OCTET STRING 809 } 811 JoinMechanisms ::= SEQUENCE OF JoinMechanism 812 JoinMechanism ::= CHOICE { 813 alaCarte [0] Mechanisms, 814 suite [1] SecuritySuite 815 } 817 Mechanisms ::= SEQUENCE { 818 signatureDef SigDef, 819 kEAlg KEAlg, 820 keyWrap KeyWrap, 821 ackData AckData, 822 opInfo OpInfo 823 } 825 SecuritySuite ::= OBJECT IDENTIFIER 827 -- SECURITY SUITE ONE -- 828 -- id-securitySuiteOne OBJECT IDENTIFIER ::= {TBD} 830 SigDef ::= SEQUENCE { 831 sigAlgorithmID INTEGER, 832 hashAlgorithmID INTEGER 833 } 835 KEAlg ::= SEQUENCE { 836 keyExchangeAlgorithmID INTEGER, 837 keyExchangeAlgorithmData OCTET STRING OPTIONAL 838 } 840 KeyWrap ::= INTEGER 842 AckData ::= CHOICE { 843 none [0] NULL 844 } 846 OpInfo ::= SEQUENCE { 847 timeOut LifeDate, 848 terse BOOLEAN 849 } 851 Transport ::= CHOICE { 852 tcp [0] NULL, 853 udp [1] NULL, 854 udpRTJtcpOther [2] NULL 855 } 857 END 859 B.3 GSAKMPv1 De-Registration Policy 861 GSAKMP De-Registration provides a method to notify a (S-)GC/KS that 862 a member needs to leave a group. When GSAKMP is the De-Registration 863 Protocol for the Group, the following object identifier is used in 864 the core token. 866 id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= {TBD} 868 The De-Registration policy provides the mechanisms needed for the 869 De-Registration exchange messages, an indication of whether the 870 exchange is to be done using terse (TRUE) or verbose (FALSE) mode, 871 and the transport used for the GSAKMP De-registration messages. 873 GSAKMPv1DeRegistrationInfo ::= SEQUENCE { 874 leaveMechanisms SEQUENCE OF LeaveMechanisms, 875 terse BOOLEAN, 876 transport Transport 877 } 879 The policy dictating the mechanisms needed for the De-registration 880 exchange is defined by leaveMechanisms. This field is specified as 882 LeaveMechanisms ::= SEQUENCE { 883 sigAlgorithm INTEGER, 884 hashAlgorithm INTEGER, 885 cA KeyIdentifier 886 } 888 The INTEGER corresponding to sigAlgorithm will map to the GSAKMP 889 Signature type values. This algorithm set is to be used for message 890 signing. 892 The INTEGER corresponding to hashAlgorithm will map to the GSAKMP 893 Nonce Hash type values. This algorithm is used in computing the 894 combined nonce. 896 cA represents a trust point off of which the signer's certificate 897 must certify. It is identified by the PKIX KeyIdentifier [RFC 3280] 898 type. 900 transport will provide the expected transport for GSAKMP 901 De-registration messages. Initially, either UDP or TCP will be the 902 policy for a group. 904 Transport ::= CHOICE { 905 tcp [0] NULL, 906 udp [1] NULL 907 } 909 B.4 GSAKMPv1 De-Registration ASN.1 Module 911 GSAKMPv1DeRegistrationSA -- {TBD} 913 DEFINITIONS IMPLICIT TAGS ::= 915 BEGIN 917 IMPORTS 918 KeyIdentifier 919 FROM PKIX1Implicit88 { iso(1) identified-organization(3) 920 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 921 id-mod(0) id-pkix1-implicit(19) }; 923 -- id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= {TBD} 925 GSAKMPv1DeRegistrationInfo ::= SEQUENCE { 926 leaveMechanisms SEQUENCE OF LeaveMechanisms, 927 transport Transport 928 } 930 LeaveMechanisms ::= SEQUENCE { 931 sigAlgorithm INTEGER, 932 hashAlgorithm INTEGER, 933 cA KeyIdentifier 934 } 936 Transport ::= CHOICE { 937 tcp [0] NULL, 938 udp [1] NULL 939 } 941 END 943 B.5 GSAKMPv1 Rekey Policy 945 When GSAKMP is used as the Rekey Protocol for the Group, the 946 following object identifier should be used in the core token as the 947 rekey protocol: 949 id-GSAKMPv1Rekey OBJECT IDENTIFIER::= {TBD} 951 The GSAKMP Rekey Policy provides authorization information, 952 mechanisms for the GSAKMP Rekey messages, indicators defining rekey 953 event definitions that define when the GC/KS should send a rekey 954 message, the protocol or method the rekey event will use, the rekey 955 interval that will allow a member to recognize a failure in the rekey 956 process, a reliability indicator that defines the method the rekey 957 will use to increase the likelihood of a rekey delivery (if any), and 958 finally an indication of how subordinate-GC/KSs will handle rekey. 959 This policy also describes the specific Rekey policy methods "None" 960 and "GSAKMP LKH REKEY". 962 GSAKMPv1RekeyInfo ::= SEQUENCE { 963 authorization RekeyAuthorization, 964 mechanism RekeyMechanisms, 965 rekeyEventDef RekeyEventDef, 966 rekeyMethod RekeyMethod, 967 rekeyInterval LifeDate, 968 reliability Reliability, 969 subGCKSInfo SubGCKSInfo 970 } 972 B.5.1 Rekey Authorization 974 RekeyAuthorization ::= GCKSName 976 B.5.2 Rekey Mechanisms 978 The policy dictating the mechanisms needed for Rekey message 979 processing is defined by RekeyMechanisms. This field is specified 980 as 982 RekeyMechanisms ::= SEQUENCE { 983 sigAlgorithm INTEGER, 984 hashAlgorithm INTEGER 985 } 987 The INTEGER corresponding to sigAlgorithm will map to the GSAKMP 988 Signature type values. This algorithm set is to be used for message 989 signing. 991 The INTEGER corresponding to hashAlgorithm will map to the GSAKMP 992 Nonce Hash type values. This algorithm is used in computing the 993 combined nonce. 995 B.5.3 Rekey Event Definition 997 Rekey Event Definition provides information to the GC/KS about 998 the system requirements for sending rekey messages. This allows 999 definition of the rekey event in time as well as event driven 1000 characteristics (a number of de-registration notifications as an 1001 example), or a combination of the two (e.g., after x de-registrations 1002 or 24 hours, whichever comes first). 1004 RekeyEventDef ::= CHOICE { 1005 none [0] NULL, -- never rekey 1006 timeOnly [1] LifeDate, -- rekey every x units 1007 event [2] INTEGER, -- rekey after x events 1008 timeAndEvent [3] TimeAndEvent 1009 } 1011 The LifeDate specifies the maximum time a group should exist between 1012 rekeys. This does not require clock synchronization as this is 1013 used with respect to a local clock. (GC/KS clock for sending rekey 1014 messages or member clock for determining whether a message has been 1015 missed.) 1017 The INTEGER corresponding to the event is an indicator of the number 1018 of events a group should sustain before a rekey message is sent. 1019 This defines the events between rekeys. An example of a relevant 1020 event is de-registration notifications. 1022 The TimeAndEvent is defined as a couple of the LifeDate and Integer 1023 policies. 1025 TimeAndEvent ::= SEQUENCE { 1026 time LifeDate, -- rekey after x units of time OR 1027 event INTEGER -- x events occur 1028 } 1030 B.5.4 Rekey Methods 1032 Rekey Method defines the policy of how the rekey is to be 1033 accomplished. This field is specified as 1035 RekeyMethod ::= SEQUENCE { 1036 rekeyMethodType OBJECT IDENTIFIER, 1037 rekeyMethodInfo OCTET STRING 1038 } 1040 The rekeyMethodType will define the rekey method to be used by the 1041 group. 1043 The rekeyMethodInfo will supply the GMs with the information they 1044 need to operate in the correct rekey mode. 1046 B.5.4.1 Rekey Method NONE 1048 The group defined to work without a rekey protocols supporting 1049 it is supported by the rekeyMethodType NONE. There is no 1050 RekeyMethodNoneInfo associated with this option. 1052 id-rekeyNone OBJECT IDENTIFIER ::= {TBD} 1054 RekeyMethodNoneInfo ::= NULL 1056 B.5.4.2 Rekey Method GSAKMP LKH 1058 The GSAKMP protocol specification defined an interpretation of the 1059 Logical Key Hierarchy (LKH) protocol as a rekey method. This method 1060 is supported by the following values. 1062 id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {TBD} 1064 RekeyMethodGSAKMPLKHInfo ::= INTEGER 1066 The GSAKMP LKH method requires a gsakmp type value for identifying 1067 the cryptographic algorithm used to wrap the keys. This value maps 1068 to the GSAKMP encryption type. 1070 B.5.5 Rekey Interval 1072 Rekey interval defines the maximum delay the GM should see 1073 between valid rekeys. This provides a means to ensure the GM is 1074 synchronized, from a key management perspective, with the rest of the 1075 group. It is defined as a time/date stamp. 1077 B.5.6 Rekey Reliability 1079 The Rekey message in the GSAKMP protocol is a single push message. 1080 There are reliability concerns with such non-acknowledged messages 1081 (i.e. message exchange). The Reliability policy defines the 1082 mechanism used to deal with these concerns. 1084 Reliability ::= SEQUENCE { 1085 reliabilityMechanism OBJECT IDENTIFIER, 1086 reliabilityMechContent OCTET STRING 1087 } 1089 The reliability mechanism is defined by an OBJECT IDENTIFIER and 1090 the information needed to operate that mechanism is defined as 1091 reliabilityMechContent and is an OCTET STRING. (as before) 1093 B.5.6.1 Rekey Reliability Mechanism None 1095 In networks with adequate reliability it may not be necessary to use 1096 a mechanism to improve reliability of the Rekey Message. For these 1097 networks the ReliabilityMechanism NONE is appropriate. 1099 id-reliabilityNone OBJECT IDENTIFIER ::= {TBD} 1101 ReliabilityContentNone ::= NULL 1103 B.5.6.2 Rekey Reliability Mechanism Resend 1105 In networks with unknown or questionable reliability it may be 1106 necessary to use a mechanism to improve reliability of the Rekey 1107 Message. For these networks the ReliabilityMechanism RESEND is 1108 potentially appropriate. This mechanism has the GC/KS repeatedly 1109 sending out the same message. 1111 id-reliabilityResend OBJECT IDENTIFIER ::= {TBD} 1113 ReliabilityResendInfo ::= INTEGER 1115 The INTEGER value in the ReliabilityResendInfo indicates the number 1116 of times the message should be resent. 1118 B.5.6.3 Rekey Reliability Mechanism Post 1120 Another reliability mechanism is to post the rekey message on 1121 some service that will make it generally available. This is the 1122 reliabilityPost method. 1124 id-reliabilityPost OBJECT IDENTIFIER ::= {TBD} 1126 ReliabilityContentPost ::= IA5String 1128 The IA5String associated with ReliabilityPost is the identifier of 1129 the posting site and rekey message. 1131 B.5.7 Distributed Operation Policy 1133 The policy dictating the relationships between GC/KS and S-GC/KS for 1134 distributed operations is defined as SubGCKSInfo. It is defined as 1135 a couple of a subGCKSScheme and some information relating to that 1136 Scheme in sGCKSContent. 1138 SubGCKSInfo ::= SEQUENCE { 1139 subGCKSScheme OBJECT IDENTIFIER, 1140 sGCKSContent OCTET STRING 1141 } 1143 B.5.7.1 No Distributed Operation 1145 If the group is not to use S-GC/KS then that Scheme would be 1146 SGCKSSchemeNone. 1148 id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {TBD} 1150 SGCKSNoneContent ::= NULL 1152 B.5.7.2 Autonomous Distributed Mode 1154 If the group is to use S-GC/KS as defined in the GSAKMP specification 1155 as Autonomous mode, then that scheme would be SGCKSAutonomous. 1157 id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= {TBD} 1159 SGCKSAutonomous ::= SEQUENCE { 1160 authSubs GCKSName, 1161 domain OCTET STRING OPTIONAL 1162 } 1164 The policy information needed for autonomous mode is a list of 1165 authorized S-GC/KSs and and restrictions on who they may serve. 1166 The domain field, representing these restrictions is NULL for this 1167 version. 1169 B.6 GSAKMPv1 Rekey Policy ASN.1 Module 1171 GSAKMPv1RekeySA -- {TBD} 1173 DEFINITIONS IMPLICIT TAGS ::= 1175 BEGIN 1177 IMPORTS 1178 GCKSName 1179 FROM GSAKMPv1RegistrationSA {TBD} 1180 LifeDate 1181 FROM PolicyToken {TBD}; 1183 -- id-GSAKMPv1Rekey OBJECT IDENTIFIER::= {TBD} 1185 GSAKMPv1RekeyInfo ::= SEQUENCE { 1186 authorization RekeyAuthorization, 1187 mechanism RekeyMechanisms, 1188 rekeyEventDef RekeyEventDef, -- tells the GCKS when to rekey 1189 rekeyMethod RekeyMethod, 1190 rekeyInterval LifeDate, -- member knows when to rejoin 1191 reliability Reliability, -- what mech will be used to 1192 -- increase the likelihood 1193 -- of rekey delivery 1194 subGCKSInfo SubGCKSInfo -- what subordinate gcks needs 1195 } 1197 RekeyAuthorization ::= GCKSName 1199 RekeyMechanisms ::= SEQUENCE { 1200 sigAlgorithm INTEGER, 1201 hashAlgorithm INTEGER 1202 } 1204 RekeyEventDef ::= CHOICE { 1205 none [0] NULL, -- never rekey 1206 timeOnly [1] EXPLICIT LifeDate, -- rekey every x units 1207 event [2] INTEGER, -- rekey after x events 1208 timeAndEvent [3] TimeAndEvent 1209 } 1211 TimeAndEvent ::= SEQUENCE { 1212 time LifeDate, -- rekey after x units of time OR 1213 event INTEGER -- x events occur 1214 } 1216 RekeyMethod ::= SEQUENCE { 1217 rekeyMethodType OBJECT IDENTIFIER, 1218 rekeyMethodInfo OCTET STRING 1219 } 1221 -- REKEY METHOD NONE -- 1223 -- id-rekeyNone OBJECT IDENTIFIER ::= {TBD} 1225 RekeyMethodNoneInfo ::= NULL 1227 -- REKEY METHOD GSAKMP LKH -- 1229 -- id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {TBD} 1231 RekeyMethodGSAKMPLKHInfo ::= INTEGER -- gsakmp type value for 1232 -- wrapping mechanism 1234 Reliability ::= SEQUENCE { 1235 reliabilityMechanism OBJECT IDENTIFIER, 1236 reliabilityMechContent OCTET STRING 1237 } 1239 -- RELIABILITY MECHANISM NONE -- 1241 -- id-reliabilityNone OBJECT IDENTIFIER ::= {TBD} 1242 ReliabilityContentNone ::= NULL 1244 -- RELIABILITY MECHANISM RESEND -- 1246 -- id-reliabilityResend OBJECT IDENTIFIER ::= {TBD} 1248 ReliabilityResendInfo ::= INTEGER -- # of times rekey message should 1249 -- be resent 1251 -- RELIABILITY MECHANISM POST -- 1252 -- id-reliabilityPost OBJECT IDENTIFIER ::= {TBD} 1254 ReliabilityContentPost ::= IA5String 1256 SubGCKSInfo ::= SEQUENCE { 1257 subGCKSScheme OBJECT IDENTIFIER, 1258 sGCKSContent OCTET STRING 1259 } 1261 -- id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {TBD} 1263 SGCKSNoneContent ::= NULL 1265 -- id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= {TBD} 1267 SGCKSAutonomous ::= SEQUENCE { 1268 authSubs GCKSName, 1269 domain OCTET STRING OPTIONAL 1270 } 1272 END 1274 C APPENDIX C -- Data SA Policy 1276 The Data SA provides the data structures needed for the protection 1277 of the data exchanged between group members. This appendix defines 1278 the data structures needed for a simple, generic security application 1279 making use of fixed security mechanisms. Such a Data SA requires 1280 only that keys delivered by the registration and rekey protocols be 1281 mapped to the service using them. 1283 C.1 Generic Data Policy 1285 The Generic Data Policy has the following identifier: 1287 id-genericDataSA OBJECT IDENTIFIER :: = TBD 1289 If an authentication mechanism is used within the security 1290 application, the key identifier (kMKeyID) used in the key management 1291 protocol is given, as well as an optional key expiration date. 1292 Likewise, if an encryption mechanism is used within the security 1293 application, the encryption key identifier is given, as well as an 1294 optional key expiration date (keyExpirationDate). 1296 GenericDataSAInfo ::= SEQUENCE { 1297 authentication [0] EXPLICIT KeyInfo OPTIONAL, 1298 encryption [1] EXPLICIT KeyInfo OPTIONAL 1299 } 1301 KeyInfo ::= SEQUENCE{ 1302 kMKeyID OCTET STRING, 1303 keyExpirationDate LifeDate OPTIONAL 1304 } 1306 C.2 Generic Data Policy ASN.1 Module 1308 GenericDataSA -- {TBD} 1310 DEFINITIONS IMPLICIT TAGS ::= 1312 BEGIN 1314 -- DATA APPLICATION: Generic 1315 -- This token specification is for data applications with 1316 -- fixed security mechanisms. Such data applications only 1317 -- need a mapping of management protocol key identification 1318 -- tags to security service. 1320 IMPORTS 1321 LifeDate 1322 FROM PolicyToken {TBD} 1324 KeyIdentifier 1325 FROM PKIX1Implicit88 { iso(1) identified-organization(3) 1326 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1327 id-mod(0) id-pkix1-implicit(19) }; 1329 -- id-genericDataSA OBJECT IDENTIFIER ::= {TBD} 1331 GenericDataSAInfo ::= SEQUENCE { 1332 authentication [0] EXPLICIT KeyInfo OPTIONAL, 1333 encryption [1] EXPLICIT KeyInfo OPTIONAL 1334 } 1336 KeyInfo ::= SEQUENCE{ 1337 kMKeyID OCTET STRING, 1338 keyExpirationDate LifeDate OPTIONAL 1339 } 1341 END 1343 D APPENDIX D -- Change History (To Be Removed from RFC) 1345 D.1 Changes from Group Policy Token v-00 to v-01, December 2004 1347 - Editorial/Grammatical changes throughout the document. 1349 - Core Policy Token ASN.1 Module Appendix rewritten. 1351 - GSAKMPv1 Registration ASN.1 Module Appendix rewritten. 1353 - GSAKMPv1 De-Registration ASN.1 Module Appendix rewritten. 1355 - GSAKMPv1 Rekey Policy ASN.1 Module Appendix rewritten. 1357 - RFC 3711 Policy Appendix was rewritten. 1359 D.2 Changes from Group Policy Token v-01 to v-02, March 2005 1361 - RFC 3711 policy removed. 1363 - Generic Data SA provided. 1365 D.3 Changes from Group Policy Token v-02 to v-03, July 2005 1367 - Consistency corrections between text and ASN.1 modules. 1369 - Explicit tagging in sequences of sequences to avoid encoding 1370 ambiguities. 1372 D.4 Changes from Group Policy Token v-03 to v-04, September 2005 1374 - Authorization field for group senders. 1376 - Editorial corrections. 1378 - Renamed to "Group Security Policy Token". 1380 D.5 Changes from Group Policy Token v-04 to v-05, December 2005 1382 - Removed constraints on CMS signing-time attribute. 1384 - Removed unnecessary explicit tags in CHOICE constructs of the 1385 core token. 1387 D.6 Changes from Group Policy Token v-05 to v-06, January 2006 1389 - Added explanation paragraphs to section The Policy Token. 1391 - Added tokenDefVersion field to TokenID structure. 1393 - Added updating/extension rules to the IANA Considerations 1394 section. 1396 Authors' Addresses 1398 Andrea Colegrove 1399 SPARTA, Inc. 1400 7075 Samuel Morse Drive 1401 Columbia, MD 21046 1402 (410) 872-1515 ext 232 1403 FAX (410) 872-8079 1404 acc@sparta.com 1406 Hugh Harney 1407 SPARTA, Inc. 1408 7075 Samuel Morse Drive 1409 Columbia, MD 21046 1410 (410) 872-1515 ext 203 1411 FAX (410) 872-8079 1412 hh@sparta.com 1414 Full Copyright Statement 1416 Copyright (C) The Internet Society (2006). This document is subject 1417 to the rights, licenses and restrictions contained in BCP 78, and 1418 except as set forth therein, the authors retain all their rights. 1420 This document and the information contained herein are provided 1421 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1422 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1423 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1424 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1425 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1426 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1428 IPR Considerations 1430 By submitting this Internet-Draft, each author represents that any 1431 applicable patent or other IPR claims of which he or she is aware 1432 have been or will be disclosed, and any of which he or she becomes 1433 aware will be disclosed, in accordance with Section 6 of BCP 79. 1435 The IETF takes no position regarding the validity or scope of any 1436 Intellectual Property Rights or other rights that might be claimed 1437 to pertain to the implementation or use of the technology described 1438 in this document or the extent to which any license under such rights 1439 might or might not be available; nor does it represent that it has 1440 made any independent effort to identify any such rights. Information 1441 on the procedures with respect to rights in RFC documents can be 1442 found in BCP 78 and BCP 79. 1444 Copies of IPR disclosures made to the IETF Secretariat and any 1445 assurances of licenses to be made available, or the result of an 1446 attempt made to obtain a general license or permission for the 1447 use of such proprietary rights by implementers or users of this 1448 specification can be obtained from the IETF on-line IPR repository 1449 at http://www.ietf.org/ipr. 1451 The IETF invites any interested party to bring to its attention any 1452 copyrights, patents or patent applications, or other proprietary 1453 rights that may cover technology that may be required to implement 1454 this standard. Please address the information to the IETF at ietf- 1455 ipr@ietf.org. 1457 Document expiration: July 23, 2006