draft-ietf-msec-policy-token-sec-06.txt   rfc4534.txt 
Internet Engineering Task Force Network Working Group A. Colegrove
INTERNET-DRAFT A Colegrove Request for Comments: 4534 H. Harney
H Harney Category: Standards Track SPARTA, Inc.
draft-ietf-msec-policy-token-sec-06.txt SPARTA, Inc.
Expires: July 23, 2006 January 2006
Group Security Policy Token v1 Group Security Policy Token v1
Status of this memo Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at Internet community, and requests discussion and suggestions for
any time. It is inappropriate to use Internet-Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2006).
http://www.ietf.org/shadow.html
Abstract Abstract
The Group Security Policy Token is a structure used to The Group Security Policy Token is a structure used to specify the
specify the security policy and configurable parameters security policy and configurable parameters for a cryptographic
for a cryptographic group, such as a secure multicast group, such as a secure multicast group. Because the security of a
group. Because the security of a group is comprised of group is composed of the totality of multiple security services,
the totality of multiple security services, mechanisms, and mechanisms, and attributes throughout the communications
attributes throughout the communications infrastructure, infrastructure, an authenticatable representation of the features
an authenticatable representation of the features that that must be supported throughout the system is needed to ensure
must be supported throughout the system is needed to ensure consistent security. This document specifies the structure of such a
consistent security. This document specifies the structure token.
of such a token.
Contents
1 Introduction 5
2 Token Creation and Receipt 6
3 The Policy Token 6
3.1 Token Identifiers . . . . . . . . . . . . . . . . . . . . . 8
3.2 Registration Policy . . . . . . . . . . . . . . . . . . . . 8
3.3 Rekey Policy . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Group Data Policy . . . . . . . . . . . . . . . . . . . . . 10
4 Security Considerations 10
5 IANA Considerations 10
6 References 11
6.1 Normative References . . . . . . . . . . . . . . . . . . . 11
6.2 Non-Normative References . . . . . . . . . . . . . . . . . 12
7 Acknowledgments 12
A APPENDIX A -- Core Policy Token ASN.1 Module 13
B APPENDIX B -- GSAKMPv1 Base Policy 15
B.1 GSAKMPv1 Registration Policy . . . . . . . . . . . . . . . 15
B.1.1 Authorization . . . . . . . . . . . . . . . . . . . . . 15
B.1.2 AccessControl . . . . . . . . . . . . . . . . . . . . . 17
B.1.3 JoinMechanisms . . . . . . . . . . . . . . . . . . . . 17
B.1.3.1 alaCarte . . . . . . . . . . . . . . . . . . . . 18
B.1.3.2 suite . . . . . . . . . . . . . . . . . . . . . . 19
B.1.4Transport . . . . . . . . . . . . . . . . . . . . . . . 20
B.2 GSAKMPv1 Registration ASN.1 Module . . . . . . . . . . . . 20
B.3 GSAKMPv1 De-Registration Policy . . . . . . . . . . . . . . 23
B.4 GSAKMPv1 De-Registration ASN.1 Module . . . . . . . . . . . 24
B.5 GSAKMPv1 Rekey Policy . . . . . . . . . . . . . . . . . . . 24
B.5.1 Rekey Authorization . . . . . . . . . . . . . . . . . . 25
B.5.2 Rekey Mechanisms . . . . . . . . . . . . . . . . . . . 25
B.5.3 Rekey Event Definition . . . . . . . . . . . . . . . . 26
B.5.4 Rekey Methods . . . . . . . . . . . . . . . . . . . . . 27
B.5.4.1 Rekey Method NONE . . . . . . . . . . . . . . . . 27
B.5.4.2 Rekey Method GSAKMP LKH . . . . . . . . . . . . . 27
B.5.5 Rekey Interval . . . . . . . . . . . . . . . . . . . . 28
B.5.6 Rekey Reliability . . . . . . . . . . . . . . . . . . . 28
B.5.6.1 Rekey Reliability Mechanism None . . . . . . . . 28
B.5.6.2 Rekey Reliability Mechanism Resend . . . . . . . 28
B.5.6.3 Rekey Reliability Mechanism Post . . . . . . . . 29
B.5.7 Distributed Operation Policy . . . . . . . . . . . . . 29
B.5.7.1 No Distributed Operation . . . . . . . . . . . . 29
B.5.7.2 Autonomous Distributed Mode . . . . . . . . . . . 30
B.6 GSAKMPv1 Rekey Policy ASN.1 Module . . . . . . . . . . . . 30
C APPENDIX C -- Data SA Policy 33
C.1 Generic Data Policy . . . . . . . . . . . . . . . . . . . . 33
C.2 Generic Data Policy ASN.1 Module . . . . . . . . . . . . . 34
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
D.2 Changes from Group Policy Token v-01 to v-02, March 2005 . 35
D.3 Changes from Group Policy Token v-02 to v-03, July 2005 . . 35
D.4 Changes from Group Policy Token v-03 to v-04, September 2005 35
D.5 Changes from Group Policy Token v-04 to v-05, December 2005 35
D.6 Changes from Group Policy Token v-05 to v-06, January 2006 35
Authors Addresses 37 Table of Contents
Full Copyright Statement 37
IPR Considerations 37 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
1 Introduction 1. Introduction
The Multicast Group Security Architecture [RFC3740] defines the The Multicast Group Security Architecture [RFC3740] defines the
security infrastructure to support secure group communications. The security infrastructure to support secure group communications. The
Policy Token assumes this architecture in its definition. It defines policy token assumes this architecture in its definition. It defines
the enforceable security parameters for a Group Secure Association. the enforceable security parameters for a Group Secure Association.
The Policy Token is a verifiable data construct signed by the group The policy token is a verifiable data construct signed by the Group
owner, the entity with the authorization to create security policy. Owner, the entity with the authorization to create security policy.
The group controllers in a group will use the policy token to ensure 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 that the mechanisms used to secure the group are correct and to
enforce the access control rules for joining members. The group enforce the access control rules for joining members. The group
members, who may contribute data to the group or access data from the 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 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 a trusted authority. Also, the members may want to verify that the
access control rules are adequate to protect the data that the member access control rules are adequate to protect the data that the member
is submitting to the group. is submitting to the group.
The Policy Token is specified in ASN.1 [X.208] and is to be DER 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 [X.660] encoded. This specification ability allows the token to
easily import group definitions that span different applications and easily import group definitions that span different applications and
environments. ASN.1 allows the token to specify branches that can environments. ASN.1 allows the token to specify branches that can be
be used by any multicast security protocol. Any group can use this used by any multicast security protocol. Any group can use this
policy token structure to specify the use of multiple protocols in policy token structure to specify the use of multiple protocols in
securing the group. securing the group.
Care was taken in this specification to provide a core level of token Care was taken in this specification to provide a core level of token
specificity that would allow ease of extensibility and flexibility specificity that would allow ease of extensibility and flexibility in
in supporting mechanisms. This was done by using the following supporting mechanisms. This was done by using the following
abstracted construct: abstracted construct:
Mechanism ::= SEQUENCE { Mechanism ::= SEQUENCE {
mechanismIdentifier OBJECT IDENTIFIER, mechanismIdentifier OBJECT IDENTIFIER,
mechanismParameters OCTET STRING mechanismParameters OCTET STRING
} }
This construct will allow the use of group mechanisms specified in This construct will allow the use of group mechanisms specified in
other documents with the Policy Token. other documents with the policy token.
The Policy Token is structured to reflect the MSEC Architecture The policy token is structured to reflect the MSEC Architecture
layers for a Group Security Association. Each of the architectural layers for a Group Security Association. Each of the architectural
layers is identified and given a branch in the "Core" token. layers is identified and given a branch in the "Core" token. This
This allows a high degree of flexibility for future protocol allows a high degree of flexibility for future protocol
specifications at each architectural layer without the need to change specifications at each architectural layer without the need to change
the "Core" policy token, which can then act as a single point of the "Core" policy token, which can then act as a single point of
reference for defining secure groups using any mix of protocols for reference for defining secure groups using any mix of protocols for
any number of environments. any number of environments.
2 Token Creation and Receipt 2. Token Creation and Receipt
At the time of group creation or whenever the policy of the group is At the time of group creation or whenever the policy of the group is
updated, the Group Owner will create a new policy token. updated, the Group Owner will create a new policy token.
To ensure authenticity of the specified policy, the Token MUST be To ensure authenticity of the specified policy, the Token MUST be
signed by the Group Owner. The signed token MUST be in accordance signed by the Group Owner. The signed token MUST be in accordance
with the CMS [RFC 3852] SignedData type. with the Cryptographic Message Syntax (CMS) [RFC3852] SignedData
type.
The content of the SignedData is the token itself. It is represented The content of the SignedData is the token itself. It is represented
with the ContentType object identifier of with the ContentType object identifier of
id-ct-msec-token OBJECT IDENTIFIER ::= {TBD} 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 The CMS sid value of the SignerInfo, which identifies the public key
needed to validate the signature, MUST be that of the Group Owner. needed to validate the signature, MUST be that of the Group Owner.
The signedAttrs field MUST be present. In addition to the minimally The signedAttrs field MUST be present. In addition to the minimally
required fields of signedAttrs, the signing-time attribute MUST be required fields of signedAttrs, the signing-time attribute MUST be
present. present.
Upon receipt of a Policy Token, the recipient MUST check that Upon receipt of a policy token, the recipient MUST check that
- the Group Owner, as identified by the sid in the SignerInfo, is - the Group Owner, as identified by the sid in the SignerInfo, is
the expected entity the expected entity.
- the signing-time value is more recent than the signing-time value - the signing-time value is more recent than the signing-time value
seen in a previously received Policy Token for that group, or the seen in a previously received policy token for that group, or the
Policy Token is the first token seen by the recipient for that policy token is the first token seen by the recipient for that
group. group.
- the processing of the signature successfully validates in - the processing of the signature successfully validates in
accordance with RFC 3852 accordance with RFC 3852.
- the specified security and communication mechanisms (or at least - the specified security and communication mechanisms (or at least
one mechanism of each choice) are supported and are in compliance one mechanism of each choice) are supported and are in compliance
with the recipient's local policy. with the recipient's local policy.
3 The Policy Token 3. The Policy Token
The structure of the Policy Token is as follows: The structure of the policy token is as follows:
Token ::= SEQUENCE { Token ::= SEQUENCE {
tokenInfo TokenID, tokenInfo TokenID,
registration SEQUENCE OF Registration, registration SEQUENCE OF Registration,
rekey SEQUENCE OF GroupMngmtProtocol, rekey SEQUENCE OF GroupMngmtProtocol,
data SEQUENCE OF DataProtocol data SEQUENCE OF DataProtocol
} }
tokenInfo provides information about the instance of the Policy tokenInfo provides information about the instance of the Policy Token
Token (PT). (PT).
registration provides a list of acceptable registration and registration provides a list of acceptable registration and
deregistration policy and mechanisms that may be used to manage de-registration policy and mechanisms that may be used to manage
member-initiated joins and departures from a group. A NULL member-initiated joins and departures from a group. A NULL
sequence indicates that the group does not support registration sequence indicates that the group does not support registration
and deregistration of members. A member MUST be able to support and de-registration of members. A member MUST be able to support
at least one set of Registration mechanisms in order to join at least one set of Registration mechanisms in order to join the
the group. When multiple mechanisms are present, a member MAY group. When multiple mechanisms are present, a member MAY use
use any of the listed methods. The list is ordered in terms of any of the listed methods. The list is ordered in terms of Group
Group Owner preference. A member MUST choose the highest listed Owner preference. A member MUST choose the highest listed
mechanism that local policy supports. mechanism that local policy supports.
rekey provides the rekey protocols that will be used in managing rekey provides the rekey protocols that will be used in managing the
the group. The member MUST be able to accept one of the types group. The member MUST be able to accept one of the types of
of rekey messages listed. The list is ordered in terms of rekey messages listed. The list is ordered in terms of Group
Group Owner preference. A member MUST choose the highest listed Owner preference. A member MUST choose the highest listed
mechanism that local policy supports. mechanism that local policy supports.
data provides the applications used in the communications between data provides the applications used in the communications between
group members. When multiple applications are provided, the group members. When multiple applications are provided, the
order of the list implies the order of encapsulation of the data. order of the list implies the order of encapsulation of the data.
A member MUST be able to support all the listed applications and A member MUST be able to support all the listed applications and
if any choices of mechanisms are provided per application, the if any choices of mechanisms are provided per application, the
member MUST support at least one of the mechanisms. member MUST support at least one of the mechanisms.
For the registration, rekey, and data fields, implementations For the registration, rekey, and data fields, implementations
encountering unknown protocol identifiers MUST handle this gracefully encountering unknown protocol identifiers MUST handle this gracefully
by providing indicators that an unknown protocol is among the by providing indicators that an unknown protocol is among the
sequence of permissible protocols. If the unknown protocol is the sequence of permissible protocols. If the unknown protocol is the
only allowable protocol in the sequence, then the implementation only allowable protocol in the sequence, then the implementation
cannot support that field, and the member cannot join the group. cannot support that field, and the member cannot join the group. It
It is a matter of local policy whether a join is permitted when an is a matter of local policy whether a join is permitted when an
unknown protocol exists among the allowable, known protocols. unknown protocol exists among the allowable, known protocols.
Protocols in addition to registration, rekey, and data SHOULD NOT Protocols in addition to registration, rekey, and data SHOULD NOT be
be added to subsequent versions of this Token unless the MSEC added to subsequent versions of this Token unless the MSEC
architecture changes. architecture changes.
Each data field of the PT is specified further in the following Each data field of the PT is specified further in the following
sections. sections.
3.1 Token Identifiers 3.1. Token Identifiers
tokenInfo explicitly identifies a version of the Policy Token for a tokenInfo explicitly identifies a version of the policy token for a
particular group. It is defined as particular group. It is defined as
TokenID ::= SEQUENCE { TokenID ::= SEQUENCE {
tokenDefVersion INTEGER (1), tokenDefVersion INTEGER (1),
groupName OCTET STRING, groupName OCTET STRING,
edition INTEGER OPTIONAL edition INTEGER OPTIONAL
} }
tokenDefVersion is the version of the Group Policy Token tokenDefVersion is the version of the Group Policy Token
Specification. This specifications (v1) is represented as one Specification. This specification (v1) is represented as one
(1). Changes to the structure of the Group Security Policy Token (1). Changes to the structure of the Group Security Policy Token
will require an update to this field. will require an update to this field.
groupName is the identifier of the group and MUST be unique relative groupName is the identifier of the group and MUST be unique relative
to the Group Owner. to the Group Owner.
edition is an optional INTEGER indicating the sequence number of the edition is an optional INTEGER indicating the sequence number of the
PT. If edition is present, group entities MUST accept a PT only 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 when the value is greater than the last value seen in a valid PT
for that group. for that group.
The type LifeDate is also defined to provide standard methods of The type LifeDate is also defined to provide standard methods of
indicating timestamps and intervals in the Tokens. indicating timestamps and intervals in the Tokens.
LifeDate ::= CHOICE { LifeDate ::= CHOICE {
gt GeneralizedTime, gt GeneralizedTime,
utc UTCTime, utc UTCTime,
interval INTEGER interval INTEGER
} }
3.2 Registration Policy 3.2. Registration Policy
The registration SA is defined in the MSEC Architecture. During The registration security association (SA) is defined in the MSEC
registration, a prospective group member and the group controller Architecture. During registration, a prospective group member and
will interact to give the group member access to the keys and the group controller will interact to give the group member access to
information it needs to join the group and participate in the group the keys and information it needs to join the group and participate
data SA. in the group Data SA.
The deregistration piece allows a current group member to notify the The de-registration piece allows a current group member to notify the
GC/KS that it will no longer be participating in the data SA. Group Controller Key Server (GC/KS) that it will no longer be
participating in the Data SA.
Registration ::= SEQUENCE { Registration ::= SEQUENCE {
register GroupMngmtProtocol, register GroupMngmtProtocol,
de-register GroupMngmtProtocol de-register GroupMngmtProtocol
} }
The protocol for registration and de-registration are each specified The protocols for registration and de-registration are each specified
as as
GroupMngmtProtocol ::= CHOICE { GroupMngmtProtocol ::= CHOICE {
none NULL, none NULL,
supported Protocol supported Protocol
} }
Protocol ::= SEQUENCE { Protocol ::= SEQUENCE {
protocol OBJECT IDENTIFIER, protocol OBJECT IDENTIFIER,
protocolInfo OCTET STRING protocolInfo OCTET STRING
} }
For example, register might be specified as the GSAKMP [HMCG] For example, register might be specified as the Group Secure
registration protocol. The OBJECT IDENTIFIER TBS would be followed Association Key Management Protocol (GSAKMP) [RFC4535] registration
by the parameters used in GSAKMP registration as specified in protocol. The OBJECT IDENTIFIER TBS would be followed by the
appendix B.1. parameters used in GSAKMP registration as specified in Appendix B.1.
3.3 Rekey Policy 3.3. Rekey Policy
The Rekey SA is defined in the MSEC Architecture. During the Rekey The Rekey SA is defined in the MSEC Architecture. During the Rekey
of a group, several changes can potentially be made: of a group, several changes can potentially be made:
- refresh/change group protection keys, - refresh/change group protection keys,
- update the Policy Token, - update the policy token,
- change the group membership. - change the group membership.
During Rekey, the membership of the group can be modified as well as During Rekey, the membership of the group can be modified as well as
refreshing the group traffic protection keys and updating the Policy refreshing the group traffic protection keys and updating the Policy
Token. Token.
This field is also specified as a sequence of protocols that will be This field is also specified as a sequence of protocols that will be
used by the GC/KS. used by the GC/KS.
3.4 Group Data Policy 3.4. Group Data Policy
The Data SA is the ultimate consumer of the group keys. The 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 field will indicate the keys and mechanisms that are to be used in
communications between group members. There are several protocols communications between group members. There are several protocols
that could make use of group keys, ranging from simple security that could make use of group keys, ranging from simple security
applications that only need key for encryption and/or integrity applications that only need key for encryption and/or integrity
protection to more complex configurable security protocols such as protection to more complex configurable security protocols such as
IPsec and SRTP. The sequencing of the Data SA mechanisms are from IPsec and Secure Real-time Transport Protocol (SRTP) [RFC3711]. The
"inside" to "outside". That is, the first Data SA defined in a sequencing of the Data SA mechanisms are from "inside" to "outside".
policy token must act on the raw data. Any data SA specified after That is, the first Data SA defined in a policy token must act on the
that will be applied in turn. raw data. Any Data SA specified after that will be applied in turn.
DataProtocol ::= Protocol DataProtocol ::= Protocol
4 Security Considerations 4. Security Considerations
This document specifies the structure for a Group Policy Token. As This document specifies the structure for a group policy token. As
such, the structure as received by a group entity must be verifiably such, the structure as received by a group entity must be verifiably
authentic. This Policy Token uses CMS to apply authentication authentic. This policy token uses CMS to apply authentication
through digital signatures. The security of this scheme relies through digital signatures. The security of this scheme relies upon
upon a secure CMS implementation, choice of signature mechanism a secure CMS implementation, choice of signature mechanism of
of appropriate strength for the group using the Policy Token, appropriate strength for the group using the policy token, and
and secure, sufficiently strong keys. Additionally, it relies secure, sufficiently strong keys. Additionally, it relies upon
upon knowledge of a well-known Group Owner as the root of policy knowledge of a well-known Group Owner as the root of policy
enforcement. enforcement.
Furthermore, while the Group Owner may list alternate mechanisms Furthermore, while the Group Owner may list alternate mechanisms for
for various functions, the group is only as strong as the weakest various functions, the group is only as strong as the weakest
accepted mechanisms. As such, the Group Owner is responsible for accepted mechanisms. As such, the Group Owner is responsible for
providing only acceptable security mechanisms. providing only acceptable security mechanisms.
5 IANA Considerations 5. IANA Considerations
The following object identifiers should be assigned: The following object identifiers have been assigned:
- id-ct-msec-token OBJECT IDENTIFIER ::= TBD - id-ct-msec-token OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.1.1
- id-securitySuiteOne OBJECT IDENTIFIER ::= TBD - id-securitySuiteOne OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.2.1
- id-GSAKMPv1RegistrationProtocol OBJECT IDENTIFIER::= TBD - id-GSAKMPv1RegistrationProtocol
OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.1
- id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= TBD - id-GSAKMPv1DeRegistrationProtocol
- id-GSAKMPv1Rekey OBJECT IDENTIFIER::= TBD OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.2
- id-rekeyNone OBJECT IDENTIFIER ::= TBD - id-GSAKMPv1Rekey OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.3
- id-rekeyNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.4.1
- id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= TBD - id-rekeyMethodGSAKMPLKH
OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.4.2
- id-reliabilityNone OBJECT IDENTIFIER ::= TBD - id-reliabilityNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.1
- id-reliabilityResend OBJECT IDENTIFIER ::= TBD - id-reliabilityResend OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.2
- id-reliabilityPost OBJECT IDENTIFIER ::= TBD - id-reliabilityPost OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.3
- id-subGCKSSchemeNone OBJECT IDENTIFIER ::= TBD - id-subGCKSSchemeNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.6.1
- id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= TBD - id-subGCKSSchemeAutonomous
OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.6.2
- id-genericDataSA OBJECT IDENTIFIER ::= TBD - id-genericDataSA OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.7.1
The Group Security Policy Token can be extended through The Group Security Policy Token can be extended through
specification. Extensions in the form of objects can be registered specification. Extensions in the form of objects can be registered
through IANA. Extensions requiring changes to the protocol structure through IANA. Extensions requiring changes to the protocol structure
will require an update to the tokenDefVersion field of the TokenID will require an update to the tokenDefVersion field of the TokenID
(see section 3.1). (see Section 3.1).
6 References
The following references were used in the preparation of this 6. References
document.
6.1 Normative References 6.1. Normative References
[HMCG] H. Harney, U. Meth, A. Colegrove, and G. Gross, "GSAKMP", [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
draft-ietf-msec-gsakmp-sec-10.txt, RFC Editor Queue, May 2005. Group Secure Association Key Management Protocol", RFC
4535, June 2006.
[RFC 3280] R. Housley, W. Polk, W. Ford, D. Solo, Internet X.509 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
Public Key Infrastructure Certificate and Certificate Revocation List X.509 Public Key Infrastructure Certificate and Certificate
(CRL) Profile, RFC 3280, April 2002. Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC 3852] R. Housley, Cryptographic Message Syntax, RFC 3825, July [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
2004. 3852, July 2004.
[X.208] Recommendation X.209, Specification of Abstract Syntax [X.208] Recommendation X.208, Specification of Abstract Syntax
Notation One (ASN.1), 1988. Notation One (ASN.1), 1988.
[X.660] Recommendation X.660, Information Technology ASN.1 Encoding [X.660] Recommendation X.660, Information Technology ASN.1 Encoding
Rules: Specification of Basic Encoding Rules (BER), Canonical Rules: Specification of Basic Encoding Rules (BER),
Encoding Rules (CER), and Distinguished Encoding Rules (DER), 1997. Canonical Encoding Rules (CER), and Distinguished Encoding
Rules (DER), 1997.
6.2 Non-Normative References 6.2. Informative References
[HCLM00] H. Harney, A. Colegrove, P. Lough, and U. Meth, "GSAKMP [HCLM00] Harney, H., Colegrove, A., Lough, P., and U. Meth, "GSAKMP
Token Specification", draft-ietf-msec-tokenspec-sec-00.txt. Token Specification", Work in Progress, February 2003.
[RFC 3711] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-Time Transport Protocol (SRTP)", RFC 3711, Norrman, "The Secure Real-time Transport Protocol (SRTP)",
March 2004. RFC 3711, March 2004.
[RFC 3740] T. Hardjono and B. Weis, "The Multicast Group Security [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004. Architecture", RFC 3740, March 2004.
[HCM01] H. Harney, A. Colegrove, P. McDaniel, "Principles of Policy [HCM01] H. Harney, A. Colegrove, P. McDaniel, "Principles of Policy
in Secure Groups", Proceedings of Network and Distributed Systems in Secure Groups", Proceedings of Network and Distributed
Security 2001 Internet Society, San Diego, CA, February 2001 Systems Security 2001 Internet Society, San Diego, CA,
February 2001.
[HHMCD01] , Thomas Hardjono, Hugh Harney, Pat McDaniel, Andrea [HHMCD01] Hardjono, T., Harney, H., McDaniel, P., Colegrove, A., and
Colgrove, Pete Dinsmore, Group Security Policy Token: Definition and P. Dinsmore, "Group Security Policy Token: Definition and
Payloads', draft-ietf-msec-gspt-00.txt, Expired. Payloads", Work in Progress, August 2003.
7 Acknowledgments 7. Acknowledgements
The following individuals deserve recognition and thanks for their The following individuals deserve recognition and thanks for their
contributions which have greatly improved this specification: Uri contributions, which have greatly improved this specification: Uri
Meth whose knowledge of GSAKMP and tokens was greatly appreciated Meth, whose knowledge of GSAKMP and tokens was greatly appreciated as
as well as his help in getting this document submitted; Peter Lough, well as his help in getting this document submitted; Peter Lough,
Thomas Hardjono, Patrick McDaniel, and Pete Dinsmore for their work Thomas Hardjono, Patrick McDaniel, and Pete Dinsmore for their work
on earlier versions of policy tokens; George Gross for the impetus to on earlier versions of policy tokens; George Gross for the impetus to
have a well-specified, extensible policy token; and Rod Fleischer for have a well-specified, extensible policy token; and Rod Fleischer for
catching implementation issues. catching implementation issues.
A APPENDIX A -- Core Policy Token ASN.1 Module The following technical works influenced the design of the Group
Security Policy Token: [HCLM00], [HCM01], and [HHMCD01]
PolicyToken -- {TBD} Appendix A. Core Policy Token ASN.1 Module
PolicyToken
{1.3.6.1.5.5.12.0.1}
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
Token ::= SEQUENCE { Token ::= SEQUENCE {
tokenInfo TokenID, tokenInfo TokenID,
registration SEQUENCE OF Registration, registration SEQUENCE OF Registration,
rekey SEQUENCE OF GroupMngmtProtocol, rekey SEQUENCE OF GroupMngmtProtocol,
data SEQUENCE OF DataProtocol data SEQUENCE OF DataProtocol
skipping to change at page 15, line 5 skipping to change at page 13, line 5
------------------------------------------------------------ ------------------------------------------------------------
-- DataProtocol -- DataProtocol
DataProtocol ::= Protocol DataProtocol ::= Protocol
------------------------------------------------------------ ------------------------------------------------------------
END END
B APPENDIX B -- GSAKMPv1 Base Policy Appendix B. GSAKMPv1 Base Policy
This appendix provides the data structures needed for when GSAKMP This appendix provides the data structures needed for when GSAKMP
exchanges are used as the GroupMngmtProtocol for the registration, exchanges are used as the GroupMngmtProtocol for the registration,
de-registration, and/or rekey SAs. This GSAKMP Base Policy de-registration, and/or Rekey SAs. This GSAKMP Base Policy
specification assumes familiarity with GSAKMP. specification assumes familiarity with GSAKMP.
B.1 GSAKMPv1 Registration Policy B.1. GSAKMPv1 Registration Policy
When GSAKMP is used in the Group Management Protocol for When GSAKMP is used in the Group Management Protocol for
registration, the following object identifier is used in the core registration, the following object identifier is used in the core
token. token.
id-GSAKMPv1RegistrationProtocol OBJECT IDENTIFIER::= {TBD} id-GSAKMPv1RegistrationProtocol
OBJECT IDENTIFIER::= {1.3.6.1.5.5.12.3.1}
The registration policy for GSAKMP provides 1) information on The registration policy for GSAKMP provides 1) information on
authorizations for group roles; 2) access control information for authorizations for group roles, 2) access control information for
group members; 3) the mechanisms used in the registration process, group members, 3) the mechanisms used in the registration process,
and 4) information on what transport the GSAKMP registration exchange and 4) information on what transport the GSAKMP registration exchange
will use. will use.
GSAKMPv1RegistrationInfo ::= SEQUENCE { GSAKMPv1RegistrationInfo ::= SEQUENCE {
joinAuthorization JoinAuthorization, joinAuthorization JoinAuthorization,
joinAccessControl SEQUENCE OF AccessControl, joinAccessControl SEQUENCE OF AccessControl,
joinMechanisms JoinMechanisms, joinMechanisms JoinMechanisms,
transport Transport transport Transport
} }
B.1.1 Authorization B.1.1. Authorization
joinAuthorization provides information on who is allowed to be a joinAuthorization provides information on who is allowed to be a
Group Controller/Key Server (GC/KS) and a sub-GC/KS. It also Group Controller Key Server (GC/KS) and a sub-GC/KS. It also can
can indicate if there are limitations on who can send data in a indicate if there are limitations on who can send data in a
group. group.
JoinAuthorization ::= SEQUENCE { JoinAuthorization ::= SEQUENCE {
gCKS GCKSName, gCKS GCKSName,
subGCKS SEQUENCE OF GCKSName OPTIONAL, subGCKS SEQUENCE OF GCKSName OPTIONAL,
senders SenderAuthorization senders SenderAuthorization
} }
The authorization information is in the form of an access control The authorization information is in the form of an access control
list indicating entity name and acceptable certification authority list indicating entity name and acceptable certification authority
information for the entity's certificate. information for the entity's certificate.
GCKSName ::= SEQUENCE OF UserCAPair GCKSName ::= SEQUENCE OF UserCAPair
UserCAPair ::= SEQUENCE { UserCAPair ::= SEQUENCE {
groupEntity GSAKMPID, groupEntity GSAKMPID,
cA CertAuth cA CertAuth
} }
groupEntity is defined by type and value. The types are indicated groupEntity is defined by type and value. The types are indicated by
by integers that correspond to the GSAKMP Identification types. integers that correspond to the GSAKMP Identification types.
When a portion of a defined name type is filled with an "*", this When a portion of a defined name type is filled with an "*", this
indicates a wildcard, representing any valid choice for a field. indicates a wildcard, representing any valid choice for a field.
This allows the specification of an authorization rule that is a This allows the specification of an authorization rule that is a
set of related names. set of related names.
GSAKMPID ::= SEQUENCE { GSAKMPID ::= SEQUENCE {
typeValue INTEGER, typeValue INTEGER,
typeData OCTET STRING typeData OCTET STRING
} }
The certificate authority is identified by the X.509 [RFC 3280] key The certificate authority is identified by the X.509 [RFC 3280] key
identifier. identifier.
CertAuth ::= KeyIdentifier CertAuth ::= KeyIdentifier
Senders within a group can either be all - indicating no sender Senders within a group either can be all (indicating no sender
restrictions or can be an explicit list of those members authorized restrictions) or can be an explicit list of those members authorized
to send data. to send data.
SenderAuthorization ::= CHOICE { SenderAuthorization ::= CHOICE {
all [0] NULL, all [0] NULL,
limited [1] EXPLICIT SEQUENCE OF UserCAPair limited [1] EXPLICIT SEQUENCE OF UserCAPair
} }
B.1.2 AccessControl B.1.2. AccessControl
joinAccessControl provides information on who is allowed to be a joinAccessControl provides information on who is allowed to be a
Group Member. The access control list is implemented as a set Group Member. The access control list is implemented as a set of
of permissions that the member must satisfy and a list of name permissions that the member must satisfy and a list of name rules
rules and the certificate authority that each must satisfy. and the certificate authority that each must satisfy.
Additionally, a list of exclusions to the list may be provided. Additionally, a list of exclusions to the list may be provided.
AccessControl ::= SEQUENCE { AccessControl ::= SEQUENCE {
permissions [1] EXPLICIT SEQUENCE OF Permission OPTIONAL, permissions [1] EXPLICIT SEQUENCE OF Permission OPTIONAL,
accessRule [2] EXPLICIT SEQUENCE OF UserCAPair, accessRule [2] EXPLICIT SEQUENCE OF UserCAPair,
exclusionsRule [3] EXPLICIT SEQUENCE OF UserCAPair OPTIONAL exclusionsRule [3] EXPLICIT SEQUENCE OF UserCAPair OPTIONAL
} }
The permissions initially available are an abstract set of numeric The permissions initially available are an abstract set of numeric
levels that may be interpreted internal to a community. levels that may be interpreted internal to a community.
skipping to change at page 17, line 38 skipping to change at page 15, line 21
two(2), two(2),
three(3), three(3),
four(4), four(4),
five(5), five(5),
six(6), six(6),
seven(7), seven(7),
eight(8), eight(8),
nine(9) nine(9)
} }
B.1.3 JoinMechanisms B.1.3. JoinMechanisms
Allowable GSAKMP mechanism choices for a particular group are Allowable GSAKMP mechanism choices for a particular group are
specified in joinMechanisms. Any set of JoinMechanism is acceptable specified in joinMechanisms. Any set of JoinMechanism is acceptable
from a policy perspective. from a policy perspective.
JoinMechanisms ::= SEQUENCE OF JoinMechanism JoinMechanisms ::= SEQUENCE OF JoinMechanism
Each set of mechanisms used in the GSAKMP Registration may be Each set of mechanisms used in the GSAKMP Registration may be
specified either as an explicitly defined set or as a pre-defined specified either as an explicitly defined set or as a pre-defined
security suite. security suite.
JoinMechanism ::= CHOICE { JoinMechanism ::= CHOICE {
alaCarte [0] Mechanisms, alaCarte [0] Mechanisms,
suite [1] SecuritySuite suite [1] SecuritySuite
} }
B.1.3.1 alaCarte B.1.3.1. alaCarte
In an explicitly defined -- or alaCarte -- set, a mechanism In an explicitly defined -- or alaCarte -- set, a mechanism is
is defined for the signature, the key exchange algorithm, the defined for the signature, the key exchange algorithm, the key
key wrapping algorithm, the type of acknowledgment data, and wrapping algorithm, the type of acknowledgement data, and
configuration data for the setting of timeouts. configuration data for the setting of timeouts.
Mechanisms ::= SEQUENCE { Mechanisms ::= SEQUENCE {
signatureDef SigDef, signatureDef SigDef,
kEAlg KEAlg, kEAlg KEAlg,
keyWrap KeyWrap, keyWrap KeyWrap,
ackData AckData, ackData AckData,
opInfo OpInfo opInfo OpInfo
} }
The signature definition requires specification of the signature The signature definition requires specification of the signature
algorithm for message signing. The INTEGER that defines the choice algorithm for message signing. The INTEGER that defines the choice
corresponds to the GSAKMP Signature type. corresponds to the GSAKMP Signature type.
SigDef ::= SEQUENCE { SigDef ::= SEQUENCE {
sigAlgorithmID INTEGER, sigAlgorithmID INTEGER,
hashAlgorithmID INTEGER hashAlgorithmID INTEGER
} }
The INTEGER corresponding to hashAlgorithm will map to the GSAKMP The INTEGER corresponding to hashAlgorithm will map to the GSAKMP
skipping to change at page 19, line 29 skipping to change at page 16, line 44
AckData ::= CHOICE { AckData ::= CHOICE {
none [0] NULL none [0] NULL
} }
OpInfo provides configuration data for the operation of GSAKMP OpInfo provides configuration data for the operation of GSAKMP
registration. timeOut indicates the elapsed amount of time registration. timeOut indicates the elapsed amount of time
before a sent message is considered to be misrouted or lost. It before a sent message is considered to be misrouted or lost. It
is specified as the timestamp type LifeDate, previously defined is specified as the timestamp type LifeDate, previously defined
in the core token. terse informs a GC/KS whether the group in the core token. terse informs a GC/KS whether the group
should be operated in terse (TRUE) or verbose (FALSE) mode. 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.
OpInfo ::= SEQUENCE { OpInfo ::= SEQUENCE {
timeOut LifeDate, timeOut LifeDate,
terse BOOLEAN terse BOOLEAN,
timestamp BOOLEAN OPTIONAL
} }
B.1.3.2 suite B.1.3.2. suite
If the choice of mechanism for the join is a predefined security If the choice of mechanism for the join is a predefined security
suite, then it is identified by OBJECT IDENTIFIER (OID). Other suite, then it is identified by OBJECT IDENTIFIER (OID). Other
security suites may be defined elsewhere by specification and security suites may be defined elsewhere by specification and
registration of an OID. registration of an OID.
SecuritySuite ::= OBJECT IDENTIFIER SecuritySuite ::= OBJECT IDENTIFIER
The OID for security suite 1, as defined within the GSAKMPv1 The OID for security suite 1, as defined within the GSAKMPv1
specification is specification, is
id-securitySuiteOne OBJECT IDENTIFIER ::= {TBD} id-securitySuiteOne OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.2.1}
B.1.4 Transport B.1.4. Transport
transport indicates what protocol GSAKMP should ride over. The transport indicates what protocol GSAKMP should ride over. The
choice of udpRTJtcpOther indicates that the GSAKMP Request to choice of udpRTJtcpOther indicates that the GSAKMP Request to
Join message is carried by UDP and all other group establishment Join message is carried by UDP and all other group establishment
messages are carried by TCP. messages are carried by TCP.
Transport ::= CHOICE { Transport ::= CHOICE {
tcp [0] NULL, tcp [0] NULL,
udp [1] NULL, udp [1] NULL,
udpRTJtcpOther [2] NULL udpRTJtcpOther [2] NULL
} }
B.2 GSAKMPv1 Registration ASN.1 Module B.2. GSAKMPv1 Registration ASN.1 Module
GSAKMPv1RegistrationSA -- {TBD} GSAKMPv1RegistrationSA
{1.3.6.1.5.5.12.0.2}
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
EXPORTS EXPORTS
GCKSName; GCKSName;
IMPORTS IMPORTS
LifeDate LifeDate
FROM PolicyToken {TBD} FROM PolicyToken {1.3.6.1.5.5.12.0.1}
KeyIdentifier KeyIdentifier
FROM PKIX1Implicit88 { iso(1) identified-organization(3) FROM PKIX1Implicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit(19) }; id-mod(0) id-pkix1-implicit(19) };
-- id-GSAKMPv1RegistrationProtocol OBJECT IDENTIFIER::= {TBD} id-GSAKMPv1RegistrationProtocol
OBJECT IDENTIFIER::= {1.3.6.1.5.5.12.7}
GSAKMPv1RegistrationInfo ::= SEQUENCE { GSAKMPv1RegistrationInfo ::= SEQUENCE {
joinAuthorization JoinAuthorization, joinAuthorization JoinAuthorization,
joinAccessControl SEQUENCE OF AccessControl, joinAccessControl SEQUENCE OF AccessControl,
joinMechanisms JoinMechanisms, joinMechanisms JoinMechanisms,
transport Transport transport Transport
} }
JoinAuthorization ::= SEQUENCE { JoinAuthorization ::= SEQUENCE {
gCKS GCKSName, gCKS GCKSName,
skipping to change at page 22, line 20 skipping to change at page 19, line 39
signatureDef SigDef, signatureDef SigDef,
kEAlg KEAlg, kEAlg KEAlg,
keyWrap KeyWrap, keyWrap KeyWrap,
ackData AckData, ackData AckData,
opInfo OpInfo opInfo OpInfo
} }
SecuritySuite ::= OBJECT IDENTIFIER SecuritySuite ::= OBJECT IDENTIFIER
-- SECURITY SUITE ONE -- -- SECURITY SUITE ONE --
-- id-securitySuiteOne OBJECT IDENTIFIER ::= {TBD} id-securitySuiteOne OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.2.1}
SigDef ::= SEQUENCE { SigDef ::= SEQUENCE {
sigAlgorithmID INTEGER, sigAlgorithmID INTEGER,
hashAlgorithmID INTEGER hashAlgorithmID INTEGER
} }
KEAlg ::= SEQUENCE { KEAlg ::= SEQUENCE {
keyExchangeAlgorithmID INTEGER, keyExchangeAlgorithmID INTEGER,
keyExchangeAlgorithmData OCTET STRING OPTIONAL keyExchangeAlgorithmData OCTET STRING OPTIONAL
} }
skipping to change at page 22, line 33 skipping to change at page 20, line 4
sigAlgorithmID INTEGER, sigAlgorithmID INTEGER,
hashAlgorithmID INTEGER hashAlgorithmID INTEGER
} }
KEAlg ::= SEQUENCE { KEAlg ::= SEQUENCE {
keyExchangeAlgorithmID INTEGER, keyExchangeAlgorithmID INTEGER,
keyExchangeAlgorithmData OCTET STRING OPTIONAL keyExchangeAlgorithmData OCTET STRING OPTIONAL
} }
KeyWrap ::= INTEGER KeyWrap ::= INTEGER
AckData ::= CHOICE { AckData ::= CHOICE {
none [0] NULL none [0] NULL
} }
OpInfo ::= SEQUENCE { OpInfo ::= SEQUENCE {
timeOut LifeDate, timeOut LifeDate,
terse BOOLEAN terse BOOLEAN,
timestamp BOOLEAN OPTIONAL
} }
Transport ::= CHOICE { Transport ::= CHOICE {
tcp [0] NULL, tcp [0] NULL,
udp [1] NULL, udp [1] NULL,
udpRTJtcpOther [2] NULL udpRTJtcpOther [2] NULL
} }
END END
B.3 GSAKMPv1 De-Registration Policy B.3. GSAKMPv1 De-Registration Policy
GSAKMP De-Registration provides a method to notify a (S-)GC/KS that GSAKMP de-registration provides a method to notify a (S-)GC/KS that a
a member needs to leave a group. When GSAKMP is the De-Registration member needs to leave a group. When GSAKMP is the de-registration
Protocol for the Group, the following object identifier is used in Protocol for the Group, the following object identifier is used in
the core token. the core token.
id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= {TBD} id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::=
{1.3.6.1.5.5.12.3.2}
The De-Registration policy provides the mechanisms needed for the The de-registration policy provides the mechanisms needed for the
De-Registration exchange messages, an indication of whether the de-registration exchange messages, an indication of whether the
exchange is to be done using terse (TRUE) or verbose (FALSE) mode, exchange is to be done using terse (TRUE) or verbose (FALSE) mode,
and the transport used for the GSAKMP De-registration messages. and the transport used for the GSAKMP de-registration messages.
GSAKMPv1DeRegistrationInfo ::= SEQUENCE { GSAKMPv1DeRegistrationInfo ::= SEQUENCE {
leaveMechanisms SEQUENCE OF LeaveMechanisms, leaveMechanisms SEQUENCE OF LeaveMechanisms,
terse BOOLEAN, terse BOOLEAN,
transport Transport transport Transport
} }
The policy dictating the mechanisms needed for the De-registration The policy dictating the mechanisms needed for the de-registration
exchange is defined by leaveMechanisms. This field is specified as exchange is defined by leaveMechanisms. This field is specified as
LeaveMechanisms ::= SEQUENCE { LeaveMechanisms ::= SEQUENCE {
sigAlgorithm INTEGER, sigAlgorithm INTEGER,
hashAlgorithm INTEGER, hashAlgorithm INTEGER,
cA KeyIdentifier cA KeyIdentifier
} }
The INTEGER corresponding to sigAlgorithm will map to the GSAKMP The INTEGER corresponding to sigAlgorithm will map to the GSAKMP
Signature type values. This algorithm set is to be used for message Signature type values. This algorithm set is to be used for message
signing. signing.
The INTEGER corresponding to hashAlgorithm will map to the GSAKMP The INTEGER corresponding to hashAlgorithm will map to the GSAKMP
Nonce Hash type values. This algorithm is used in computing the Nonce Hash type values. This algorithm is used in computing the
combined nonce. combined nonce.
cA represents a trust point off of which the signer's certificate cA represents a trust point off of which the signer's certificate
must certify. It is identified by the PKIX KeyIdentifier [RFC 3280] must certify. It is identified by the Public Key Infrastructure for
type. X.509 Certificates (PKIX) KeyIdentifier [RFC3280] type.
transport will provide the expected transport for GSAKMP transport will provide the expected transport for GSAKMP
De-registration messages. Initially, either UDP or TCP will be the de-registration messages. Initially, either UDP or TCP will be the
policy for a group. policy for a group.
Transport ::= CHOICE { Transport ::= CHOICE {
tcp [0] NULL, tcp [0] NULL,
udp [1] NULL udp [1] NULL
} }
B.4 GSAKMPv1 De-Registration ASN.1 Module B.4. GSAKMPv1 De-Registration ASN.1 Module
GSAKMPv1DeRegistrationSA -- {TBD} GSAKMPv1DeRegistrationSA
{1.3.6.1.5.5.12.0.3}
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
KeyIdentifier KeyIdentifier
FROM PKIX1Implicit88 { iso(1) identified-organization(3) FROM PKIX1Implicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit(19) }; id-mod(0) id-pkix1-implicit(19) };
-- id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= {TBD} id-GSAKMPv1DeRegistrationProtocol
OBJECT IDENTIFIER::= {1.3.6.1.5.5.12.3.2}
GSAKMPv1DeRegistrationInfo ::= SEQUENCE { GSAKMPv1DeRegistrationInfo ::= SEQUENCE {
leaveMechanisms SEQUENCE OF LeaveMechanisms, leaveMechanisms SEQUENCE OF LeaveMechanisms,
transport Transport transport Transport
} }
LeaveMechanisms ::= SEQUENCE { LeaveMechanisms ::= SEQUENCE {
sigAlgorithm INTEGER, sigAlgorithm INTEGER,
hashAlgorithm INTEGER, hashAlgorithm INTEGER,
cA KeyIdentifier cA KeyIdentifier
} }
Transport ::= CHOICE { Transport ::= CHOICE {
tcp [0] NULL, tcp [0] NULL,
udp [1] NULL udp [1] NULL
} }
skipping to change at page 24, line 45 skipping to change at page 22, line 17
cA KeyIdentifier cA KeyIdentifier
} }
Transport ::= CHOICE { Transport ::= CHOICE {
tcp [0] NULL, tcp [0] NULL,
udp [1] NULL udp [1] NULL
} }
END END
B.5 GSAKMPv1 Rekey Policy B.5. GSAKMPv1 Rekey Policy
When GSAKMP is used as the Rekey Protocol for the Group, the When GSAKMP is used as the Rekey Protocol for the Group, the
following object identifier should be used in the core token as the following object identifier should be used in the core token as the
rekey protocol: rekey protocol:
id-GSAKMPv1Rekey OBJECT IDENTIFIER::= {TBD} id-GSAKMPv1Rekey OBJECT IDENTIFIER::= {1.3.6.1.5.5.12.0.4}
The GSAKMP Rekey Policy provides authorization information, The GSAKMP rekey policy provides authorization information,
mechanisms for the GSAKMP Rekey messages, indicators defining rekey mechanisms for the GSAKMP rekey messages, indicators defining rekey
event definitions that define when the GC/KS should send a 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 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 interval that will allow a member to recognize a failure in the rekey
process, a reliability indicator that defines the method 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 will use to increase the likelihood of a rekey delivery (if any), and
finally an indication of how subordinate-GC/KSs will handle rekey. finally an indication of how subordinate-GC/KSes will handle rekey.
This policy also describes the specific Rekey policy methods "None" This policy also describes the specific rekey policy methods "None"
and "GSAKMP LKH REKEY". and "GSAKMP LKH REKEY".
GSAKMPv1RekeyInfo ::= SEQUENCE { GSAKMPv1RekeyInfo ::= SEQUENCE {
authorization RekeyAuthorization, authorization RekeyAuthorization,
mechanism RekeyMechanisms, mechanism RekeyMechanisms,
rekeyEventDef RekeyEventDef, rekeyEventDef RekeyEventDef,
rekeyMethod RekeyMethod, rekeyMethod RekeyMethod,
rekeyInterval LifeDate, rekeyInterval LifeDate,
reliability Reliability, reliability Reliability,
subGCKSInfo SubGCKSInfo subGCKSInfo SubGCKSInfo
} }
B.5.1 Rekey Authorization B.5.1. Rekey Authorization
RekeyAuthorization ::= GCKSName RekeyAuthorization ::= GCKSName
B.5.2 Rekey Mechanisms B.5.2. Rekey Mechanisms
The policy dictating the mechanisms needed for Rekey message The policy dictating the mechanisms needed for rekey message
processing is defined by RekeyMechanisms. This field is specified processing is defined by RekeyMechanisms. This field is specified as
as
RekeyMechanisms ::= SEQUENCE { RekeyMechanisms ::= SEQUENCE {
sigAlgorithm INTEGER, sigAlgorithm INTEGER,
hashAlgorithm INTEGER hashAlgorithm INTEGER
} }
The INTEGER corresponding to sigAlgorithm will map to the GSAKMP The INTEGER corresponding to sigAlgorithm will map to the GSAKMP
Signature type values. This algorithm set is to be used for message Signature type values. This algorithm set is to be used for message
signing. signing.
The INTEGER corresponding to hashAlgorithm will map to the GSAKMP The INTEGER corresponding to hashAlgorithm will map to the GSAKMP
Nonce Hash type values. This algorithm is used in computing the Nonce Hash type values. This algorithm is used in computing the
combined nonce. combined nonce.
B.5.3 Rekey Event Definition B.5.3. Rekey Event Definition
Rekey Event Definition provides information to the GC/KS about Rekey Event Definition provides information to the GC/KS about the
the system requirements for sending rekey messages. This allows system requirements for sending rekey messages. This allows
definition of the rekey event in time as well as event driven definition of the rekey event in time as well as event-driven
characteristics (a number of de-registration notifications as an characteristics (a number of de-registration notifications as an
example), or a combination of the two (e.g., after x de-registrations example), or a combination of the two (e.g., after x de-registrations
or 24 hours, whichever comes first). or 24 hours, whichever comes first).
RekeyEventDef ::= CHOICE { RekeyEventDef ::= CHOICE {
none [0] NULL, -- never rekey none [0] NULL, -- never rekey
timeOnly [1] LifeDate, -- rekey every x units timeOnly [1] LifeDate, -- rekey every x units
event [2] INTEGER, -- rekey after x events event [2] INTEGER, -- rekey after x events
timeAndEvent [3] TimeAndEvent timeAndEvent [3] TimeAndEvent
} }
The LifeDate specifies the maximum time a group should exist between The LifeDate specifies the maximum time a group should exist between
rekeys. This does not require clock synchronization as this is rekeys. This does not require clock synchronization as this is used
used with respect to a local clock. (GC/KS clock for sending rekey with respect to a local clock (a GC/KS clock for sending rekey
messages or member clock for determining whether a message has been messages or a member clock for determining whether a message has been
missed.) missed).
The INTEGER corresponding to the event is an indicator of the number The INTEGER corresponding to the event is an indicator of the number
of events a group should sustain before a rekey message is sent. of events a group should sustain before a rekey message is sent.
This defines the events between rekeys. An example of a relevant This defines the events between rekeys. An example of a relevant
event is de-registration notifications. event is de-registration notifications.
The TimeAndEvent is defined as a couple of the LifeDate and Integer The TimeAndEvent is defined as a couple of the LifeDate and Integer
policies. policies.
TimeAndEvent ::= SEQUENCE { TimeAndEvent ::= SEQUENCE {
time LifeDate, -- rekey after x units of time OR time LifeDate, -- rekey after x units of time OR
event INTEGER -- x events occur event INTEGER -- x events occur
} }
B.5.4 Rekey Methods B.5.4. Rekey Methods
Rekey Method defines the policy of how the rekey is to be The rekey method defines the policy of how the rekey is to be
accomplished. This field is specified as accomplished. This field is specified as
RekeyMethod ::= SEQUENCE { RekeyMethod ::= SEQUENCE {
rekeyMethodType OBJECT IDENTIFIER, rekeyMethodType OBJECT IDENTIFIER,
rekeyMethodInfo OCTET STRING rekeyMethodInfo OCTET STRING
} }
The rekeyMethodType will define the rekey method to be used by the The rekeyMethodType will define the rekey method to be used by the
group. group.
The rekeyMethodInfo will supply the GMs with the information they The rekeyMethodInfo will supply the GMs with the information they
need to operate in the correct rekey mode. need to operate in the correct rekey mode.
B.5.4.1 Rekey Method NONE B.5.4.1. Rekey Method NONE
The group defined to work without a rekey protocols supporting The group defined to work without a rekey protocols supporting it is
it is supported by the rekeyMethodType NONE. There is no supported by the rekeyMethodType NONE. There is no
RekeyMethodNoneInfo associated with this option. RekeyMethodNoneInfo associated with this option.
id-rekeyNone OBJECT IDENTIFIER ::= {TBD} id-rekeyNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.4.1}
RekeyMethodNoneInfo ::= NULL RekeyMethodNoneInfo ::= NULL
B.5.4.2 Rekey Method GSAKMP LKH B.5.4.2. Rekey Method GSAKMP LKH
The GSAKMP protocol specification defined an interpretation of the The GSAKMP protocol specification defined an interpretation of the
Logical Key Hierarchy (LKH) protocol as a rekey method. This method Logical Key Hierarchy (LKH) protocol as a rekey method. This method
is supported by the following values. is supported by the following values.
id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {TBD} id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.4.2}
RekeyMethodGSAKMPLKHInfo ::= INTEGER RekeyMethodGSAKMPLKHInfo ::= INTEGER
The GSAKMP LKH method requires a gsakmp type value for identifying The GSAKMP LKH method requires a gsakmp type value for identifying
the cryptographic algorithm used to wrap the keys. This value maps the cryptographic algorithm used to wrap the keys. This value maps
to the GSAKMP encryption type. to the GSAKMP encryption type.
B.5.5 Rekey Interval B.5.5. Rekey Interval
Rekey interval defines the maximum delay the GM should see Rekey interval defines the maximum delay the GM should see between
between valid rekeys. This provides a means to ensure the GM is valid rekeys. This provides a means to ensure the GM is
synchronized, from a key management perspective, with the rest of the synchronized, from a key management perspective, with the rest of the
group. It is defined as a time/date stamp. group. It is defined as a time/date stamp.
B.5.6 Rekey Reliability B.5.6. Rekey Reliability
The Rekey message in the GSAKMP protocol is a single push message. The rekey message in the GSAKMP protocol is a single push message.
There are reliability concerns with such non-acknowledged messages There are reliability concerns with such non-acknowledged messages
(i.e. message exchange). The Reliability policy defines the (i.e., message exchange). The Reliability policy defines the
mechanism used to deal with these concerns. mechanism used to deal with these concerns.
Reliability ::= SEQUENCE { Reliability ::= SEQUENCE {
reliabilityMechanism OBJECT IDENTIFIER, reliabilityMechanism OBJECT IDENTIFIER,
reliabilityMechContent OCTET STRING reliabilityMechContent OCTET STRING
} }
The reliability mechanism is defined by an OBJECT IDENTIFIER and The reliability mechanism is defined by an OBJECT IDENTIFIER and the
the information needed to operate that mechanism is defined as information needed to operate that mechanism is defined as
reliabilityMechContent and is an OCTET STRING. (as before) reliabilityMechContent and is an OCTET STRING (as before).
B.5.6.1 Rekey Reliability Mechanism None B.5.6.1. Rekey Reliability Mechanism None
In networks with adequate reliability it may not be necessary to use In networks with adequate reliability, it may not be necessary to use
a mechanism to improve reliability of the Rekey Message. For these a mechanism to improve reliability of the rekey message. For these
networks the ReliabilityMechanism NONE is appropriate. networks the ReliabilityMechanism NONE is appropriate.
id-reliabilityNone OBJECT IDENTIFIER ::= {TBD} id-reliabilityNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.1}
ReliabilityContentNone ::= NULL ReliabilityContentNone ::= NULL
B.5.6.2 Rekey Reliability Mechanism Resend B.5.6.2. Rekey Reliability Mechanism Resend
In networks with unknown or questionable reliability it may be In networks with unknown or questionable reliability, it may be
necessary to use a mechanism to improve reliability of the Rekey necessary to use a mechanism to improve reliability of the Rekey
Message. For these networks the ReliabilityMechanism RESEND is Message. For these networks, the ReliabilityMechanism RESEND is
potentially appropriate. This mechanism has the GC/KS repeatedly potentially appropriate. This mechanism has the GC/KS repeatedly
sending out the same message. sending out the same message.
id-reliabilityResend OBJECT IDENTIFIER ::= {TBD} id-reliabilityResend OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.2}
ReliabilityResendInfo ::= INTEGER ReliabilityResendInfo ::= INTEGER
The INTEGER value in the ReliabilityResendInfo indicates the number The INTEGER value in the ReliabilityResendInfo indicates the number
of times the message should be resent. of times the message should be resent.
B.5.6.3 Rekey Reliability Mechanism Post B.5.6.3. Rekey Reliability Mechanism Post
Another reliability mechanism is to post the rekey message on Another reliability mechanism is to post the rekey message on some
some service that will make it generally available. This is the service that will make it generally available. This is the
reliabilityPost method. reliabilityPost method.
id-reliabilityPost OBJECT IDENTIFIER ::= {TBD} id-reliabilityPost OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.3}
ReliabilityContentPost ::= IA5String ReliabilityContentPost ::= IA5String
The IA5String associated with ReliabilityPost is the identifier of The IA5String associated with ReliabilityPost is the identifier of
the posting site and rekey message. the posting site and rekey message.
B.5.7 Distributed Operation Policy B.5.7. Distributed Operation Policy
The policy dictating the relationships between GC/KS and S-GC/KS for The policy dictating the relationships between GC/KS and S-GC/KS for
distributed operations is defined as SubGCKSInfo. It is defined as distributed operations is defined as SubGCKSInfo. It is defined as a
a couple of a subGCKSScheme and some information relating to that couple of a subGCKSScheme and some information relating to that
Scheme in sGCKSContent. Scheme in sGCKSContent.
SubGCKSInfo ::= SEQUENCE { SubGCKSInfo ::= SEQUENCE {
subGCKSScheme OBJECT IDENTIFIER, subGCKSScheme OBJECT IDENTIFIER,
sGCKSContent OCTET STRING sGCKSContent OCTET STRING
} }
B.5.7.1 No Distributed Operation B.5.7.1. No Distributed Operation
If the group is not to use S-GC/KS then that Scheme would be If the group is not to use S-GC/KS, then that Scheme would be
SGCKSSchemeNone. SGCKSSchemeNone.
id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {TBD} id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.1}
SGCKSNoneContent ::= NULL SGCKSNoneContent ::= NULL
B.5.7.2 Autonomous Distributed Mode B.5.7.2. Autonomous Distributed Mode
If the group is to use S-GC/KS as defined in the GSAKMP specification If the group is to use S-GC/KS as defined in the GSAKMP specification
as Autonomous mode, then that scheme would be SGCKSAutonomous. as Autonomous mode, then that scheme would be SGCKSAutonomous.
id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= {TBD} id-subGCKSSchemeAutonomous
OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.2}
SGCKSAutonomous ::= SEQUENCE { SGCKSAutonomous ::= SEQUENCE {
authSubs GCKSName, authSubs GCKSName,
domain OCTET STRING OPTIONAL domain OCTET STRING OPTIONAL
} }
The policy information needed for autonomous mode is a list of The policy information needed for autonomous mode is a list of
authorized S-GC/KSs and and restrictions on who they may serve. authorized S-GC/KSes and restrictions on who they may serve. The
The domain field, representing these restrictions is NULL for this domain field representing these restrictions is NULL for this
version. version.
B.6 GSAKMPv1 Rekey Policy ASN.1 Module B.6. GSAKMPv1 Rekey Policy ASN.1 Module
GSAKMPv1RekeySA -- {TBD} GSAKMPv1RekeySA
{1.3.6.1.5.5.12.0.4}
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
GCKSName GCKSName
FROM GSAKMPv1RegistrationSA {TBD} FROM GSAKMPv1RegistrationSA {1.3.6.1.5.5.12.0.2}
LifeDate LifeDate
FROM PolicyToken {TBD}; FROM PolicyToken {1.3.6.1.5.5.12.0.1};
-- id-GSAKMPv1Rekey OBJECT IDENTIFIER::= {TBD} id-GSAKMPv1Rekey OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.0.4}
GSAKMPv1RekeyInfo ::= SEQUENCE { GSAKMPv1RekeyInfo ::= SEQUENCE {
authorization RekeyAuthorization, authorization RekeyAuthorization,
mechanism RekeyMechanisms, mechanism RekeyMechanisms,
rekeyEventDef RekeyEventDef, -- tells the GCKS when to rekey rekeyEventDef RekeyEventDef, -- tells the GCKS when to rekey
rekeyMethod RekeyMethod, rekeyMethod RekeyMethod,
rekeyInterval LifeDate, -- member knows when to rejoin rekeyInterval LifeDate, -- member knows when to rejoin
reliability Reliability, -- what mech will be used to reliability Reliability, -- what mech will be used to
-- increase the likelihood -- increase the likelihood
-- of rekey delivery -- of rekey delivery
subGCKSInfo SubGCKSInfo -- what subordinate gcks needs subGCKSInfo SubGCKSInfo -- what subordinate GCKS needs
} }
RekeyAuthorization ::= GCKSName RekeyAuthorization ::= GCKSName
RekeyMechanisms ::= SEQUENCE { RekeyMechanisms ::= SEQUENCE {
sigAlgorithm INTEGER, sigAlgorithm INTEGER,
hashAlgorithm INTEGER hashAlgorithm INTEGER
} }
RekeyEventDef ::= CHOICE { RekeyEventDef ::= CHOICE {
skipping to change at page 31, line 35 skipping to change at page 28, line 16
event INTEGER -- x events occur event INTEGER -- x events occur
} }
RekeyMethod ::= SEQUENCE { RekeyMethod ::= SEQUENCE {
rekeyMethodType OBJECT IDENTIFIER, rekeyMethodType OBJECT IDENTIFIER,
rekeyMethodInfo OCTET STRING rekeyMethodInfo OCTET STRING
} }
-- REKEY METHOD NONE -- -- REKEY METHOD NONE --
-- id-rekeyNone OBJECT IDENTIFIER ::= {TBD} id-rekeyNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.4.1}
RekeyMethodNoneInfo ::= NULL RekeyMethodNoneInfo ::= NULL
-- REKEY METHOD GSAKMP LKH -- -- REKEY METHOD GSAKMP LKH --
-- id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {TBD} id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.4.2}
RekeyMethodGSAKMPLKHInfo ::= INTEGER -- gsakmp type value for RekeyMethodGSAKMPLKHInfo ::= INTEGER -- gsakmp type value for
-- wrapping mechanism -- wrapping mechanism
Reliability ::= SEQUENCE { Reliability ::= SEQUENCE {
reliabilityMechanism OBJECT IDENTIFIER, reliabilityMechanism OBJECT IDENTIFIER,
reliabilityMechContent OCTET STRING reliabilityMechContent OCTET STRING
} }
-- RELIABILITY MECHANISM NONE -- -- RELIABILITY MECHANISM NONE --
-- id-reliabilityNone OBJECT IDENTIFIER ::= {TBD} id-reliabilityNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.1}
ReliabilityContentNone ::= NULL ReliabilityContentNone ::= NULL
-- RELIABILITY MECHANISM RESEND -- -- RELIABILITY MECHANISM RESEND --
-- id-reliabilityResend OBJECT IDENTIFIER ::= {TBD} id-reliabilityResend OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.2}
ReliabilityResendInfo ::= INTEGER -- # of times rekey message should ReliabilityResendInfo ::= INTEGER -- # of times rekey message should
-- be resent -- be resent
-- RELIABILITY MECHANISM POST -- -- RELIABILITY MECHANISM POST --
-- id-reliabilityPost OBJECT IDENTIFIER ::= {TBD}
ReliabilityContentPost ::= IA5String id-reliabilityPost OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.3}
ReliabilityContentPost ::= IA5String
SubGCKSInfo ::= SEQUENCE { SubGCKSInfo ::= SEQUENCE {
subGCKSScheme OBJECT IDENTIFIER, subGCKSScheme OBJECT IDENTIFIER,
sGCKSContent OCTET STRING sGCKSContent OCTET STRING
} }
-- id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {TBD} id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.1}
SGCKSNoneContent ::= NULL SGCKSNoneContent ::= NULL
-- id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= {TBD} id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.2}
SGCKSAutonomous ::= SEQUENCE { SGCKSAutonomous ::= SEQUENCE {
authSubs GCKSName, authSubs GCKSName,
domain OCTET STRING OPTIONAL domain OCTET STRING OPTIONAL
} }
END END
C APPENDIX C -- Data SA Policy Appendix C. Data SA Policy
The Data SA provides the data structures needed for the protection The Data SA provides the data structures needed for the protection
of the data exchanged between group members. This appendix defines of the data exchanged between group members. This appendix defines
the data structures needed for a simple, generic security application the data structures needed for a simple, generic security application
making use of fixed security mechanisms. Such a Data SA requires making use of fixed security mechanisms. Such a Data SA requires
only that keys delivered by the registration and rekey protocols be only that keys delivered by the registration and rekey protocols be
mapped to the service using them. mapped to the service using them.
C.1 Generic Data Policy C.1. Generic Data Policy
The Generic Data Policy has the following identifier: The Generic Data Policy has the following identifier:
id-genericDataSA OBJECT IDENTIFIER :: = TBD id-genericDataSA OBJECT IDENTIFIER :: = {1.3.6.1.5.5.12.7.1}
If an authentication mechanism is used within the security If an authentication mechanism is used within the security
application, the key identifier (kMKeyID) used in the key management application, the key identifier (kMKeyID) used in the key management
protocol is given, as well as an optional key expiration date. protocol is given, as well as an optional key expiration date.
Likewise, if an encryption mechanism is used within the security Likewise, if an encryption mechanism is used within the security
application, the encryption key identifier is given, as well as an application, the encryption key identifier is given, as well as an
optional key expiration date (keyExpirationDate). optional key expiration date (keyExpirationDate).
GenericDataSAInfo ::= SEQUENCE { GenericDataSAInfo ::= SEQUENCE {
authentication [0] EXPLICIT KeyInfo OPTIONAL, authentication [0] EXPLICIT KeyInfo OPTIONAL,
encryption [1] EXPLICIT KeyInfo OPTIONAL encryption [1] EXPLICIT KeyInfo OPTIONAL
} }
KeyInfo ::= SEQUENCE{ KeyInfo ::= SEQUENCE{
kMKeyID OCTET STRING, kMKeyID OCTET STRING,
keyExpirationDate LifeDate OPTIONAL keyExpirationDate LifeDate OPTIONAL
} }
C.2 Generic Data Policy ASN.1 Module C.2. Generic Data Policy ASN.1 Module
GenericDataSA -- {TBD} GenericDataSA
{1.3.6.1.5.5.12.0.5}
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- DATA APPLICATION: Generic -- DATA APPLICATION: Generic
-- This token specification is for data applications with -- This token specification is for data applications with
-- fixed security mechanisms. Such data applications only -- fixed security mechanisms. Such data applications only
-- need a mapping of management protocol key identification -- need a mapping of management protocol key identification
-- tags to security service. -- tags to security service.
IMPORTS IMPORTS
LifeDate LifeDate
FROM PolicyToken {TBD} FROM PolicyToken {1.3.6.1.5.5.12.0.1}
KeyIdentifier KeyIdentifier
FROM PKIX1Implicit88 { iso(1) identified-organization(3) FROM PKIX1Implicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit(19) }; id-mod(0) id-pkix1-implicit(19) };
-- id-genericDataSA OBJECT IDENTIFIER ::= {TBD} id-genericDataSA OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.7.1}
GenericDataSAInfo ::= SEQUENCE { GenericDataSAInfo ::= SEQUENCE {
authentication [0] EXPLICIT KeyInfo OPTIONAL, authentication [0] EXPLICIT KeyInfo OPTIONAL,
encryption [1] EXPLICIT KeyInfo OPTIONAL encryption [1] EXPLICIT KeyInfo OPTIONAL
} }
KeyInfo ::= SEQUENCE{ KeyInfo ::= SEQUENCE{
kMKeyID OCTET STRING, kMKeyID OCTET STRING,
keyExpirationDate LifeDate OPTIONAL keyExpirationDate LifeDate OPTIONAL
} }
END 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.
- RFC 3711 policy removed.
- Generic Data SA provided.
- Consistency corrections between text and ASN.1 modules.
- Explicit tagging in sequences of sequences to avoid encoding
ambiguities.
D.4 Changes from Group Policy Token v-03 to v-04, September 2005
- Authorization field for group senders.
- Editorial corrections.
- Renamed to "Group Security Policy Token".
D.5 Changes from Group Policy Token v-04 to v-05, December 2005
- Removed constraints on CMS signing-time attribute.
- Removed unnecessary explicit tags in CHOICE constructs of the
core token.
D.6 Changes from Group Policy Token v-05 to v-06, January 2006
- Added explanation paragraphs to section The Policy Token.
- Added tokenDefVersion field to TokenID structure.
- Added updating/extension rules to the IANA Considerations
section.
Authors' Addresses Authors' Addresses
Andrea Colegrove Andrea Colegrove
SPARTA, Inc. SPARTA, Inc.
7075 Samuel Morse Drive 7110 Samuel Morse Drive
Columbia, MD 21046 Columbia, MD 21046
(410) 872-1515 ext 232
FAX (410) 872-8079 Phone: (443) 430-8014
acc@sparta.com Fax: (443) 430-8163
EMail: acc@sparta.com
Hugh Harney Hugh Harney
SPARTA, Inc. SPARTA, Inc.
7075 Samuel Morse Drive 7110 Samuel Morse Drive
Columbia, MD 21046 Columbia, MD 21046
(410) 872-1515 ext 203
FAX (410) 872-8079 Phone: (443) 430-8032
hh@sparta.com Fax: (443) 430-8181
EMail: hh@sparta.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The Internet Society (2006).
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 This document is subject to the rights, licenses and restrictions
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE contained in BCP 78, and except as set forth therein, the authors
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE retain all their rights.
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.
IPR Considerations 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.
By submitting this Internet-Draft, each author represents that any Intellectual Property
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the attempt made to obtain a general license or permission for the use of
use of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
Document expiration: July 23, 2006 Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 203 change blocks. 
433 lines changed or deleted 373 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/