summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4534.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4534.txt')
-rw-r--r--doc/rfc/rfc4534.txt1851
1 files changed, 1851 insertions, 0 deletions
diff --git a/doc/rfc/rfc4534.txt b/doc/rfc/rfc4534.txt
new file mode 100644
index 0000000..ed052de
--- /dev/null
+++ b/doc/rfc/rfc4534.txt
@@ -0,0 +1,1851 @@
+
+
+
+
+
+
+Network Working Group A. Colegrove
+Request for Comments: 4534 H. Harney
+Category: Standards Track SPARTA, Inc.
+ June 2006
+
+
+ Group Security Policy Token v1
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ The Group Security Policy Token is a structure used to specify the
+ security policy and configurable parameters for a cryptographic
+ group, such as a secure multicast group. Because the security of a
+ group is composed of the totality of multiple security services,
+ mechanisms, and attributes throughout the communications
+ infrastructure, an authenticatable representation of the features
+ that must be supported throughout the system is needed to ensure
+ consistent security. This document specifies the structure of such a
+ token.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 1]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Token Creation and Receipt ......................................4
+ 3. The Policy Token ................................................5
+ 3.1. Token Identifiers ..........................................6
+ 3.2. Registration Policy ........................................6
+ 3.3. Rekey Policy ...............................................7
+ 3.4. Group Data Policy ..........................................8
+ 4. Security Considerations .........................................8
+ 5. IANA Considerations .............................................8
+ 6. References.......................................................9
+ 6.1. Normative References .......................................9
+ 6.2. Informative References ....................................10
+ 7. Acknowledgements ...............................................10
+ Appendix A. Core Policy Token ASN.1 Module ........................11
+ Appendix B. GSAKMPv1 Base Policy ..................................13
+ B.1. GSAKMPv1 Registration Policy ..............................13
+ B.1.1. Authorization .......................................13
+ B.1.2. AccessControl .......................................14
+ B.1.3. JoinMechanisms ......................................15
+ B.1.3.1. alaCarte ...................................15
+ B.1.3.2. suite ......................................17
+ B.1.4. Transport ...........................................17
+ B.2. GSAKMPv1 Registration ASN.1 Module ........................17
+ B.3. GSAKMPv1 De-Registration Policy ...........................20
+ B.4. GSAKMPv1 De-Registration ASN.1 Module .....................21
+ B.5. GSAKMPv1 Rekey Policy .....................................22
+ B.5.1. Rekey Authorization ................................22
+ B.5.2. Rekey Mechanisms ...................................23
+ B.5.3. Rekey Event Definition .............................23
+ B.5.4. Rekey Methods ......................................24
+ B.5.4.1 Rekey Method NONE ..........................24
+ B.5.4.2 Rekey Method GSAKMP LKH ....................24
+ B.5.5 Rekey Interval ......................................25
+ B.5.6 Rekey Reliability ...................................25
+ B.5.6.1 Rekey Reliability Mechanism None ............25
+ B.5.6.2 Rekey Reliability Mechanism Resend ..........25
+ B.5.6.3 Rekey Reliability Mechanism Post ............26
+ B.5.7 Distributed Operation Policy ........................26
+ B.5.7.1 No Distributed Operation ....................26
+ B.5.7.2 Autonomous Distributed Mode .................26
+ B.6. GSAKMPv1 Rekey Policy ASN.1 Module ........................27
+ Appendix C. Data SA Policy ........................................30
+ C.1. Generic Data Policy .......................................30
+ C.2. Generic Data Policy ASN.1 Module ..........................30
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 2]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+1. Introduction
+
+ The Multicast Group Security Architecture [RFC3740] 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 the member
+ is submitting to the group.
+
+ The policy token is specified in ASN.1 [X.208] and is to be DER
+ [X.660] 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 & Harney Standards Track [Page 3]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+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 Cryptographic Message Syntax (CMS) [RFC3852] SignedData
+ type.
+
+ The content of the SignedData is the token itself. It is represented
+ with the ContentType object identifier of
+
+ id-ct-msec-token OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.1.1}
+
+ The CMS sid value of the SignerInfo, which identifies the public key
+ needed to validate the signature, 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.
+
+ 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 successfully validates in
+ accordance with RFC 3852.
+
+ - 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 4]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+3. The Policy Token
+
+ The structure of the policy token is as follows:
+
+ 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
+ de-registration 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 de-registration of members. A member MUST be able to support
+ at least one set of Registration mechanisms 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 MUST 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 MUST 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.
+
+ For the registration, rekey, and data fields, implementations
+ encountering unknown protocol identifiers MUST handle this gracefully
+ by providing indicators that an unknown protocol is among the
+ sequence of permissible protocols. If the unknown protocol is the
+ only allowable protocol in the sequence, then the implementation
+ cannot support that field, and the member cannot join the group. It
+ is a matter of local policy whether a join is permitted when an
+ unknown protocol exists among the allowable, known protocols.
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 5]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+ Protocols in addition to registration, rekey, and data SHOULD NOT be
+ added to subsequent versions of this Token unless the MSEC
+ architecture changes.
+
+ Each data field of the PT is specified further in the following
+ sections.
+
+3.1. Token Identifiers
+
+ tokenInfo explicitly identifies a version of the policy token for a
+ particular group. It is defined as
+
+ TokenID ::= SEQUENCE {
+ tokenDefVersion INTEGER (1),
+ groupName OCTET STRING,
+ edition INTEGER OPTIONAL
+ }
+
+ tokenDefVersion is the version of the Group Policy Token
+ Specification. This specification (v1) is represented as one
+ (1). Changes to the structure of the Group Security Policy Token
+ will require an update to this field.
+
+ groupName is the identifier of the group and MUST be unique relative
+ to the Group Owner.
+
+ 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.
+
+ The type LifeDate is also defined to provide standard methods of
+ indicating timestamps and intervals in the Tokens.
+
+ LifeDate ::= CHOICE {
+ gt GeneralizedTime,
+ utc UTCTime,
+ interval INTEGER
+ }
+
+3.2. Registration Policy
+
+ The registration security association (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 the group and participate
+ in the group Data SA.
+
+
+
+
+Colegrove & Harney Standards Track [Page 6]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+ The de-registration piece allows a current group member to notify the
+ Group Controller Key Server (GC/KS) that it will no longer be
+ participating in the Data SA.
+
+ Registration ::= SEQUENCE {
+ register GroupMngmtProtocol,
+ de-register GroupMngmtProtocol
+ }
+
+ The protocols for registration and de-registration are each specified
+ as
+
+ GroupMngmtProtocol ::= CHOICE {
+ none NULL,
+ supported Protocol
+ }
+
+ Protocol ::= SEQUENCE {
+ protocol OBJECT IDENTIFIER,
+ protocolInfo OCTET STRING
+ }
+
+ For example, register might be specified as the Group Secure
+ Association Key Management Protocol (GSAKMP) [RFC4535] 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 Policy
+
+ The Rekey SA is defined in the MSEC Architecture. During the Rekey
+ of a group, several changes can potentially be made:
+
+ - refresh/change group protection keys,
+
+ - update the policy token,
+
+ - change the group membership.
+
+ During Rekey, the membership of the group can be modified as well as
+ refreshing the group traffic protection keys and updating the Policy
+ Token.
+
+ This field is also specified as a sequence of protocols that will be
+ used by the GC/KS.
+
+
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 7]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+3.4. Group Data Policy
+
+ 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 group keys, ranging from simple security
+ applications that only need key for encryption and/or integrity
+ protection to more complex configurable security protocols such as
+ IPsec and Secure Real-time Transport Protocol (SRTP) [RFC3711]. 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
+
+ This 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 have been assigned:
+
+ - id-ct-msec-token OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.1.1
+
+ - id-securitySuiteOne OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.2.1
+
+ - id-GSAKMPv1RegistrationProtocol
+ OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.1
+
+ - id-GSAKMPv1DeRegistrationProtocol
+ OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.2
+
+ - id-GSAKMPv1Rekey OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.3
+
+
+
+
+Colegrove & Harney Standards Track [Page 8]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+ - id-rekeyNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.4.1
+
+ - id-rekeyMethodGSAKMPLKH
+ OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.4.2
+
+ - id-reliabilityNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.1
+
+ - id-reliabilityResend OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.2
+
+ - id-reliabilityPost OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.3
+
+ - id-subGCKSSchemeNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.6.1
+
+ - id-subGCKSSchemeAutonomous
+ OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.6.2
+
+ - id-genericDataSA OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.7.1
+
+ The Group Security Policy Token can be extended through
+ specification. Extensions in the form of objects can be registered
+ through IANA. Extensions requiring changes to the protocol structure
+ will require an update to the tokenDefVersion field of the TokenID
+ (see Section 3.1).
+
+6. References
+
+6.1. Normative References
+
+ [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
+ Group Secure Association Key Management Protocol", RFC
+ 4535, June 2006.
+
+ [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+ X.509 Public Key Infrastructure Certificate and Certificate
+ Revocation List (CRL) Profile", RFC 3280, April 2002.
+
+ [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+ 3852, July 2004.
+
+ [X.208] Recommendation X.208, Specification of Abstract Syntax
+ Notation One (ASN.1), 1988.
+
+ [X.660] Recommendation X.660, Information Technology ASN.1 Encoding
+ Rules: Specification of Basic Encoding Rules (BER),
+ Canonical Encoding Rules (CER), and Distinguished Encoding
+ Rules (DER), 1997.
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 9]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+6.2. Informative References
+
+ [HCLM00] Harney, H., Colegrove, A., Lough, P., and U. Meth, "GSAKMP
+ Token Specification", Work in Progress, February 2003.
+
+ [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+ Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+ RFC 3711, March 2004.
+
+ [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
+ Architecture", RFC 3740, 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] Hardjono, T., Harney, H., McDaniel, P., Colegrove, A., and
+ P. Dinsmore, "Group Security Policy Token: Definition and
+ Payloads", Work in Progress, August 2003.
+
+7. Acknowledgements
+
+ The following individuals deserve recognition and thanks for their
+ contributions, which have greatly improved this specification: Uri
+ Meth, whose knowledge of GSAKMP and tokens was greatly appreciated as
+ well as his help in getting this document submitted; 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; and Rod Fleischer for
+ catching implementation issues.
+
+ The following technical works influenced the design of the Group
+ Security Policy Token: [HCLM00], [HCM01], and [HHMCD01]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 10]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+Appendix A. Core Policy Token ASN.1 Module
+
+ PolicyToken
+ {1.3.6.1.5.5.12.0.1}
+
+ DEFINITIONS IMPLICIT TAGS ::=
+
+ BEGIN
+
+ Token ::= SEQUENCE {
+ tokenInfo TokenID,
+ registration SEQUENCE OF Registration,
+ rekey SEQUENCE OF GroupMngmtProtocol,
+ data SEQUENCE OF DataProtocol
+ }
+
+ ------------------------------------------------------------
+ -- Token ID
+
+ TokenID ::= SEQUENCE {
+ tokenDefVersion INTEGER (1), -- Group Security Policy Token v1
+ groupName OCTET STRING,
+ edition INTEGER OPTIONAL
+ }
+
+ LifeDate ::= CHOICE {
+ gt GeneralizedTime,
+ utc UTCTime,
+ interval INTEGER
+ }
+
+ ------------------------------------------------------------
+ -- Registration
+
+ Registration ::= SEQUENCE {
+ register GroupMngmtProtocol,
+ de-register GroupMngmtProtocol
+ }
+
+ ------------------------------------------------------------
+ -- GroupMngmtProtocol
+
+ GroupMngmtProtocol ::= CHOICE {
+ none NULL,
+ supported Protocol
+ }
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 11]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+ Protocol ::= SEQUENCE {
+ protocol OBJECT IDENTIFIER,
+ protocolInfo OCTET STRING
+ }
+
+ ------------------------------------------------------------
+ -- DataProtocol
+
+ DataProtocol ::= Protocol
+
+ ------------------------------------------------------------
+
+ END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 12]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+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::= {1.3.6.1.5.5.12.3.1}
+
+ 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. It also can
+ indicate if there are limitations on who can send data in a
+ group.
+
+ JoinAuthorization ::= SEQUENCE {
+ gCKS GCKSName,
+ subGCKS SEQUENCE OF GCKSName OPTIONAL,
+ senders SenderAuthorization
+ }
+
+ The authorization information is in the form of an access control
+ list indicating entity name and acceptable certification authority
+ information for the entity's certificate.
+
+ GCKSName ::= SEQUENCE OF UserCAPair
+
+
+
+
+Colegrove & Harney Standards Track [Page 13]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+ 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 [RFC3280] key
+ identifier.
+
+ CertAuth ::= KeyIdentifier
+
+ Senders within a group either can be all (indicating no sender
+ restrictions) or can be an explicit list of those members authorized
+ to send data.
+
+ SenderAuthorization ::= CHOICE {
+ all [0] NULL,
+ limited [1] EXPLICIT SEQUENCE OF UserCAPair
+ }
+
+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 may be provided.
+
+ AccessControl ::= SEQUENCE {
+ permissions [1] EXPLICIT SEQUENCE OF Permission OPTIONAL,
+ accessRule [2] EXPLICIT SEQUENCE OF UserCAPair,
+ exclusionsRule [3] EXPLICIT SEQUENCE OF UserCAPair OPTIONAL
+ }
+
+ The permissions initially available are an abstract set of numeric
+ levels that may be interpreted internal to a community.
+
+
+
+
+Colegrove & Harney Standards Track [Page 14]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+ 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
+ }
+
+B.1.3.1. alaCarte
+
+ 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.
+
+ Mechanisms ::= SEQUENCE {
+ signatureDef SigDef,
+ kEAlg KEAlg,
+ keyWrap KeyWrap,
+ ackData AckData,
+ opInfo OpInfo
+ }
+
+
+
+
+Colegrove & Harney Standards Track [Page 15]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+ 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 ::= SEQUENCE {
+ sigAlgorithmID INTEGER,
+ hashAlgorithmID INTEGER
+ }
+
+ The INTEGER corresponding to hashAlgorithm will map to the GSAKMP
+ Nonce Hash type values. This algorithm is used in computing the
+ combined nonce.
+
+ The key exchange algorithm requires an integer to define the GSAKMP
+ key creation type and may require additional per type data.
+
+ 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. timeOut indicates the elapsed amount of time
+ before a sent message is considered to be misrouted or lost. It
+ is specified as the timestamp type LifeDate, previously defined
+ in the core token. terse informs a GC/KS whether the group
+ should be operated in terse (TRUE) or verbose (FALSE) mode. The
+ optional timestamp field indicates whether a timestamp (TRUE) or
+ a nonce (FALSE) is used for anti-replay protection. If the field
+ is absent, the use of nonces is the default mode for GSAKMP
+ registration.
+
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 16]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+ OpInfo ::= SEQUENCE {
+ timeOut LifeDate,
+ terse BOOLEAN,
+ timestamp BOOLEAN OPTIONAL
+ }
+
+B.1.3.2. suite
+
+ 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 ::= {1.3.6.1.5.5.12.2.1}
+
+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
+ }
+
+B.2. GSAKMPv1 Registration ASN.1 Module
+
+ GSAKMPv1RegistrationSA
+ {1.3.6.1.5.5.12.0.2}
+
+ DEFINITIONS IMPLICIT TAGS ::=
+
+ BEGIN
+ EXPORTS
+ GCKSName;
+
+ IMPORTS
+ LifeDate
+ FROM PolicyToken {1.3.6.1.5.5.12.0.1}
+
+
+
+
+Colegrove & Harney Standards Track [Page 17]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+ 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::= {1.3.6.1.5.5.12.7}
+
+ GSAKMPv1RegistrationInfo ::= SEQUENCE {
+ joinAuthorization JoinAuthorization,
+ joinAccessControl SEQUENCE OF AccessControl,
+ joinMechanisms JoinMechanisms,
+ transport Transport
+ }
+
+ JoinAuthorization ::= SEQUENCE {
+ gCKS GCKSName,
+ subGCKS SEQUENCE OF GCKSName OPTIONAL,
+ senders SenderAuthorization
+ }
+
+ GCKSName ::= SEQUENCE OF UserCAPair
+
+ UserCAPair ::= SEQUENCE {
+ groupEntity GSAKMPID,
+ cA CertAuth
+ }
+
+ CertAuth ::= KeyIdentifier
+
+ SenderAuthorization ::= CHOICE {
+ all [0] NULL,
+ limited [1] EXPLICIT SEQUENCE OF UserCAPair
+ }
+
+ AccessControl ::= SEQUENCE {
+ permissions [1] EXPLICIT SEQUENCE OF Permission OPTIONAL,
+ accessRule [2] EXPLICIT SEQUENCE OF UserCAPair,
+ exclusionsRule [3] EXPLICIT SEQUENCE OF UserCAPair OPTIONAL
+ }
+
+ Permission ::= CHOICE {
+ simplePermission [1] SimplePermission
+ }
+
+
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 18]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+ 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 ::= {1.3.6.1.5.5.12.2.1}
+
+ SigDef ::= SEQUENCE {
+ sigAlgorithmID INTEGER,
+ hashAlgorithmID INTEGER
+ }
+
+ KEAlg ::= SEQUENCE {
+ keyExchangeAlgorithmID INTEGER,
+ keyExchangeAlgorithmData OCTET STRING OPTIONAL
+ }
+
+ KeyWrap ::= INTEGER
+
+
+
+Colegrove & Harney Standards Track [Page 19]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+ AckData ::= CHOICE {
+ none [0] NULL
+ }
+
+ OpInfo ::= SEQUENCE {
+ timeOut LifeDate,
+ terse BOOLEAN,
+ timestamp BOOLEAN OPTIONAL
+ }
+
+ 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::=
+ {1.3.6.1.5.5.12.3.2}
+
+ 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 SEQUENCE OF 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 & Harney Standards Track [Page 20]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+ 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 Public Key Infrastructure for
+ X.509 Certificates (PKIX) KeyIdentifier [RFC3280] 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
+ {1.3.6.1.5.5.12.0.3}
+
+ 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::= {1.3.6.1.5.5.12.3.2}
+
+ GSAKMPv1DeRegistrationInfo ::= SEQUENCE {
+ leaveMechanisms SEQUENCE OF LeaveMechanisms,
+ transport Transport
+ }
+
+
+
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 21]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+ LeaveMechanisms ::= SEQUENCE {
+ sigAlgorithm INTEGER,
+ hashAlgorithm INTEGER,
+ cA KeyIdentifier
+ }
+
+ Transport ::= CHOICE {
+ tcp [0] NULL,
+ udp [1] NULL
+ }
+
+ 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::= {1.3.6.1.5.5.12.0.4}
+
+ 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 likelihood of a rekey delivery (if any), and
+ finally an indication of how subordinate-GC/KSes 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,
+ rekeyMethod RekeyMethod,
+ rekeyInterval LifeDate,
+ reliability Reliability,
+ subGCKSInfo SubGCKSInfo
+ }
+
+B.5.1. Rekey Authorization
+
+ RekeyAuthorization ::= GCKSName
+
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 22]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+B.5.2. Rekey Mechanisms
+
+ The policy dictating the mechanisms needed for rekey message
+ processing is defined by RekeyMechanisms. This field is specified as
+
+ 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, whichever 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 (a GC/KS clock for sending rekey
+ messages or a member clock for determining whether a message has been
+ missed).
+
+ 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 notifications.
+
+ The TimeAndEvent is defined as a couple of the LifeDate and Integer
+ policies.
+
+
+
+
+Colegrove & Harney Standards Track [Page 23]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+ TimeAndEvent ::= SEQUENCE {
+ time LifeDate, -- rekey after x units of time OR
+ event INTEGER -- x events occur
+ }
+
+B.5.4. Rekey Methods
+
+ The rekey method defines the policy of how the rekey is to be
+ accomplished. 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 ::= {1.3.6.1.5.5.12.4.1}
+
+ 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 ::= {1.3.6.1.5.5.12.4.2}
+
+ 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 & Harney Standards Track [Page 24]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+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 single push message.
+ There are reliability concerns with such non-acknowledged messages
+ (i.e., message exchange). 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 ::= {1.3.6.1.5.5.12.5.1}
+
+ 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.
+
+ id-reliabilityResend OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.2}
+
+ ReliabilityResendInfo ::= INTEGER
+
+ The INTEGER value in the ReliabilityResendInfo indicates the number
+ of times the message should be resent.
+
+
+
+
+Colegrove & Harney Standards Track [Page 25]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+B.5.6.3. Rekey Reliability Mechanism Post
+
+ Another reliability mechanism is to post the rekey message on some
+ service that will make it generally available. This is the
+ reliabilityPost method.
+
+ id-reliabilityPost OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.3}
+
+ 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 ::= {1.3.6.1.5.5.12.6.1}
+
+ SGCKSNoneContent ::= NULL
+
+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 ::= {1.3.6.1.5.5.12.6.2}
+
+ SGCKSAutonomous ::= SEQUENCE {
+ authSubs GCKSName,
+ domain OCTET STRING OPTIONAL
+ }
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 26]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+ The policy information needed for autonomous mode is a list of
+ authorized S-GC/KSes 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
+ {1.3.6.1.5.5.12.0.4}
+
+ DEFINITIONS IMPLICIT TAGS ::=
+
+ BEGIN
+
+ IMPORTS
+ GCKSName
+ FROM GSAKMPv1RegistrationSA {1.3.6.1.5.5.12.0.2}
+ LifeDate
+ FROM PolicyToken {1.3.6.1.5.5.12.0.1};
+
+ id-GSAKMPv1Rekey OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.0.4}
+
+ 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
+ }
+
+ RekeyAuthorization ::= GCKSName
+
+ RekeyMechanisms ::= SEQUENCE {
+ sigAlgorithm INTEGER,
+ hashAlgorithm INTEGER
+ }
+
+ RekeyEventDef ::= CHOICE {
+ none [0] NULL, -- never rekey
+ timeOnly [1] EXPLICIT LifeDate, -- rekey every x units
+ event [2] INTEGER, -- rekey after x events
+ timeAndEvent [3] TimeAndEvent
+ }
+
+
+
+
+Colegrove & Harney Standards Track [Page 27]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+ 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 ::= {1.3.6.1.5.5.12.4.1}
+
+ RekeyMethodNoneInfo ::= NULL
+
+ -- REKEY METHOD GSAKMP LKH --
+
+ id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.4.2}
+
+ RekeyMethodGSAKMPLKHInfo ::= INTEGER -- gsakmp type value for
+ -- wrapping mechanism
+
+ Reliability ::= SEQUENCE {
+ reliabilityMechanism OBJECT IDENTIFIER,
+ reliabilityMechContent OCTET STRING
+ }
+
+ -- RELIABILITY MECHANISM NONE --
+
+ id-reliabilityNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.1}
+
+ ReliabilityContentNone ::= NULL
+
+ -- RELIABILITY MECHANISM RESEND --
+
+ id-reliabilityResend OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.2}
+
+ ReliabilityResendInfo ::= INTEGER -- # of times rekey message should
+ -- be resent
+
+ -- RELIABILITY MECHANISM POST --
+
+ id-reliabilityPost OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.3}
+
+ ReliabilityContentPost ::= IA5String
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 28]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+ SubGCKSInfo ::= SEQUENCE {
+ subGCKSScheme OBJECT IDENTIFIER,
+ sGCKSContent OCTET STRING
+ }
+
+ id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.1}
+
+ SGCKSNoneContent ::= NULL
+
+ id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.2}
+
+ SGCKSAutonomous ::= SEQUENCE {
+ authSubs GCKSName,
+ domain OCTET STRING OPTIONAL
+ }
+
+ END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 29]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+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 data structures needed for a simple, generic security application
+ making use of fixed security mechanisms. Such a Data SA requires
+ only that keys delivered by the registration and rekey protocols be
+ mapped to the service using them.
+
+C.1. Generic Data Policy
+
+ The Generic Data Policy has the following identifier:
+
+ id-genericDataSA OBJECT IDENTIFIER :: = {1.3.6.1.5.5.12.7.1}
+
+ If an authentication mechanism is used within the security
+ application, the key identifier (kMKeyID) used in the key management
+ protocol is given, as well as an optional key expiration date.
+ Likewise, if an encryption mechanism is used within the security
+ application, the encryption key identifier is given, as well as an
+ optional key expiration date (keyExpirationDate).
+
+ GenericDataSAInfo ::= SEQUENCE {
+ authentication [0] EXPLICIT KeyInfo OPTIONAL,
+ encryption [1] EXPLICIT KeyInfo OPTIONAL
+ }
+
+ KeyInfo ::= SEQUENCE{
+ kMKeyID OCTET STRING,
+ keyExpirationDate LifeDate OPTIONAL
+ }
+
+C.2. Generic Data Policy ASN.1 Module
+
+ GenericDataSA
+ {1.3.6.1.5.5.12.0.5}
+
+ DEFINITIONS IMPLICIT TAGS ::=
+
+ BEGIN
+
+ -- DATA APPLICATION: Generic
+ -- This token specification is for data applications with
+ -- fixed security mechanisms. Such data applications only
+ -- need a mapping of management protocol key identification
+ -- tags to security service.
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 30]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+ IMPORTS
+ LifeDate
+ FROM PolicyToken {1.3.6.1.5.5.12.0.1}
+
+ 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-genericDataSA OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.7.1}
+
+ GenericDataSAInfo ::= SEQUENCE {
+ authentication [0] EXPLICIT KeyInfo OPTIONAL,
+ encryption [1] EXPLICIT KeyInfo OPTIONAL
+ }
+
+ KeyInfo ::= SEQUENCE{
+ kMKeyID OCTET STRING,
+ keyExpirationDate LifeDate OPTIONAL
+ }
+
+ END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 31]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+Authors' Addresses
+
+ Andrea Colegrove
+ SPARTA, Inc.
+ 7110 Samuel Morse Drive
+ Columbia, MD 21046
+
+ Phone: (443) 430-8014
+ Fax: (443) 430-8163
+ EMail: acc@sparta.com
+
+
+ Hugh Harney
+ SPARTA, Inc.
+ 7110 Samuel Morse Drive
+ Columbia, MD 21046
+
+ Phone: (443) 430-8032
+ Fax: (443) 430-8181
+ EMail: hh@sparta.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 32]
+
+RFC 4534 Group Security Policy Token v1 June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ 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.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Colegrove & Harney Standards Track [Page 33]
+