Request for Comments: 4534 H. Harney
Category: Standards Track SPARTA, Inc.
June 2006
Group Security Policy Token v1
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Group Security Policy Token is a structure used to specify the
security policy and configurable parameters for a cryptographic
group, such as a secure multicast group. Because the security of a
group is composed of the totality of multiple security services,
mechanisms, and attributes throughout the communications
infrastructure, an authenticatable representation of the features
that must be supported throughout the system is needed to ensure
consistent security. This document specifies the structure of such a
token.
Table of Contents
1. Introduction ....................................................3
2. Token Creation and Receipt ......................................4
3. The Policy Token ................................................5
3.1. Token Identifiers ..........................................6
3.2. Registration Policy ........................................6
3.3. Rekey Policy ...............................................7
3.4. Group Data Policy ..........................................8
4. Security Considerations .........................................8
5. IANA Considerations .............................................8
6. References.......................................................9
6.1. Normative References .......................................9
6.2. Informative References ....................................10
7. Acknowledgements ...............................................10
Appendix A. Core Policy Token ASN.1 Module ........................11
Appendix B. GSAKMPv1 Base Policy ..................................13
B.1. GSAKMPv1 Registration Policy ..............................13
B.1.1. Authorization .......................................13
B.1.2. AccessControl .......................................14
B.1.3. JoinMechanisms ......................................15
B.1.3.1. alaCarte ...................................15
B.1.3.2. suite ......................................17
B.1.4. Transport ...........................................17
B.2. GSAKMPv1 Registration ASN.1 Module ........................17
B.3. GSAKMPv1 De-Registration Policy ...........................20
B.4. GSAKMPv1 De-Registration ASN.1 Module .....................21
B.5. GSAKMPv1 Rekey Policy .....................................22
B.5.1. Rekey Authorization ................................22
B.5.2. Rekey Mechanisms ...................................23
B.5.3. Rekey Event Definition .............................23
B.5.4. Rekey Methods ......................................24
B.5.4.1 Rekey Method NONE ..........................24
B.5.4.2 Rekey Method GSAKMP LKH ....................24
B.5.5 Rekey Interval ......................................25
B.5.6 Rekey Reliability ...................................25
B.5.6.1 Rekey Reliability Mechanism None ............25
B.5.6.2 Rekey Reliability Mechanism Resend ..........25
B.5.6.3 Rekey Reliability Mechanism Post ............26
B.5.7 Distributed Operation Policy ........................26
B.5.7.1 No Distributed Operation ....................26
B.5.7.2 Autonomous Distributed Mode .................26
B.6. GSAKMPv1 Rekey Policy ASN.1 Module ........................27
Appendix C. Data SA Policy ........................................30
C.1. Generic Data Policy .......................................30
C.2. Generic Data Policy ASN.1 Module ..........................30
1. Introduction
The Multicast Group Security Architecture [RFC3740] defines the
security infrastructure to support secure group communications. The
policy token assumes this architecture in its definition. It defines
the enforceable security parameters for a Group Secure Association.
The policy token is a verifiable data construct signed by the Group
Owner, the entity with the authorization to create security policy.
The group controllers in a group will use the policy token to ensure
that the mechanisms used to secure the group are correct and to
enforce the access control rules for joining members. The group
members, who may contribute data to the group or access data from the
group, will use the policy token to ensure that the group is owned by
a trusted authority. Also, the members may want to verify that the
access control rules are adequate to protect the data that the member
is submitting to the group.
The policy token is specified in ASN.1 [X.208] and is to be DER
[X.660] encoded. This specification ability allows the token to
easily import group definitions that span different applications and
environments. ASN.1 allows the token to specify branches that can be
used by any multicast security protocol. Any group can use this
policy token structure to specify the use of multiple protocols in
securing the group.
Care was taken in this specification to provide a core level of token
specificity that would allow ease of extensibility and flexibility in
supporting mechanisms. This was done by using the following
abstracted construct:
Mechanism ::= SEQUENCE {
mechanismIdentifier OBJECT IDENTIFIER,
mechanismParameters OCTET STRING
}
This construct will allow the use of group mechanisms specified in
other documents with the policy token.
The policy token is structured to reflect the MSEC Architecture
layers for a Group Security Association. Each of the architectural
layers is identified and given a branch in the "Core" token. This
allows a high degree of flexibility for future protocol
specifications at each architectural layer without the need to change
the "Core" policy token, which can then act as a single point of
reference for defining secure groups using any mix of protocols for
any number of environments.
2. Token Creation and Receipt
At the time of group creation or whenever the policy of the group is
updated, the Group Owner will create a new policy token.
To ensure authenticity of the specified policy, the Token MUST be
signed by the Group Owner. The signed token MUST be in accordance
with the Cryptographic Message Syntax (CMS) [RFC3852] SignedData
type.
The content of the SignedData is the token itself. It is represented
with the ContentType object identifier of
id-ct-msec-token OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.1.1}
The CMS sid value of the SignerInfo, which identifies the public key
needed to validate the signature, MUST be that of the Group Owner.
The signedAttrs field MUST be present. In addition to the minimally
required fields of signedAttrs, the signing-time attribute MUST be
present.
Upon receipt of a policy token, the recipient MUST check that
- the Group Owner, as identified by the sid in the SignerInfo, is
the expected entity.
- the signing-time value is more recent than the signing-time value
seen in a previously received policy token for that group, or the
policy token is the first token seen by the recipient for that
group.
- the processing of the signature successfully validates in
accordance with RFC 3852.
- the specified security and communication mechanisms (or at least
one mechanism of each choice) are supported and are in compliance
with the recipient’s local policy.
3. The Policy Token
The structure of the policy token is as follows:
Token ::= SEQUENCE {
tokenInfo TokenID,
registration SEQUENCE OF Registration,
rekey SEQUENCE OF GroupMngmtProtocol,
data SEQUENCE OF DataProtocol
}
tokenInfo provides information about the instance of the Policy Token
(PT).
registration provides a list of acceptable registration and
de-registration policy and mechanisms that may be used to manage
member-initiated joins and departures from a group. A NULL
sequence indicates that the group does not support registration
and de-registration of members. A member MUST be able to support
at least one set of Registration mechanisms in order to join the
group. When multiple mechanisms are present, a member MAY use
any of the listed methods. The list is ordered in terms of Group
Owner preference. A member MUST choose the highest listed
mechanism that local policy supports.
rekey provides the rekey protocols that will be used in managing the
group. The member MUST be able to accept one of the types of
rekey messages listed. The list is ordered in terms of Group
Owner preference. A member MUST choose the highest listed
mechanism that local policy supports.
data provides the applications used in the communications between
group members. When multiple applications are provided, the
order of the list implies the order of encapsulation of the data.
A member MUST be able to support all the listed applications and
if any choices of mechanisms are provided per application, the
member MUST support at least one of the mechanisms.
For the registration, rekey, and data fields, implementations
encountering unknown protocol identifiers MUST handle this gracefully
by providing indicators that an unknown protocol is among the
sequence of permissible protocols. If the unknown protocol is the
only allowable protocol in the sequence, then the implementation
cannot support that field, and the member cannot join the group. It
is a matter of local policy whether a join is permitted when an
unknown protocol exists among the allowable, known protocols.
Protocols in addition to registration, rekey, and data SHOULD NOT be
added to subsequent versions of this Token unless the MSEC
architecture changes.
Each data field of the PT is specified further in the following
sections.
3.1. Token Identifiers
tokenInfo explicitly identifies a version of the policy token for a
particular group. It is defined as
TokenID ::= SEQUENCE {
tokenDefVersion INTEGER (1),
groupName OCTET STRING,
edition INTEGER OPTIONAL
}
tokenDefVersion is the version of the Group Policy Token
Specification. This specification (v1) is represented as one
(1). Changes to the structure of the Group Security Policy Token
will require an update to this field.
groupName is the identifier of the group and MUST be unique relative
to the Group Owner.
edition is an optional INTEGER indicating the sequence number of the
PT. If edition is present, group entities MUST accept a PT only
when the value is greater than the last value seen in a valid PT
for that group.
The type LifeDate is also defined to provide standard methods of
indicating timestamps and intervals in the Tokens.
LifeDate ::= CHOICE {
gt GeneralizedTime,
utc UTCTime,
interval INTEGER
}
3.2. Registration Policy
The registration security association (SA) is defined in the MSEC
Architecture. During registration, a prospective group member and
the group controller will interact to give the group member access to
the keys and information it needs to join the group and participate
in the group Data SA.
The de-registration piece allows a current group member to notify the
Group Controller Key Server (GC/KS) that it will no longer be
participating in the Data SA.
Registration ::= SEQUENCE {
register GroupMngmtProtocol,
de-register GroupMngmtProtocol
}
The protocols for registration and de-registration are each specified
as
GroupMngmtProtocol ::= CHOICE {
none NULL,
supported Protocol
}
Protocol ::= SEQUENCE {
protocol OBJECT IDENTIFIER,
protocolInfo OCTET STRING
}
For example, register might be specified as the Group Secure
Association Key Management Protocol (GSAKMP) [RFC4535] registration
protocol. The OBJECT IDENTIFIER TBS would be followed by the
parameters used in GSAKMP registration as specified in Appendix B.1.
3.3. Rekey Policy
The Rekey SA is defined in the MSEC Architecture. During the Rekey
of a group, several changes can potentially be made:
- refresh/change group protection keys,
- update the policy token,
- change the group membership.
During Rekey, the membership of the group can be modified as well as
refreshing the group traffic protection keys and updating the Policy
Token.
This field is also specified as a sequence of protocols that will be
used by the GC/KS.
3.4. Group Data Policy
The Data SA is the ultimate consumer of the group keys. The data
field will indicate the keys and mechanisms that are to be used in
communications between group members. There are several protocols
that could make use of group keys, ranging from simple security
applications that only need key for encryption and/or integrity
protection to more complex configurable security protocols such as
IPsec and Secure Real-time Transport Protocol (SRTP) [RFC3711]. The
sequencing of the Data SA mechanisms are from "inside" to "outside".
That is, the first Data SA defined in a policy token must act on the
raw data. Any Data SA specified after that will be applied in turn.
DataProtocol ::= Protocol
4. Security Considerations
This document specifies the structure for a group policy token. As
such, the structure as received by a group entity must be verifiably
authentic. This policy token uses CMS to apply authentication
through digital signatures. The security of this scheme relies upon
a secure CMS implementation, choice of signature mechanism of
appropriate strength for the group using the policy token, and
secure, sufficiently strong keys. Additionally, it relies upon
knowledge of a well-known Group Owner as the root of policy
enforcement.
Furthermore, while the Group Owner may list alternate mechanisms for
various functions, the group is only as strong as the weakest
accepted mechanisms. As such, the Group Owner is responsible for
providing only acceptable security mechanisms.
5. IANA Considerations
The following object identifiers have been assigned:
- id-ct-msec-token OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.1.1
- id-securitySuiteOne OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.2.1
- id-GSAKMPv1RegistrationProtocol
OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.1
- id-GSAKMPv1DeRegistrationProtocol
OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.2
- id-GSAKMPv1Rekey OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.3
- id-rekeyNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.4.1
- id-rekeyMethodGSAKMPLKH
OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.4.2
- id-reliabilityNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.1
- id-reliabilityResend OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.2
- id-reliabilityPost OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.3
- id-subGCKSSchemeNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.6.1
- id-subGCKSSchemeAutonomous
OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.6.2
- id-genericDataSA OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.7.1
The Group Security Policy Token can be extended through
specification. Extensions in the form of objects can be registered
through IANA. Extensions requiring changes to the protocol structure
will require an update to the tokenDefVersion field of the TokenID
(see Section 3.1).
6. References
6.1. Normative References
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
Group Secure Association Key Management Protocol", RFC
4535, June 2006.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[X.208] Recommendation X.208, Specification of Abstract Syntax
Notation One (ASN.1), 1988.
[X.660] Recommendation X.660, Information Technology ASN.1 Encoding
Rules: Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER), and Distinguished Encoding
Rules (DER), 1997.
6.2. Informative References
[HCLM00] Harney, H., Colegrove, A., Lough, P., and U. Meth, "GSAKMP
Token Specification", Work in Progress, February 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[HCM01] H. Harney, A. Colegrove, P. McDaniel, "Principles of Policy
in Secure Groups", Proceedings of Network and Distributed
Systems Security 2001 Internet Society, San Diego, CA,
February 2001.
[HHMCD01] Hardjono, T., Harney, H., McDaniel, P., Colegrove, A., and
P. Dinsmore, "Group Security Policy Token: Definition and
Payloads", Work in Progress, August 2003.
7. Acknowledgements
The following individuals deserve recognition and thanks for their
contributions, which have greatly improved this specification: Uri
Meth, whose knowledge of GSAKMP and tokens was greatly appreciated as
well as his help in getting this document submitted; Peter Lough,
Thomas Hardjono, Patrick McDaniel, and Pete Dinsmore for their work
on earlier versions of policy tokens; George Gross for the impetus to
have a well-specified, extensible policy token; and Rod Fleischer for
catching implementation issues.
The following technical works influenced the design of the Group
Security Policy Token: [HCLM00], [HCM01], and [HHMCD01]
Appendix A. Core Policy Token ASN.1 Module
PolicyToken
{1.3.6.1.5.5.12.0.1}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
Token ::= SEQUENCE {
tokenInfo TokenID,
registration SEQUENCE OF Registration,
rekey SEQUENCE OF GroupMngmtProtocol,
data SEQUENCE OF DataProtocol
}
------------------------------------------------------------
-- Token ID
TokenID ::= SEQUENCE {
tokenDefVersion INTEGER (1), -- Group Security Policy Token v1
groupName OCTET STRING,
edition INTEGER OPTIONAL
}
LifeDate ::= CHOICE {
gt GeneralizedTime,
utc UTCTime,
interval INTEGER
}
------------------------------------------------------------
-- Registration
Registration ::= SEQUENCE {
register GroupMngmtProtocol,
de-register GroupMngmtProtocol
}
------------------------------------------------------------
-- GroupMngmtProtocol
GroupMngmtProtocol ::= CHOICE {
none NULL,
supported Protocol
}
Protocol ::= SEQUENCE {
protocol OBJECT IDENTIFIER,
protocolInfo OCTET STRING
}
------------------------------------------------------------
-- DataProtocol
DataProtocol ::= Protocol
------------------------------------------------------------
END
Appendix B. GSAKMPv1 Base Policy
This appendix provides the data structures needed for when GSAKMP
exchanges are used as the GroupMngmtProtocol for the registration,
de-registration, and/or Rekey SAs. This GSAKMP Base Policy
specification assumes familiarity with GSAKMP.
B.1. GSAKMPv1 Registration Policy
When GSAKMP is used in the Group Management Protocol for
registration, the following object identifier is used in the core
token.
id-GSAKMPv1RegistrationProtocol
OBJECT IDENTIFIER::= {1.3.6.1.5.5.12.3.1}
The registration policy for GSAKMP provides 1) information on
authorizations for group roles, 2) access control information for
group members, 3) the mechanisms used in the registration process,
and 4) information on what transport the GSAKMP registration exchange
will use.
GSAKMPv1RegistrationInfo ::= SEQUENCE {
joinAuthorization JoinAuthorization,
joinAccessControl SEQUENCE OF AccessControl,
joinMechanisms JoinMechanisms,
transport Transport
}
B.1.1. Authorization
joinAuthorization provides information on who is allowed to be a
Group Controller Key Server (GC/KS) and a sub-GC/KS. It also can
indicate if there are limitations on who can send data in a
group.
JoinAuthorization ::= SEQUENCE {
gCKS GCKSName,
subGCKS SEQUENCE OF GCKSName OPTIONAL,
senders SenderAuthorization
}
The authorization information is in the form of an access control
list indicating entity name and acceptable certification authority
information for the entity’s certificate.
GCKSName ::= SEQUENCE OF UserCAPair
UserCAPair ::= SEQUENCE {
groupEntity GSAKMPID,
cA CertAuth
}
groupEntity is defined by type and value. The types are indicated by
integers that correspond to the GSAKMP Identification types.
When a portion of a defined name type is filled with an "*", this
indicates a wildcard, representing any valid choice for a field.
This allows the specification of an authorization rule that is a
set of related names.
GSAKMPID ::= SEQUENCE {
typeValue INTEGER,
typeData OCTET STRING
}
The certificate authority is identified by the X.509 [RFC3280] key
identifier.
CertAuth ::= KeyIdentifier
Senders within a group either can be all (indicating no sender
restrictions) or can be an explicit list of those members authorized
to send data.
SenderAuthorization ::= CHOICE {
all [0] NULL,
limited [1] EXPLICIT SEQUENCE OF UserCAPair
}
B.1.2. AccessControl
joinAccessControl provides information on who is allowed to be a
Group Member. The access control list is implemented as a set of
permissions that the member must satisfy and a list of name rules