draft-ietf-msec-policy-token-sec-05.txt   draft-ietf-msec-policy-token-sec-06.txt 
Internet Engineering Task Force Internet Engineering Task Force
INTERNET-DRAFT A Colegrove INTERNET-DRAFT A Colegrove
H Harney H Harney
draft-ietf-msec-policy-token-sec-05.txt SPARTA, Inc. draft-ietf-msec-policy-token-sec-06.txt SPARTA, Inc.
Expires: June 16, 2006 December 2005 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 By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 3, line 11 skipping to change at page 3, line 11
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 consistent security. This document specifies the structure
of such a token. of such a token.
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 Token Identifiers . . . . . . . . . . . . . . . . . . . . . 7 3.1 Token Identifiers . . . . . . . . . . . . . . . . . . . . . 8
3.2 Registration Policy . . . . . . . . . . . . . . . . . . . . 8 3.2 Registration Policy . . . . . . . . . . . . . . . . . . . . 8
3.3 Rekey Policy . . . . . . . . . . . . . . . . . . . . . . . 9 3.3 Rekey Policy . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Group Data Policy . . . . . . . . . . . . . . . . . . . . . 9 3.4 Group Data Policy . . . . . . . . . . . . . . . . . . . . . 10
4 Security Considerations 10 4 Security Considerations 10
5 IANA Considerations 10 5 IANA Considerations 10
6 References 11 6 References 11
6.1 Normative References . . . . . . . . . . . . . . . . . . . 11 6.1 Normative References . . . . . . . . . . . . . . . . . . . 11
6.2 Non-Normative References . . . . . . . . . . . . . . . . . 11 6.2 Non-Normative References . . . . . . . . . . . . . . . . . 12
7 Acknowledgments 12 7 Acknowledgments 12
A APPENDIX A -- Core Policy Token ASN.1 Module 13 A APPENDIX A -- Core Policy Token ASN.1 Module 13
B APPENDIX B -- GSAKMPv1 Base Policy 15 B APPENDIX B -- GSAKMPv1 Base Policy 15
B.1 GSAKMPv1 Registration Policy . . . . . . . . . . . . . . . 15 B.1 GSAKMPv1 Registration Policy . . . . . . . . . . . . . . . 15
B.1.1 Authorization . . . . . . . . . . . . . . . . . . . . . 15 B.1.1 Authorization . . . . . . . . . . . . . . . . . . . . . 15
B.1.2 AccessControl . . . . . . . . . . . . . . . . . . . . . 17 B.1.2 AccessControl . . . . . . . . . . . . . . . . . . . . . 17
B.1.3 JoinMechanisms . . . . . . . . . . . . . . . . . . . . 17 B.1.3 JoinMechanisms . . . . . . . . . . . . . . . . . . . . 17
B.1.3.1 alaCarte . . . . . . . . . . . . . . . . . . . . 18 B.1.3.1 alaCarte . . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 4, line 11 skipping to change at page 4, line 11
C APPENDIX C -- Data SA Policy 33 C APPENDIX C -- Data SA Policy 33
C.1 Generic Data Policy . . . . . . . . . . . . . . . . . . . . 33 C.1 Generic Data Policy . . . . . . . . . . . . . . . . . . . . 33
C.2 Generic Data Policy ASN.1 Module . . . . . . . . . . . . . 34 C.2 Generic Data Policy ASN.1 Module . . . . . . . . . . . . . 34
D APPENDIX D -- Change History (To Be Removed from RFC) 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.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.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.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.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.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 36 Authors Addresses 37
Full Copyright Statement 36 Full Copyright Statement 37
IPR Considerations 36 IPR Considerations 37
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.
skipping to change at page 7, line 39 skipping to change at page 7, line 39
Group Owner preference. A member MUST choose the highest listed Group 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
encountering unknown protocol identifiers MUST handle this gracefully
by providing indicators that an unknown protocol is among the
sequence of permissible protocols. If the unknown protocol is the
only allowable protocol in the sequence, then the implementation
cannot support that field, and the member cannot join the group.
It is a matter of local policy whether a join is permitted when an
unknown protocol exists among the allowable, known protocols.
Protocols in addition to registration, rekey, and data SHOULD NOT
be added to subsequent versions of this Token unless the MSEC
architecture changes.
Each data field of the PT is specified further in the following 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),
groupName OCTET STRING, groupName OCTET STRING,
edition INTEGER OPTIONAL edition INTEGER OPTIONAL
} }
tokenDefVersion is the version of the Group Policy Token
Specification. This specifications (v1) is represented as one
(1). Changes to the structure of the Group Security Policy Token
will require an update to this field.
groupName is the identifier of the group and MUST be unique relative 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.
skipping to change at page 10, line 37 skipping to change at page 11, line 4
The following object identifiers should be assigned: The following object identifiers should be assigned:
- id-ct-msec-token OBJECT IDENTIFIER ::= TBD - id-ct-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
- id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= TBD - id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= TBD
- id-GSAKMPv1Rekey OBJECT IDENTIFIER::= TBD - id-GSAKMPv1Rekey OBJECT IDENTIFIER::= TBD
- id-rekeyNone OBJECT IDENTIFIER ::= TBD - id-rekeyNone OBJECT IDENTIFIER ::= TBD
- id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= TBD - id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= TBD
- id-reliabilityNone OBJECT IDENTIFIER ::= TBD - id-reliabilityNone OBJECT IDENTIFIER ::= TBD
- id-reliabilityResend OBJECT IDENTIFIER ::= TBD - id-reliabilityResend OBJECT IDENTIFIER ::= TBD
- 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
The Group Security Policy Token can be extended through
specification. Extensions in the form of objects can be registered
through IANA. Extensions requiring changes to the protocol structure
will require an update to the tokenDefVersion field of the TokenID
(see section 3.1).
6 References 6 References
The following references were used in the preparation of this The following references were used in the preparation of this
document. document.
6.1 Normative References 6.1 Normative References
[HMCG] H. Harney, U. Meth, A. Colegrove, and G. Gross, "GSAKMP", [HMCG] H. Harney, U. Meth, A. Colegrove, and G. Gross, "GSAKMP",
draft-ietf-msec-gsakmp-sec-10.txt, RFC Editor Queue, May 2005. draft-ietf-msec-gsakmp-sec-10.txt, RFC Editor Queue, May 2005.
skipping to change at page 13, line 12 skipping to change at page 13, line 12
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 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
TokenID ::= SEQUENCE { TokenID ::= SEQUENCE {
tokenDefVersion INTEGER (1), -- Group Security Policy Token v1
groupName OCTET STRING, groupName OCTET STRING,
edition INTEGER OPTIONAL edition INTEGER OPTIONAL
} }
LifeDate ::= CHOICE { LifeDate ::= CHOICE {
gt GeneralizedTime, gt GeneralizedTime,
utc UTCTime, utc UTCTime,
interval INTEGER interval INTEGER
} }
skipping to change at page 36, line 5 skipping to change at page 35, line 39
- Renamed to "Group Security Policy Token". - Renamed to "Group Security Policy Token".
D.5 Changes from Group Policy Token v-04 to v-05, December 2005 D.5 Changes from Group Policy Token v-04 to v-05, December 2005
- Removed constraints on CMS signing-time attribute. - Removed constraints on CMS signing-time attribute.
- Removed unnecessary explicit tags in CHOICE constructs of the - Removed unnecessary explicit tags in CHOICE constructs of the
core token. 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 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 Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set 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 This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
skipping to change at page 37, line 18 skipping to change at page 38, line 18
use of such proprietary rights by implementers or users of this use of 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 http://www.ietf.org/ipr. at 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 ietf-
ipr@ietf.org. ipr@ietf.org.
Document expiration: June 16, 2006 Document expiration: July 23, 2006
 End of changes. 19 change blocks. 
12 lines changed or deleted 47 lines changed or added

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