Internet Engineering Task Force INTERNET-DRAFT A Colegrove (SPARTA) H Harney (SPARTA) draft-ietf-msec-policy-token-sec-01.txt SPARTA, Inc. Expires: June 30, 2005 December 2004 Group Policy Token V1 with Application to GSAKMP Status of this memo By submitting this Internet-Draft, the authors certify that any applicable patent or other IPR claims of which I am (we are) aware have been disclosed, or will be disclosed, and any of which I (we) become aware will be disclosed, in accordance with RFC 3668 (BCP 79). By submitting this Internet-Draft, the authors accept the provisions of Section 3 of RFC 3667 (BCP 78). Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress''. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The Policy Token is a structure used to specify the security policy and configurable parameters for a cryptographic group, such as a secure multicast group. This document specifies the structure of such a token in order to securely bind system-level security to protocols supporting the management of cryptographic groups. INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 Copyright Notice Copyright (c) The Internet Society (2004). All Rights Reserved. Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 2] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 Contents 1 Introduction 5 2 Token Creation and Receipt 6 3 The Policy Token 6 3.1 tokenInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 registration . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 rekey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4 Security Considerations 9 5 IANA Considerations 9 6 References 10 6.1 Normative References . . . . . . . . . . . . . . . . . . . . . . . 10 6.2 Non-Normative References . . . . . . . . . . . . . . . . . . . . . 10 7 Acknowledgements 11 A APPENDIX A -- Core Policy Token ASN.1 Module 12 B APPENDIX B -- GSAKMPv1 Base Policy 14 B.1 GSAKMPv1 Registration Policy . . . . . . . . . . . . . . . . . . . 14 B.1.1 Authorization . . . . . . . . . . . . . . . . . . . . . . . . . 14 B.1.2 AccessControl . . . . . . . . . . . . . . . . . . . . . . . . . 15 B.1.3 JoinMechanisms . . . . . . . . . . . . . . . . . . . . . . . . 16 B.1.4 Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 B.2 GSAKMPv1 Registration ASN.1 Module . . . . . . . . . . . . . . . . 19 B.3 GSAKMPv1 De-Registration Policy . . . . . . . . . . . . . . . . . . 21 B.4 GSAKMPv1 De-Registration ASN.1 Module . . . . . . . . . . . . . . . 22 B.5 GSAKMPv1 Rekey Policy . . . . . . . . . . . . . . . . . . . . . . . 23 B.5.1 Rekey Authorization . . . . . . . . . . . . . . . . . . . . . . 23 B.5.2 Rekey Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 23 B.5.3 Rekey Event Definition . . . . . . . . . . . . . . . . . . . . 24 B.5.4 Rekey Methods . . . . . . . . . . . . . . . . . . . . . . . . . 25 B.5.4.1 Rekey Method NONE . . . . . . . . . . . . . . . . . . . . 25 B.5.4.2 Rekey Method GSAKMP LKH . . . . . . . . . . . . . . . . . 25 B.5.5 Rekey Interval . . . . . . . . . . . . . . . . . . . . . . . . 26 B.5.6 Rekey Reliability . . . . . . . . . . . . . . . . . . . . . . . 26 B.5.6.1 Rekey Reliability Mechanism None . . . . . . . . . . . . 26 B.5.6.2 Rekey Reliability Mechanism Resend . . . . . . . . . . . 26 B.5.6.3 Rekey Reliability Mechanism Post . . . . . . . . . . . . 27 B.5.7 Distributed Operation Policy . . . . . . . . . . . . . . . . . 27 B.5.7.1 No Distributed Operation . . . . . . . . . . . . . . . . 27 B.5.7.2 Autonomous Distributed Mode . . . . . . . . . . . . . . . 28 B.6 GSAKMPv1 Rekey Policy ASN.1 Module . . . . . . . . . . . . . . . . 28 C APPENDIX C -- Data SA Policy 30 C.1 RFC 3711 Data Policy . . . . . . . . . . . . . . . . . . . . . . . 30 C.2 Secure RTP Data Policy ASN.1 Module . . . . . . . . . . . . . . . . 33 D APPENDIX D -- Change History (To Be Removed from RFC) 34 D.1 Changes from Group Policy Token v-00 to v-01, December 2004 . . . . 34 Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 3] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 Authors Addresses 35 Full Copyright Statement 35 Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 4] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 1 Introduction The Multicast Group Security Architecture [HW05] defines the security infrastructure to support secure group communications. The Policy Token assumes this architecture in its definition. It defines the enforceable security parameters for a Group Secure Association. The Policy Token is a verifiable data construct signed by the group owner, the entity with the authorization to create security policy. The group controllers in a group will use the policy token to ensure that the mechanisms used to secure the group are correct and to enforce the access control rules for joining members. The group members, who may contribute data to the group or access data from the group, will use the policy token to ensure that the group is owned by a trusted authority. Also, the members may want to verify that the access control rules are adequate to protect the data that member is submitting to the group. The policy token is specified in ASN.1 and is to be DER encoded. This specification ability allows the token to easily import group definitions that span different applications and environments. ASN.1 allows the token to specify branches that can be used by any multicast security protocol. Any group can use this policy token structure to specify the use of multiple protocols in securing the group. Care was taken in this specification to provide a core level of token specificity that would allow ease of extensibility and flexibility in supporting mechanisms. This was done by using the following abstracted construct: Mechanism ::= SEQUENCE { mechanismIdentifier OBJECT IDENTIFIER, mechanismParameters OCTET STRING } This construct will allow the use of group mechanisms specified in other documents with the Policy Token. The Policy Token is structured to reflect the MSEC Architecture layers for a Group Security Association. Each of the architectural layers is identified and given a branch in the "Core" token. This allows a high degree of flexibility for future protocol specifications at each architectural layer without the need to change the "Core" policy token, which can then act as a single point of reference for defining secure groups using any mix of protocols for any number of environments. Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 5] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 2 Token Creation and Receipt At the time of group creation or whenever the policy of the group is updated, the Group Owner will create a new policy token. To ensure authenticity of the specified policy, the Token MUST be signed by the Group Owner. The signed token MUST be in accordance with the CMS [RFC 3852] SignedData type. The content of the SignedData is the token itself. It is represented with the ContentType object identifier of id-msec-token OBJECT IDENTIFIER ::= {TBD} The CMS sid value of the SignerInfo MUST be that of the Group Owner. The signedAttrs field MUST be present. In addition to the minimally required fields of signedAttrs, the signing-time attribute MUST be PRESENT and MUST be specified as a GeneralizedTime value. Upon receipt of a Policy Token, the recipient MUST check that - the Group Owner, as identified by the sid in the SignerInfo, is the expected entity - the signing-time value is more recent than the signing-time value seen in a previously received Policy Token for that group, or the Policy Token is the first token seen by the recipient for that group. - the processing of the signature succeeds in accordance with RFC 3369 - the specified security and communication mechanisms (or at least one mechanism of each choice) are supported and are in compliance with the recipient's local policy. 3 The Policy Token The structure of the Policy Token is as follows: Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 6] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 Token ::= SEQUENCE { tokenInfo TokenID, registration SEQUENCE OF Registration, rekey SEQUENCE OF GroupMngmtProtocol, data SEQUENCE OF DataProtocol } tokenInfo provides information about the instance of the Policy Token (PT). registration provides a list of acceptable registration and deregistration policy and mechanisms that may be used to manage member-initiated joins and departures from a group. A NULL sequence indicates that the group does not support registration and deregistration of members. A member MUST be able to support at least one set of Registration mechansims in order to join the group. When multiple mechanisms are present, a member MAY use any of the listed methods. The list is ordered in terms of Group Owner preference. A member SHOULD choose the highest listed mechanism that local policy supports. rekey provides the rekey protocols that will be used in managing the group. The member MUST be able to accept one of the types of rekey messages listed. The list is ordered in terms of Group Owner preference. A member SHOULD choose the highest listed mechanism that local policy supports. data provides the applications used in the communications between group members. When multiple applications are provided, the order of the list implies the order of encapsulation of the data. A member MUST be able to support all the listed applications and if any choices of mechanisms are provided per application, the member MUST support at least one of the mechanisms. Each data field of the PT is specified further in the following sections. 3.1 tokenInfo tokenInfo explicitly identifies a version of the Policy Token for a particular group. It is defined as TokenID ::= SEQUENCE { groupName OCTET STRING, edition INTEGER OPTIONAL } Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 7] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 groupName is the identifier of the group edition is an optional INTEGER indicating the sequence number of the PT. If edition is present, group entities MUST accept a PT only when the value is greater than the last value seen in a valid PT for that group. 3.2 registration The registration SA is defined in the MSEC Architecture. During registration, a prospective group member and the group controller will interact to give the group member access to the keys and information it needs to join and participate in the group data SA. The deregistration piece allows a current group member to notify the GC/KS that it will no longer be participating in the data layer SA. Registration ::= SEQUENCE { register GroupMngmtProtocol, de-register GroupMngmtProtocol } The protocol for registration and de-registration are each specified as GroupMngmtProtocol ::= CHOICE { none [0] NULL, supported [1] Protocol } Protocol ::= SEQUENCE { protocol OBJECT IDENTIFIER, protocolInfo OCTET STRING } For example, register might be specified as the GSAKMP [HMC] registration protocol. The OBJECT IDENTIFIER TBS would be followed by the parameters used in GSAKMP registration as specified in appendix B.1. 3.3 rekey The Rekey SA is defined in the MSEC Architecture. During Rekey, the membership of the group can be modified as well as refreshing the group traffic protection keys and updating the Policy Token. Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 8] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 This field is also specified as a sequence of protocols that will be used by the GC/KS. 3.4 data The Data SA is the ultimate consumer of the group keys. The data field will indicate the keys and mechanisms that are to be used in communications between group members. There are several protocols that could make use of multicast key - IPSec and SRTP are the two that are of immediate interest to the authors. The sequencing of the Data SA mechanisms are from "inside" to "outside". That is, the first Data SA defined in a policy token must act on the raw data. Any data SA specified after that will be applied in turn. DataProtocol ::= Protocol 4 Security Considerations The document specifies the structure for a Group Policy Token. As such, the structure as received by a group entity must be verifiably authentic. This Policy Token uses CMS to apply authentication through digital signatures. The security of this scheme relies upon a secure CMS implementation, choice of signature mechanism of appropriate strength for the group using the Policy Token, and secure, sufficiently strong keys. Additionally, it relies upon knowledge of a well-known Group Owner as the root of policy enforcement. Furthermore, while the Group Owner may list alternate mechanisms for various functions, the group is only as strong as the weakest accepted mechanisms. As such, the Group Owner is responsible for providing only acceptable security mechanisms. 5 IANA Considerations The following object identifiers should be assigned: - id-msec-token OBJECT IDENTIFIER ::= TBD - id-securitySuiteOne OBJECT IDENTIFIER ::= TBD - id-GSAKMPv1RegistrationProtocol OBJECT IDENTIFIER::= TBD Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 9] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 - id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= TBD - id-GSAKMPv1Rekey OBJECT IDENTIFIER::= TBD - id-rekeyNone OBJECT IDENTIFIER ::= TBD - id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= TBD - id-reliabilityNone OBJECT IDENTIFIER ::= TBD - id-reliabilityResend OBJECT IDENTIFIER ::= TBD - id-reliabilityPost OBJECT IDENTIFIER ::= TBD - id-subGCKSSchemeNone OBJECT IDENTIFIER ::= TBD - id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= TBD - id-rfc3711DataSA OBJECT IDENTIFIER ::= TBD 6 References The following references were used in the preparation of this document. 6.1 Normative References [HMC] H. Harney, U. Meth, and A. Colegrove, "GSAKMP", draft-ietf-msec-gsakmp-sec-06.txt, work in progress, May 2004. [RFC 3280] R. Housley, W. Polk, W. Ford, D. Solo, Internet X.509 Pulbic Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002. [RFC 3852] R. Housley, Cryptographic Message Syntax, July 2004. 6.2 Non-Normative References [HCLM00] H. Harney, A. Colegrove, P. Lough, and U. Meth, "GSAKMP Token Specification", draft-ietf-msec-tokenspec-sec-00.txt. [RFC 3711] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. Norrman, "The Secure Real-Time Transport Protocol (SRTP)", March 2004. [RFC 3740] T. Hardjono and B. Weis, "The Multicast Group Security Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 10] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 Architecture", March 2004. [HCM01] H. Harney, A. Colegrove, P. McDaniel, "Principles of Policy in Secure Groups", Proceedings of Network and Distributed Systems Security 2001 Internet Society, San Diego, CA, February 2001 [HHMCD01] , Thomas Hardjono, Hugh Harney, Pat McDaniel, Andrea Colgrove, Pete Dinsmore, Group Security Policy Token: Definition and Payloads', draft-ietf-msec-gspt-00.txt, Work in progress. 7 Acknowledgements The following individuals deserve recognition and thanks for their contributions which have greatly improved this specification: Uri Meth, Rod Fleischer, Peter Lough, Thomas Hardjono, Patrick McDaniel, and Pete Dinsmore for their work on earlier versions of policy tokens; George Gross for the impetus to have a well-specified, extensible policy token, Mark Baugher and Elisabetta Carrara for review and clarrification of SRTP policy needs. Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 11] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 A APPENDIX A -- Core Policy Token ASN.1 Module PolicyToken -- {TBD} DEFINITIONS IMPLICIT TAGS ::= BEGIN Token ::= SEQUENCE { tokenInfo TokenID, registration SEQUENCE OF Registration, rekey SEQUENCE OF GroupMngmtProtocol, data SEQUENCE OF DataProtocol } ------------------------------------------------------------ -- Token ID TokenID ::= SEQUENCE { groupName OCTET STRING, edition INTEGER OPTIONAL } LifeDate ::= CHOICE { gt [0] GeneralizedTime, utc [1] UTCTime, interval [2] INTEGER } ------------------------------------------------------------ -- Registration Registration ::= SEQUENCE { register GroupMngmtProtocol, de-register GroupMngmtProtocol } ------------------------------------------------------------ -- GroupMngmtProtocol GroupMngmtProtocol ::= CHOICE { none [0] NULL, supported [1] Protocol } Protocol ::= SEQUENCE { protocol OBJECT IDENTIFIER, protocolInfo OCTET STRING } Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 12] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 ------------------------------------------------------------ -- DataProtocol DataProtocol ::= Protocol ------------------------------------------------------------ END Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 13] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 B APPENDIX B -- GSAKMPv1 Base Policy This appendix provides the data structures needed for when GSAKMP exchanges are used as the GroupMngmtProtocol for the registration, de-registration, and/or rekey SAs. This GSAKMP Base Policy specification assumes familiarity with GSAKMP. B.1 GSAKMPv1 Registration Policy When GSAKMP is used in the Group Management Protocol for registration, the following object identifier is used in the core token. id-GSAKMPv1RegistrationProtocol OBJECT IDENTIFIER::= {TBD} The registration policy for GSAKMP provides 1) information on authorizations for group roles; 2) access control information for group members; 3) the mechanisms used in the registration process, and 4) information on what transport the GSAKMP registration exchange will use. GSAKMPv1RegistrationInfo ::= SEQUENCE { joinAuthorization JoinAuthorization, joinAccessControl SEQUENCE OF AccessControl, joinMechanisms JoinMechanisms, transport Transport } B.1.1 Authorization joinAuthorization provides information on who is allowed to be a Group Controller/Key Server (GC/KS) and a sub-GC/KS. JoinAuthorization ::= SEQUENCE { gCKS GCKSName, subGCKS SEQUENCE OF GCKSName OPTIONAL } The authorization information is in the form of an access control list indicating entity name and acceptable certification authority information Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 14] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 for the entity's certificate. GCKSName ::= SEQUENCE OF UserCAPair UserCAPair ::= SEQUENCE { groupEntity GSAKMPID, cA CertAuth } groupEntity is defined by type and value. The types are indicated by integers that correspond to the GSAKMP Identification types. When a portion of a defined name type is filled with an "*", this indicates a wildcard, representing any valid choice for a field. This allows the specification of an authorization rule that is a set of related names. GSAKMPID ::= SEQUENCE { typeValue INTEGER, typeData OCTET STRING } The certificate authority is identified by the X.509 key identifier. CertAuth ::= KeyIdentifier B.1.2 AccessControl joinAccessControl provides information on who is allowed to be a Group Member. The access control list is implemented as a set of permissions that the member must satisfy and a list of name rules and the certificate authority that each must satisfy. Additionally, a list of exclusions to the list is provided. AccessControl ::= SEQUENCE { permissions SEQUENCE OF Permission OPTIONAL, accessRule SEQUENCE OF UserCAPair, exclusionsRule SEQUENCE OF UserCAPair OPTIONAL } The permissions initially available are an abstract set of numeric levels that may be interpretted internal to a community. Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 15] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 Permission ::= CHOICE { simplePermission [1] SimplePermission } SimplePermission ::= ENUMERATED { one(1), two(2), three(3), four(4), five(5), six(6), seven(7), eight(8), nine(9) } B.1.3 JoinMechanisms Allowable GSAKMP mechanism choices for a particular group are specified in joinMechanisms. Any set of JoinMechanism is acceptable from a policy perspective. JoinMechanisms ::= SEQUENCE OF JoinMechanism Each set of mechanisms used in the GSAKMP Registration may be specified either as an explicitly defined set or as a pre-defined security suite. JoinMechanism ::= CHOICE { alaCarte [0] Mechanisms, suite [1] SecuritySuite } In an explicitly defined -- or alaCarte -- set, a mechanism is defined for the signature, the key exchange algorithm, the key wrapping algorithm, the type of acknowledgement data, and configuration data for the setting of timeouts. Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 16] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 Mechanisms ::= SEQUENCE { signatureDef SigDef, hashAlgorithm INTEGER, kEAlg KEAlg, keyWrap KeyWrap, ackData AckData, opInfo OpInfo } The signature definition requires specification of the signature algorithm for message signing. The INTEGER that defines the choice corresponds to the GSAKMP Signature type. SigDef ::= INTEGER The key exchange algorithm requires an integer to define the GSAKMP key creation type and may require additional per type data. The INTEGER corresponding to hashAlgorithm will map to the GSAKMP Nonce Hash type values. This algorithm is used in computing the combined nonce. KEAlg ::= SEQUENCE { keyExchangeAlgorithmID INTEGER, keyExchangeAlgorithmData OCTET STRING OPTIONAL } The keyWrap is the algorithm that is used to wrap the group key(s) and the policy token (if included). The integer corresponds to the GSAKMP encryption type. KeyWrap ::= INTEGER Data may potentially be returned in a GSAKMP Key Download ACK/Failure message. The type of data required by a group is specified by AckData. No such field is currently supported or required. AckData ::= CHOICE { none [0] NULL } OpInfo provides configuration data for the operation of GSAKMP registration. Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 17] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 timeout indicates the elapsed amount of time before a sent message is considered to be misrouted or lost. It is specified as a time. terse informs a GC/KS whether the group should be operated in terse (TRUE) or verbose (FALSE) mode. OpInfo ::= SEQUENCE { timeOut LifeDate, terse BOOLEAN } LifeDate ::= CHOICE { gt [0] GeneralizedTime, utc [1] UTCTime } If the choice of mechanism for the join is a predefined security suite, then it is identified by OBJECT IDENTIFIER (OID). Other security suites may be defined elsewhere by specification and registration of an OID. SecuritySuite ::= OBJECT IDENTIFIER The OID for security suite 1, as defined within the GSAKMPv1 specification is id-securitySuiteOne OBJECT IDENTIFIER ::= {TBD} B.1.4 Transport transport indicates what protocol GSAKMP should ride over. The choice of udpRTJtcpOther indicates that the GSAKMP Request to Join message is carried by UDP and all other group establishment messages are carried by TCP. Transport ::= CHOICE { tcp [0] NULL, udp [1] NULL, udpRTJtcpOther [2] NULL } Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 18] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 B.2 GSAKMPv1 Registration ASN.1 Module GSAKMPv1RegistrationSA {TBD} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS GCKSName; IMPORTS LifeDate FROM PolicyToken {TBD} KeyIdentifier FROM PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) }; id-GSAKMPv1RegistrationProtocol OBJECT IDENTIFIER::= {TBD} GSAKMPv1RegistrationInfo ::= SEQUENCE { joinAuthorization JoinAuthorization, joinAccessControl SEQUENCE OF AccessControl, joinMechanisms JoinMechanisms, transport Transport } JoinAuthorization ::= SEQUENCE { gCKS GCKSName, subGCKS SEQUENCE OF GCKSName OPTIONAL } GCKSName ::= SEQUENCE OF UserCAPair UserCAPair ::= SEQUENCE { groupEntity GSAKMPID, cA CertAuth } CertAuth ::= KeyIdentifier AccessControl ::= SEQUENCE { permissions SEQUENCE OF Permission OPTIONAL, accessRule SEQUENCE OF UserCAPair, exclusionsRule SEQUENCE OF UserCAPair OPTIONAL } Permission ::= CHOICE { simplePermission [1] SimplePermission Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 19] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 } SimplePermission ::= ENUMERATED { one(1), two(2), three(3), four(4), five(5), six(6), seven(7), eight(8), nine(9) } GSAKMPID ::= SEQUENCE { typeValue INTEGER, typeData OCTET STRING } JoinMechanisms ::= SEQUENCE OF JoinMechanism JoinMechanism ::= CHOICE { alaCarte [0] Mechanisms, suite [1] SecuritySuite } Mechanisms ::= SEQUENCE { signatureDef SigDef, kEAlg KEAlg, keyWrap KeyWrap, ackData AckData, opInfo OpInfo } SecuritySuite ::= OBJECT IDENTIFIER -- SECURITY SUITE ONE -- id-securitySuiteOne OBJECT IDENTIFIER ::= {TBD} SigDef ::= SEQUENCE { sigAlgorithmID INTEGER, hashAlgorithmID INTEGER } KEAlg ::= SEQUENCE { keyExchangeAlgorithmID INTEGER, keyExchangeAlgorithmData OCTET STRING OPTIONAL } KeyWrap ::= INTEGER Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 20] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 AckData ::= CHOICE { none [0] NULL } OpInfo ::= SEQUENCE { timeOut LifeDate } Transport ::= CHOICE { tcp [0] NULL, udp [1] NULL, udpRTJtcpOther [2] NULL } END B.3 GSAKMPv1 De-Registration Policy GSAKMP De-Registration provides a method to notify a (S-)GC/KS that a member needs to leave a group. When GSAKMP is the De-Registration Protocol for the Group, the following object identifier is used in the core token. id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= {TBD} The De-Registration policy provides the mechanisms needed for the De-Registration exchange messages, an indication of whether the exchange is to be done using terse (TRUE) or verbose (FALSE) mode, and the transport used for the GSAKMP De-registration messages. GSAKMPv1DeRegistrationInfo ::= SEQUENCE { leaveMechanisms LeaveMechanisms, terse BOOLEAN, transport Transport } The policy dictating the mechanisms needed for the De-registration exchange is defined by leaveMechanisms. This field is specified as LeaveMechanisms ::= SEQUENCE { sigAlgorithm INTEGER, hashAlgorithm INTEGER, cA KeyIdentifier } Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 21] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 The INTEGER corresponding to sigAlgorithm will map to the GSAKMP Signature type values. This algorithm set is to be used for message signing. The INTEGER corresponding to hashAlgorithm will map to the GSAKMP Nonce Hash type values. This algorithm is used in computing the combined nonce. cA represents a trust point off of which the signer's certificate must certify. It is identified by the PKIX KeyIdentifier [RFC 3280] type. transport will provide the expected transport for GSAKMP De-registration messages. Initially, either UDP or TCP will be the policy for a group. Transport ::= CHOICE { tcp [0] NULL, udp [1] NULL } B.4 GSAKMPv1 De-Registration ASN.1 Module GSAKMPv1DeRegistrationSA {TBD} DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS KeyIdentifier FROM PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) }; id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= {TBD} GSAKMPv1DeRegistrationInfo ::= SEQUENCE { leaveMechanisms LeaveMechanisms, transport Transport } LeaveMechanisms ::= SEQUENCE { sigAlgorithm INTEGER, hashAlgorithm INTEGER, cA KeyIdentifier } Transport ::= CHOICE { tcp [0] NULL, udp [1] NULL } Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 22] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 END B.5 GSAKMPv1 Rekey Policy When GSAKMP is used as the Rekey Protocol for the Group, the following object identifier should be used in the core token as the rekey protocol: id-GSAKMPv1Rekey OBJECT IDENTIFIER::= {TBD} The GSAKMP Rekey Policy provides authorization information, mechanisms for the GSAKMP Rekey messages, indicators defining rekey event definitions that define when the GC/KS should send a rekey message, the protocol or method the rekey event will use, the rekey interval that will allow a member to recognize a failure in the rekey process, a reliability indicator that defines the method the rekey will use to increase the likelyhood of a rekey delivery (if any), and finally an indication of how subordinate-GC/KSs will handle rekey. This policy also describes the specific Rekey policy methods "None" and "GSAKMP LKH REKEY". GSAKMPv1RekeyInfo ::= SEQUENCE { authorization RekeyAuthorization, mechanism RekeyMechanisms, rekeyEventDef RekeyEventDef, -- tells the GCKS when to rekey rekeyMethod RekeyMethod, rekeyInterval LifeDate, -- member knows when to rejoin reliability Reliability, -- what mech will be used to increase -- the likelihood of rekey delivery subGCKSInfo SubGCKSInfo -- what subordinate gcks needs } B.5.1 Rekey Authorization RekeyAuthorization ::= GCKSName B.5.2 Rekey Mechanisms The policy dictating the mechanisms needed for Rekey message processing is defined by RekeyMechanisms. This field is specified as Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 23] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 RekeyMechanisms ::= SEQUENCE { sigAlgorithm INTEGER, hashAlgorithm INTEGER } The INTEGER corresponding to sigAlgorithm will map to the GSAKMP Signature type values. This algorithm set is to be used for message signing. The INTEGER corresponding to hashAlgorithm will map to the GSAKMP Nonce Hash type values. This algorithm is used in computing the combined nonce. B.5.3 Rekey Event Definition Rekey Event Definition provides information to the GC/KS about the system requirements for sending rekey messages. This allows definition of the rekey event in time as well as event driven characteristics (a number of de-registration notifications as an example), or a combination of the two (e.g., after x de-registrations or 24 hours, which ever comes first). RekeyEventDef ::= CHOICE { none [0] NULL, -- never rekey timeOnly [1] LifeDate, -- rekey every x units event [2] INTEGER, -- rekey after x events timeAndEvent [3] TimeAndEvent } The LifeDate specifies the maximum time a group should exist between rekeys. This does not require clock synchronization as this is used with respect to a local clock. The INTEGER corresponding to the event is an indicator of the number of events a group should sustain before a rekey message is sent. This defines the events between rekeys. An example of a relevant event is de-registration notificaitons. The TimeAndEvent is defined as a couple of the LifeDate and Integer policies. TimeAndEvent ::= SEQUENCE { time LifeDate, -- rekey after x units of time OR event INTEGER -- x events occur } Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 24] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 B.5.4 Rekey Methods The policy dictating the rekey method supported by the Rekey message is defined by RekeyMethod. This field is specified as RekeyMethod ::= SEQUENCE { rekeyMethodType OBJECT IDENTIFIER, rekeyMethodInfo OCTET STRING } The rekeyMethodType will define the rekey method to be used by the group. The rekeyMethodInfo will supply the GMs with the information they need to operate in the correct rekey mode. B.5.4.1 Rekey Method NONE The group defined to work without a rekey protocols supporting it is supported by the rekeyMethodType NONE. There is no RekeyMethodNoneInfo associated with this option. id-rekeyNone OBJECT IDENTIFIER ::= {TBD} RekeyMethodNoneInfo ::= NULL B.5.4.2 Rekey Method GSAKMP LKH The GSAKMP protocol specification defined an interpretation of the Logical Key Hierarchy (LKH) protocol as a rekey method. This method is supported by the following values. id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {TBD} RekeyMethodGSAKMPLKHInfo ::= INTEGER The GSAKMP LKH method requires a gsakmp type value for identifying the cryptographic algorithm used to wrap the keys. This value maps to the GSAKMP encryption type. Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 25] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 B.5.5 Rekey Interval Rekey interval defines the maximum delay the GM should see between valid rekeys. This provides a means to ensure the GM is synchronized, from a key management perspective, with the rest of the group. It is defined as a time/date stamp. B.5.6 Rekey Reliability The Rekey message in the GSAKMP protocol is a one sided exchange of data. There are reliability concerns with one sided exchanges. The Reliability policy defines the mechanism used to deal with these concerns. Reliability ::= SEQUENCE { reliabilityMechanism OBJECT IDENTIFIER, reliabilityMechContent OCTET STRING } The reliability mechanism is defined by an OBJECT IDENTIFIER and the information needed to operate that mechanism is defined as reliabilityMechContent and is an OCTET STRING. (as before) B.5.6.1 Rekey Reliability Mechanism None In networks with adequate reliability it may not be necessary to use a mechanism to improve reliability of the Rekey Message. For these networks the ReliabilityMechanism NONE is appropriate. id-reliabilityNone OBJECT IDENTIFIER ::= {TBD} ReliabilityContentNone ::= NULL B.5.6.2 Rekey Reliability Mechanism Resend In networks with unknown or questionable reliability it may be necessary to use a mechanism to improve reliability of the Rekey Message. For these networks the ReliabilityMechanism RESEND is potentially appropriate. This mechanism has the GC/KS repeatedly sending out the same message. Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 26] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 id-reliabilityResend OBJECT IDENTIFIER ::= {TBD} ReliabilityResendInfo ::= INTEGER The INTEGER value in the ReliabilityResendInfo indicates the number of times the message should be resent. B.5.6.3 Rekey Reliability Mechanism Post Another reliability mechanims is to post the rekey message on some service that will make it generally available. This is the reliabilityPost method. id-reliabilityPost OBJECT IDENTIFIER ::= {TBD} ReliabilityContentPost ::= IA5String The IA5String associated with ReliabilityPost is the identifier of the posting site and rekey message. B.5.7 Distributed Operation Policy The policy dictating the relationships between GC/KS and S-GC/KS for distributed operations is defined as SubGCKSInfo. It is defined as a couple of a subGCKSScheme and some information relating to that Scheme in sGCKSContent. SubGCKSInfo ::= SEQUENCE { subGCKSScheme OBJECT IDENTIFIER, sGCKSContent OCTET STRING } B.5.7.1 No Distributed Operation If the group is not to use S-GC/KS then that Scheme would be SGCKSSchemeNone. id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {TBD} SGCKSNoneContent ::= NULL Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 27] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 B.5.7.2 Autonomous Distributed Mode If the group is to use S-GC/KS as defined in the GSAKMP specification as Autonomous mode, then that scheme would be SGCKSAutonomous. id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= {TBD} SGCKSAutonomous ::= SEQUENCE { authSubs GCKSName, domain OCTET STRING OPTIONAL } The policy information needed for autonomous mode is a list of authorized S-GC/KSs and and restrictions on who they may serve. The domain field, representing these restrictions is NULL for this version. B.6 GSAKMPv1 Rekey Policy ASN.1 Module GSAKMPv1RekeySA {TBD} DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS GCKSName FROM GSAKMPv1RegistrationSA {TBD} LifeDate FROM PolicyToken {TBD}; id-GSAKMPv1Rekey OBJECT IDENTIFIER::= {TBD} GSAKMPv1RekeyInfo ::= SEQUENCE { authorization RekeyAuthorization, mechanism RekeyMechanisms, rekeyEventDef RekeyEventDef, -- tells the GCKS when to rekey rekeyMethod RekeyMethod, rekeyInterval LifeDate, -- member knows when to rejoin reliability Reliability, -- what mech will be used to increase -- the likelyhood of rekey delivery subGCKSInfo SubGCKSInfo -- what subordinate gcks needs } RekeyAuthorization ::= GCKSName Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 28] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 RekeyMechanisms ::= SEQUENCE { sigAlgorithm INTEGER, hashAlgorithm INTEGER } RekeyEventDef ::= CHOICE { none [0] NULL, -- never rekey timeOnly [1] LifeDate, -- rekey every x units event [2] INTEGER, -- rekey after x events timeAndEvent [3] TimeAndEvent } TimeAndEvent ::= SEQUENCE { time LifeDate, -- rekey after x units of time OR event INTEGER -- x events occur } RekeyMethod ::= SEQUENCE { rekeyMethodType OBJECT IDENTIFIER, rekeyMethodInfo OCTET STRING } -- REKEY METHOD NONE -- id-rekeyNone OBJECT IDENTIFIER ::= {TBD} RekeyMethodNoneInfo ::= NULL -- REKEY METHOD GSAKMP LKH -- id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {TBD} RekeyMethodGSAKMPLKHInfo ::= INTEGER -- gsakmp type value for wrapping -- mechanism Reliability ::= SEQUENCE { reliabilityMechanism OBJECT IDENTIFIER, reliabilityMechContent OCTET STRING } -- RELIABILITY MECHANISM NONE -- id-reliabilityNone OBJECT IDENTIFIER ::= {TBD} ReliabilityContentNone ::= NULL -- RELIABILITY MECHANISM RESEND -- id-reliabilityResend OBJECT IDENTIFIER ::= {TBD} ReliabilityResendInfo ::= INTEGER -- # of times rekey message should be resent Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 29] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 -- RELIABILITY MECHANISM POST -- id-reliabilityPost OBJECT IDENTIFIER ::= {TBD} ReliabilityContentPost ::= IA5String SubGCKSInfo ::= SEQUENCE { subGCKSScheme OBJECT IDENTIFIER, sGCKSContent OCTET STRING } id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {TBD} SGCKSNoneContent ::= NULL id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= {TBD} SGCKSAutonomous ::= NULL END C APPENDIX C -- Data SA Policy The Data SA provides the data structures needed for the protection of the data exchanged between group members. This appendix defines the specific data structure needed for one such client of a group security protocol, Secure Real Time Protocol (SRTP) [RFC 3711]. C.1 RFC 3711 Data Policy The RFC 3711 Data Policy has the following identifier: id-rfc3711DataSA OBJECT IDENTIFIER ::= {TBD} RFC3711DataSAInfo describes the Policy for RFC 3711 and includes one or two KeyIndicators for the Master Key, a KeyIndicator for the Master Salt Key if one is given, a pseudo-random function (PRF) for derivation of keys, security association information for STRP, and security association information for SRTCP. The Master Key, and when used, the Master Salt Key are provided by the key management protocol. Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 30] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 RFC3711DataSAInfo ::= SEQUENCE { keyTrigger KeyIndicator, altKeyTrigger KeyIndicator OPTIONAL, masterSaltKeyID OCTET STRING (SIZE (4)) OPTIONAL, pRF PRF, sRTPSA SRTPSA, sRTCPSA SRTCPSA } KeyIndicators may be of the form of an OCTET STRING Master Key Indicator (MKI) or may be of the form of a field as described in RFC 3711. If two Key Indictors are PRESENT, then they MUST be of different types. KeyIndicator ::= CHOICE { mKI [0] OCTET STRING (SIZE (4)), tOfROM [1] OCTET STRING } SRTPSA, the SA decription for STRP, includes encryption information, authentication information if required by policy for a particular group, a key derivation rate to describe the periodicity of key refreshment, and a maximum number of packets to be used with an SA. SRTPSA ::= SEQUENCE { encrTransformData EncryptionTransformData, authTransformData AuthenticationTransformData OPTIONAL, keyDerivRate INTEGER, sRTPPacketMax INTEGER } EncryptionTransformData describes the encryption information within a particular SA. It describes the Encryption Transform to be used, the prefixLength, the length of the encryption key to be derived for the EncryptionTransform, and the length of the sessionSalt, if salt is used. EncryptionTransformData ::= SEQUENCE { encrTransform EncryptionTransform, prefixLength INTEGER, encrKeyLength INTEGER, sessionSaltLength INTEGER OPTIONAL } Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 31] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 EncryptionTransform is the encryption algorithm to be used in the SA. The choices for SRTP and STRCP are AES Counter Mode, NULL encryption, and AES F8. EncryptionTransform ::= ENUMERATED { aesCM (0), null (1), aesF8 (2) } AuthenticationTransformData describes the authentication information for an SA. It includes the AuthenticationTransform, the authentication tagLength, and the length of the authentication key, authKeyLength. AuthenticationTransformData ::= SEQUENCE { authTransform AuthenticationTransform, tagLength INTEGER, authKeyLength INTEGER } Authentication Transform is the choice of authentication algorithm used. Its current single choice of hmacSHA1 is enumerated as follows: AuthenticationTransform ::= ENUMERATED { hmacSHA1 (0) } SRTCPSA, the SA information for SRTCP, is similar to SRTPSA. The exception is that AuthenticationTransformData MUST be provided for every group. SRTCPSA ::= SEQUENCE { encrTransformData EncryptionTransformData, authTransformData AuthenticationTransformData, keyDerivRate INTEGER, sRTCPPacketMax INTEGER } Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 32] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 C.2 Secure RTP Data Policy ASN.1 Module RFC3711DataSA {TBD} DEFINITIONS IMPLICIT TAGS ::= BEGIN -- RTP DATA APPLICATION -- id-rfc3711DataSA OBJECT IDENTIFIER ::= {TBD} RFC3711DataSAInfo ::= SEQUENCE { keyTrigger KeyIndicator, altKeyTrigger KeyIndicator OPTIONAL, masterSaltKeyID OCTET STRING (SIZE (4)) OPTIONAL, pRF PRF, sRTPSA SRTPSA, sRTCPSA SRTCPSA } KeyIndicator ::= CHOICE { mKI [0] OCTET STRING (SIZE (4)), tOfROM [1] OCTET STRING } SRTPSA ::= SEQUENCE { encrTransformData EncryptionTransformData, authTransformData AuthenticationTransformData OPTIONAL, keyDerivRate INTEGER, sRTPPacketMax INTEGER } EncryptionTransformData ::= SEQUENCE { encrTransform EncryptionTransform, prefixLength INTEGER, encrKeyLength INTEGER, sessionSaltLength INTEGER OPTIONAL } AuthenticationTransformData ::= SEQUENCE { authTransform AuthenticationTransform, tagLength INTEGER, authKeyLength INTEGER } EncryptionTransform ::= ENUMERATED { aesCM (0), null (1), aesF8 (2) } Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 33] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 AuthenticationTransform ::= ENUMERATED { hmacSHA1 (0) } PRF ::= ENUMERATED { aesCM (0) } SRTCPSA ::= SEQUENCE { encrTransformData EncryptionTransformData, authTransformData AuthenticationTransformData, keyDerivRate INTEGER, sRTCPPacketMax INTEGER } END D APPENDIX D -- Change History (To Be Removed from RFC) D.1 Changes from Group Policy Token v-00 to v-01, December 2004 - Editorial/Grammatical changes throughout the document. - Core Policy Token ASN.1 Module Appendix rewritten. - GSAKMPv1 Registration ASN.1 Module Appendix rewritten. - GSAKMPv1 De-Registration ASN.1 Module Appendix rewritten. - GSAKMPv1 Rekey Policy ASN.1 Module Appendix rewritten. - RFC 3711 Policy Appendix was rewritten. Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 34] INTERNET-DRAFT Group Policy Token V1 with Application to GSAKMPDecember 2004 Authors Addresses Andrea Colegrove SPARTA, Inc. 7075 Samuel Morse Drive Columbia, MD 21046 (410) 872-1515 ext 232 FAX (410) 872-8079 acc@sparta.com Hugh Harney SPARTA, Inc. 7075 Samuel Morse Drive Columbia, MD 21046 (410) 872-1515 ext 203 FAX (410) 872-8079 hh@sparta.com Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Document expiration: June 30, 2005 Colegrove and Harney draft-ietf-msec-policy-token-sec-01.txt [Page 35]