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

This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/