One document matched: draft-ietf-msec-policy-token-sec-03.txt
Differences from draft-ietf-msec-policy-token-sec-02.txt
Internet Engineering Task Force
INTERNET-DRAFT A Colegrove (SPARTA)
H Harney (SPARTA)
draft-ietf-msec-policy-token-sec-03.txt SPARTA, Inc.
Expires: January 7, 2006 July 2005
Group Policy Token v1:
Group Policy Token V1 with Application to GSAKMP
Status of this memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note
that other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
The Policy Token is a structure used to specify the
security policy and configurable parameters for a
cryptographic group, such as a secure multicast group. This
document specifies the structure of such a token in order to
securely bind system-level security to protocols supporting
the management of cryptographic groups.
INTERNET-DRAFT Group Polcy Token v1 July 2005
Copyright Notice Copyright (c) The Internet Society (2005). All
Rights Reserved.
Colegrove and Harney [Page 2]
INTERNET-DRAFT Group Polcy Token v1 July 2005
Contents
1 Introduction 5
2 Token Creation and Receipt 6
3 The Policy Token 6
3.1 tokenInfo . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 registration . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 rekey . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 data . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Security Considerations 9
5 IANA Considerations 10
6 References 11
6.1 Normative References . . . . . . . . . . . . . . . . . . . 11
6.2 Non-Normative References . . . . . . . . . . . . . . . . . 11
7 Acknowledgements 11
A APPENDIX A -- Core Policy Token ASN.1 Module 13
B APPENDIX B -- GSAKMPv1 Base Policy 15
B.1 GSAKMPv1 Registration Policy . . . . . . . . . . . . . . . 15
B.1.1 Authorization . . . . . . . . . . . . . . . . . . . . . 15
B.1.2 AccessControl . . . . . . . . . . . . . . . . . . . . . 16
B.1.3 JoinMechanisms . . . . . . . . . . . . . . . . . . . . 17
B.1.4 Transport . . . . . . . . . . . . . . . . . . . . . . . 19
B.2 GSAKMPv1 Registration ASN.1 Module . . . . . . . . . . . . 19
B.3 GSAKMPv1 De-Registration Policy . . . . . . . . . . . . . . 22
B.4 GSAKMPv1 De-Registration ASN.1 Module . . . . . . . . . . . 23
B.5 GSAKMPv1 Rekey Policy . . . . . . . . . . . . . . . . . . . 24
B.5.1 Rekey Authorization . . . . . . . . . . . . . . . . . . 24
B.5.2 Rekey Mechanisms . . . . . . . . . . . . . . . . . . . 25
B.5.3 Rekey Event Definition . . . . . . . . . . . . . . . . 25
B.5.4 Rekey Methods . . . . . . . . . . . . . . . . . . . . . 26
B.5.4.1 Rekey Method NONE . . . . . . . . . . . . . . . . 26
B.5.4.2 Rekey Method GSAKMP LKH . . . . . . . . . . . . . 26
B.5.5 Rekey Interval . . . . . . . . . . . . . . . . . . . . 27
B.5.6 Rekey Reliability . . . . . . . . . . . . . . . . . . . 27
B.5.6.1 Rekey Reliability Mechanism None . . . . . . . . 27
B.5.6.2 Rekey Reliability Mechanism Resend . . . . . . . 28
B.5.6.3 Rekey Reliability Mechanism Post . . . . . . . . 28
B.5.7 Distributed Operation Policy . . . . . . . . . . . . . 28
B.5.7.1 No Distributed Operation . . . . . . . . . . . . 29
B.5.7.2 Autonomous Distributed Mode . . . . . . . . . . . 29
B.6 GSAKMPv1 Rekey Policy ASN.1 Module . . . . . . . . . . . . 29
C APPENDIX C -- Data SA Policy 31
C.1 Generic Data Policy . . . . . . . . . . . . . . . . . . . . 32
C.2 Generic Data Policy ASN.1 Module . . . . . . . . . . . . . 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 33
Colegrove and Harney [Page 3]
INTERNET-DRAFT Group Polcy Token v1 July 2005
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 35
Full Copyright Statement 35
IPR Considerations 35
Colegrove and Harney [Page 4]
INTERNET-DRAFT Group Polcy Token v1 July 2005
1 Introduction
The Multicast Group Security Architecture [HW05] 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 member is
submitting to the group.
The policy token is specified in ASN.1 and is to be DER encoded.
This specification ability allows the token to easily import group
definitions that span different applications and environments.
ASN.1 allows the token to specify branches that can be used by any
multicast security protocol. Any group can use this policy token
structure to specify the use of multiple protocols in securing the
group.
Care was taken in this specification to provide a core level of token
specificity that would allow ease of extensibility and flexibility
in supporting mechanisms. This was done by using the following
abstracted construct:
Mechanism ::= SEQUENCE {
mechanismIdentifier OBJECT IDENTIFIER,
mechanismParameters OCTET STRING
}
This construct will allow the use of group mechanisms specified in
other documents with the Policy Token.
The Policy Token is structured to reflect the MSEC Architecture
layers for a Group Security Association. Each of the architectural
layers is identified and given a branch in the "Core" token.
This allows a high degree of flexibility for future protocol
specifications at each architectural layer without the need to change
the "Core" policy token, which can then act as a single point of
reference for defining secure groups using any mix of protocols for
any number of environments.
Colegrove and Harney [Page 5]
INTERNET-DRAFT Group Polcy Token v1 July 2005
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 CMS [RFC 3852] SignedData type.
The content of the SignedData is the token itself. It is represented
with the ContentType object identifier of
id-msec-token OBJECT IDENTIFIER ::= {TBD}
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
required fields of signedAttrs, the signing-time attribute MUST be
PRESENT and MUST be specified as a GeneralizedTime value.
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 succeeds 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:
Colegrove and Harney [Page 6]
INTERNET-DRAFT Group Polcy Token v1 July 2005
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
deregistration 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 deregistration of members. A member MUST be able to support
at least one set of Registration mechansims 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 SHOULD 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 SHOULD 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.
Each data field of the PT is specified further in the following
sections.
3.1 tokenInfo
tokenInfo explicitly identifies a version of the Policy Token for a
particular group. It is defined as
Colegrove and Harney [Page 7]
INTERNET-DRAFT Group Polcy Token v1 July 2005
TokenID ::= SEQUENCE {
groupName OCTET STRING,
edition INTEGER OPTIONAL
}
groupName is the identifier of the group
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 [0] GeneralizedTime,
utc [1] UTCTime,
interval [2] INTEGER,
}
3.2 registration
The registration 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 and participate in the group data SA.
The deregistration piece allows a current group member to notify the
GC/KS that it will no longer be participating in the data layer SA.
Registration ::= SEQUENCE {
register GroupMngmtProtocol,
de-register GroupMngmtProtocol
}
The protocol for registration and de-registration are each specified
as
Colegrove and Harney [Page 8]
INTERNET-DRAFT Group Polcy Token v1 July 2005
GroupMngmtProtocol ::= CHOICE {
none [0] NULL,
supported [1] Protocol
}
Protocol ::= SEQUENCE {
protocol OBJECT IDENTIFIER,
protocolInfo OCTET STRING
}
For example, register might be specified as the GSAKMP [HMCG]
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
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 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 data
The Data SA is the ultimate consumer of the group keys. The data
field will indicate the keys and mechanisms that are to be used in
communications between group members. There are several protocols
that could make use of multicast key, ranging from simple security
applications needing key only to more complex configurable security
protocols such as IPSec and SRTP. 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
The document specifies the structure for a Group Policy Token. As
such, the structure as received by a group entity must be verifiably
Colegrove and Harney [Page 9]
INTERNET-DRAFT Group Polcy Token v1 July 2005
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 should be assigned:
- id-msec-token OBJECT IDENTIFIER ::= TBD
- id-securitySuiteOne OBJECT IDENTIFIER ::= TBD
- id-GSAKMPv1RegistrationProtocol OBJECT IDENTIFIER::= TBD
- id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= TBD
- id-GSAKMPv1Rekey OBJECT IDENTIFIER::= TBD
- id-rekeyNone OBJECT IDENTIFIER ::= TBD
- id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= TBD
- id-reliabilityNone OBJECT IDENTIFIER ::= TBD
- id-reliabilityResend OBJECT IDENTIFIER ::= TBD
- id-reliabilityPost OBJECT IDENTIFIER ::= TBD
- id-subGCKSSchemeNone OBJECT IDENTIFIER ::= TBD
- id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= TBD
- id-genericDataSA OBJECT IDENTIFIER ::= TBD
Colegrove and Harney [Page 10]
INTERNET-DRAFT Group Polcy Token v1 July 2005
6 References
The following references were used in the preparation of this
document.
6.1 Normative References
[HMCG] H. Harney, U. Meth, A. Colegrove, and G. Gross, "GSAKMP",
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 Infrastructure Certificate and Certificate Revocation List
(CRL) Profile, April 2002.
[RFC 3852] R. Housley, Cryptographic Message Syntax, July 2004.
6.2 Non-Normative References
[HCLM00] H. Harney, A. Colegrove, P. Lough, and U. Meth, "GSAKMP
Token Specification", draft-ietf-msec-tokenspec-sec-00.txt.
[RFC 3711] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K.
Norrman, "The Secure Real-Time Transport Protocol (SRTP)", March
2004.
[RFC 3740] T. Hardjono and B. Weis, "The Multicast Group Security
Architecture", 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] , Thomas Hardjono, Hugh Harney, Pat McDaniel, Andrea
Colgrove, Pete Dinsmore, Group Security Policy Token: Definition and
Payloads', draft-ietf-msec-gspt-00.txt, Work in progress.
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
Colegrove and Harney [Page 11]
INTERNET-DRAFT Group Polcy Token v1 July 2005
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.
Colegrove and Harney [Page 12]
INTERNET-DRAFT Group Polcy Token v1 July 2005
A APPENDIX A -- Core Policy Token ASN.1 Module
PolicyToken -- {TBD}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
EXPORTS
LifeDate;
Token ::= SEQUENCE {
tokenInfo TokenID,
registration SEQUENCE OF Registration,
rekey SEQUENCE OF GroupMngmtProtocol,
data SEQUENCE OF DataProtocol
}
------------------------------------------------------------
-- Token ID
TokenID ::= SEQUENCE {
groupName OCTET STRING,
edition INTEGER OPTIONAL
}
LifeDate ::= CHOICE {
gt [0] GeneralizedTime,
utc [1] UTCTime,
interval [2] INTEGER
}
------------------------------------------------------------
-- Registration
Registration ::= SEQUENCE {
register GroupMngmtProtocol,
de-register GroupMngmtProtocol
}
------------------------------------------------------------
-- GroupMngmtProtocol
GroupMngmtProtocol ::= CHOICE {
none [0] NULL,
supported [1] Protocol
}
Protocol ::= SEQUENCE {
protocol OBJECT IDENTIFIER,
protocolInfo OCTET STRING
Colegrove and Harney [Page 13]
INTERNET-DRAFT Group Polcy Token v1 July 2005
}
------------------------------------------------------------
-- DataProtocol
DataProtocol ::= Protocol
------------------------------------------------------------
END
Colegrove and Harney [Page 14]
INTERNET-DRAFT Group Polcy Token v1 July 2005
B 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::= {TBD}
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.
JoinAuthorization ::= SEQUENCE {
gCKS GCKSName,
subGCKS SEQUENCE OF GCKSName OPTIONAL
}
Colegrove and Harney [Page 15]
INTERNET-DRAFT Group Polcy Token v1 July 2005
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 key identifier.
CertAuth ::= KeyIdentifier
B.1.2 AccessControl
joinAccessControl provides information on who is allowed to be a
Group Member. The access control list is implemented as a set
of permissions that the member must satisfy and a list of name
rules and the certificate authority that each must satisfy.
Additionally, a list of exclusions to the list is provided.
AccessControl ::= SEQUENCE {
permissions [1] EXPLICIT SEQUENCE OF Permission OPTIONAL,
accessRule [2] EXPLICIT SEQUENCE OF UserCAPair,
exclusionsRule [3] EXPLICIT SEQUENCE OF UserCAPair OPTIONAL
}
Colegrove and Harney [Page 16]
INTERNET-DRAFT Group Polcy Token v1 July 2005
The permissions initially available are an abstract set of numeric
levels that may be interpretted internal to a community.
Permission ::= CHOICE {
simplePermission [1] SimplePermission
}
SimplePermission ::= ENUMERATED {
one(1),
two(2),
three(3),
four(4),
five(5),
six(6),
seven(7),
eight(8),
nine(9)
}
B.1.3 JoinMechanisms
Allowable GSAKMP mechanism choices for a particular group are
specified in joinMechanisms. Any set of JoinMechanism is acceptable
from a policy perspective.
JoinMechanisms ::= SEQUENCE OF JoinMechanism
Each set of mechanisms used in the GSAKMP Registration may be
specified either as an explicitly defined set or as a pre-defined
security suite.
JoinMechanism ::= CHOICE {
alaCarte [0] Mechanisms,
suite [1] SecuritySuite
}
In an explicitly defined -- or alaCarte -- set, a mechanism
is defined for the signature, the key exchange algorithm, the
key wrapping algorithm, the type of acknowledgement data, and
configuration data for the setting of timeouts.
Colegrove and Harney [Page 17]
INTERNET-DRAFT Group Polcy Token v1 July 2005
Mechanisms ::= SEQUENCE {
signatureDef SigDef,
kEAlg KEAlg,
keyWrap KeyWrap,
ackData AckData,
opInfo OpInfo
}
The signature definition requires specification of the signature
algorithm for message signing. The INTEGER that defines the choice
corresponds to the GSAKMP Signature type.
SigDef ::= SEQUENCE {
sigAlgorithmID INTEGER,
hashAlgorithmID INTEGER
}
The key exchange algorithm requires an integer to define the GSAKMP
key creation type and may require additional per type data.
The INTEGER corresponding to hashAlgorithm will map to the GSAKMP
Nonce Hash type values. This algorithm is used in computing the
combined nonce.
KEAlg ::= SEQUENCE {
keyExchangeAlgorithmID INTEGER,
keyExchangeAlgorithmData OCTET STRING OPTIONAL
}
The keyWrap is the algorithm that is used to wrap the group key(s)
and the policy token (if included). The integer corresponds to the
GSAKMP encryption type.
KeyWrap ::= INTEGER
Data may potentially be returned in a GSAKMP Key Download ACK/Failure
message. The type of data required by a group is specified by
AckData. No such field is currently supported or required.
AckData ::= CHOICE {
none [0] NULL
}
Colegrove and Harney [Page 18]
INTERNET-DRAFT Group Polcy Token v1 July 2005
OpInfo provides configuration data for the operation of GSAKMP
registration. timeout indicates the elapsed amount of time
before a sent message is considered to be misrouted or lost. It
is specified as a time. terse informs a GC/KS whether the group
should be operated in terse (TRUE) or verbose (FALSE) mode.
OpInfo ::= SEQUENCE {
timeOut LifeDate,
terse BOOLEAN
}
If the choice of mechanism for the join is a predefined security
suite, then it is identified by OBJECT IDENTIFIER (OID). Other
security suites may be defined elsewhere by specification and
registration of an OID.
SecuritySuite ::= OBJECT IDENTIFIER
The OID for security suite 1, as defined within the GSAKMPv1
specification is
id-securitySuiteOne OBJECT IDENTIFIER ::= {TBD}
B.1.4 Transport
transport indicates what protocol GSAKMP should ride over. The
choice of udpRTJtcpOther indicates that the GSAKMP Request to
Join message is carried by UDP and all other group establishment
messages are carried by TCP.
Transport ::= CHOICE {
tcp [0] NULL,
udp [1] NULL,
udpRTJtcpOther [2] NULL
}
B.2 GSAKMPv1 Registration ASN.1 Module
GSAKMPv1RegistrationSA -- {TBD}
Colegrove and Harney [Page 19]
INTERNET-DRAFT Group Polcy Token v1 July 2005
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
EXPORTS
GCKSName;
IMPORTS
LifeDate
FROM PolicyToken {TBD}
KeyIdentifier
FROM PKIX1Implicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit(19) };
-- id-GSAKMPv1RegistrationProtocol OBJECT IDENTIFIER::= {TBD}
GSAKMPv1RegistrationInfo ::= SEQUENCE {
joinAuthorization JoinAuthorization,
joinAccessControl SEQUENCE OF AccessControl,
joinMechanisms JoinMechanisms,
transport Transport
}
JoinAuthorization ::= SEQUENCE {
gCKS GCKSName,
subGCKS SEQUENCE OF GCKSName OPTIONAL
}
GCKSName ::= SEQUENCE OF UserCAPair
UserCAPair ::= SEQUENCE {
groupEntity GSAKMPID,
cA CertAuth
}
CertAuth ::= KeyIdentifier
AccessControl ::= SEQUENCE {
permissions [1] EXPLICIT SEQUENCE OF Permission OPTIONAL,
accessRule [2] EXPLICIT SEQUENCE OF UserCAPair,
exclusionsRule [3] EXPLICIT SEQUENCE OF UserCAPair OPTIONAL
}
Permission ::= CHOICE {
simplePermission [1] SimplePermission
}
SimplePermission ::= ENUMERATED {
one(1),
two(2),
Colegrove and Harney [Page 20]
INTERNET-DRAFT Group Polcy Token v1 July 2005
three(3),
four(4),
five(5),
six(6),
seven(7),
eight(8),
nine(9)
}
GSAKMPID ::= SEQUENCE {
typeValue INTEGER,
typeData OCTET STRING
}
JoinMechanisms ::= SEQUENCE OF JoinMechanism
JoinMechanism ::= CHOICE {
alaCarte [0] Mechanisms,
suite [1] SecuritySuite
}
Mechanisms ::= SEQUENCE {
signatureDef SigDef,
kEAlg KEAlg,
keyWrap KeyWrap,
ackData AckData,
opInfo OpInfo
}
SecuritySuite ::= OBJECT IDENTIFIER
-- SECURITY SUITE ONE --
-- id-securitySuiteOne OBJECT IDENTIFIER ::= {TBD}
SigDef ::= SEQUENCE {
sigAlgorithmID INTEGER,
hashAlgorithmID INTEGER
}
KEAlg ::= SEQUENCE {
keyExchangeAlgorithmID INTEGER,
keyExchangeAlgorithmData OCTET STRING OPTIONAL
}
KeyWrap ::= INTEGER
AckData ::= CHOICE {
none [0] NULL
}
OpInfo ::= SEQUENCE {
Colegrove and Harney [Page 21]
INTERNET-DRAFT Group Polcy Token v1 July 2005
timeOut LifeDate,
terse BOOLEAN
}
Transport ::= CHOICE {
tcp [0] NULL,
udp [1] NULL,
udpRTJtcpOther [2] NULL
}
END
B.3 GSAKMPv1 De-Registration Policy
GSAKMP De-Registration provides a method to notify a (S-)GC/KS that
a member needs to leave a group. When GSAKMP is the De-Registration
Protocol for the Group, the following object identifier is used in
the core token.
id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= {TBD}
The De-Registration policy provides the mechanisms needed for the
De-Registration exchange messages, an indication of whether the
exchange is to be done using terse (TRUE) or verbose (FALSE) mode,
and the transport used for the GSAKMP De-registration messages.
GSAKMPv1DeRegistrationInfo ::= SEQUENCE {
leaveMechanisms SEQUENCE OF LeaveMechanisms,
terse BOOLEAN,
transport Transport
}
The policy dictating the mechanisms needed for the De-registration
exchange is defined by leaveMechanisms. This field is specified as
LeaveMechanisms ::= SEQUENCE {
sigAlgorithm INTEGER,
hashAlgorithm INTEGER,
cA KeyIdentifier
}
Colegrove and Harney [Page 22]
INTERNET-DRAFT Group Polcy Token v1 July 2005
The INTEGER corresponding to sigAlgorithm will map to the GSAKMP
Signature type values. This algorithm set is to be used for message
signing.
The INTEGER corresponding to hashAlgorithm will map to the GSAKMP
Nonce Hash type values. This algorithm is used in computing the
combined nonce.
cA represents a trust point off of which the signer's certificate
must certify. It is identified by the PKIX KeyIdentifier [RFC 3280]
type.
transport will provide the expected transport for GSAKMP
De-registration messages. Initially, either UDP or TCP will be the
policy for a group.
Transport ::= CHOICE {
tcp [0] NULL,
udp [1] NULL
}
B.4 GSAKMPv1 De-Registration ASN.1 Module
GSAKMPv1DeRegistrationSA -- {TBD}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
KeyIdentifier
FROM PKIX1Implicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit(19) };
-- id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= {TBD}
GSAKMPv1DeRegistrationInfo ::= SEQUENCE {
leaveMechanisms SEQUENCE OF LeaveMechanisms,
transport Transport
}
LeaveMechanisms ::= SEQUENCE {
sigAlgorithm INTEGER,
hashAlgorithm INTEGER,
cA KeyIdentifier
}
Colegrove and Harney [Page 23]
INTERNET-DRAFT Group Polcy Token v1 July 2005
Transport ::= CHOICE {
tcp [0] NULL,
udp [1] NULL
}
END
B.5 GSAKMPv1 Rekey Policy
When GSAKMP is used as the Rekey Protocol for the Group, the
following object identifier should be used in the core token as the
rekey protocol:
id-GSAKMPv1Rekey OBJECT IDENTIFIER::= {TBD}
The GSAKMP Rekey Policy provides authorization information,
mechanisms for the GSAKMP Rekey messages, indicators defining rekey
event definitions that define when the GC/KS should send a rekey
message, the protocol or method the rekey event will use, the rekey
interval that will allow a member to recognize a failure in the rekey
process, a reliability indicator that defines the method the rekey
will use to increase the likelyhood of a rekey delivery (if any), and
finally an indication of how subordinate-GC/KSs will handle rekey.
This policy also describes the specific Rekey policy methods "None"
and "GSAKMP LKH REKEY".
GSAKMPv1RekeyInfo ::= SEQUENCE {
authorization RekeyAuthorization,
mechanism RekeyMechanisms,
rekeyEventDef RekeyEventDef, -- tells the GCKS when to rekey
rekeyMethod RekeyMethod,
rekeyInterval LifeDate, -- member knows when to rejoin
reliability Reliability, -- what mech will be used to
-- increase the likelihood
-- of rekey delivery
subGCKSInfo SubGCKSInfo -- what subordinate gcks needs
}
B.5.1 Rekey Authorization
RekeyAuthorization ::= GCKSName
Colegrove and Harney [Page 24]
INTERNET-DRAFT Group Polcy Token v1 July 2005
B.5.2 Rekey Mechanisms
The policy dictating the mechanisms needed for Rekey message
processing is defined by RekeyMechanisms. This field is specified
as
RekeyMechanisms ::= SEQUENCE {
sigAlgorithm INTEGER,
hashAlgorithm INTEGER
}
The INTEGER corresponding to sigAlgorithm will map to the GSAKMP
Signature type values. This algorithm set is to be used for message
signing.
The INTEGER corresponding to hashAlgorithm will map to the GSAKMP
Nonce Hash type values. This algorithm is used in computing the
combined nonce.
B.5.3 Rekey Event Definition
Rekey Event Definition provides information to the GC/KS about
the system requirements for sending rekey messages. This allows
definition of the rekey event in time as well as event driven
characteristics (a number of de-registration notifications as an
example), or a combination of the two (e.g., after x de-registrations
or 24 hours, which ever comes first).
RekeyEventDef ::= CHOICE {
none [0] NULL, -- never rekey
timeOnly [1] LifeDate, -- rekey every x units
event [2] INTEGER, -- rekey after x events
timeAndEvent [3] TimeAndEvent
}
The LifeDate specifies the maximum time a group should exist between
rekeys. This does not require clock synchronization as this is used
with respect to a local clock.
The INTEGER corresponding to the event is an indicator of the number
of events a group should sustain before a rekey message is sent.
This defines the events between rekeys. An example of a relevant
event is de-registration notifications.
Colegrove and Harney [Page 25]
INTERNET-DRAFT Group Polcy Token v1 July 2005
The TimeAndEvent is defined as a couple of the LifeDate and Integer
policies.
TimeAndEvent ::= SEQUENCE {
time LifeDate, -- rekey after x units of time OR
event INTEGER -- x events occur
}
B.5.4 Rekey Methods
The policy dictating the rekey method supported by the Rekey message
is defined by RekeyMethod. This field is specified as
RekeyMethod ::= SEQUENCE {
rekeyMethodType OBJECT IDENTIFIER,
rekeyMethodInfo OCTET STRING
}
The rekeyMethodType will define the rekey method to be used by the
group.
The rekeyMethodInfo will supply the GMs with the information they
need to operate in the correct rekey mode.
B.5.4.1 Rekey Method NONE
The group defined to work without a rekey protocols supporting
it is supported by the rekeyMethodType NONE. There is no
RekeyMethodNoneInfo associated with this option.
id-rekeyNone OBJECT IDENTIFIER ::= {TBD}
RekeyMethodNoneInfo ::= NULL
B.5.4.2 Rekey Method GSAKMP LKH
The GSAKMP protocol specification defined an interpretation of the
Logical Key Hierarchy (LKH) protocol as a rekey method. This method
is supported by the following values.
Colegrove and Harney [Page 26]
INTERNET-DRAFT Group Polcy Token v1 July 2005
id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {TBD}
RekeyMethodGSAKMPLKHInfo ::= INTEGER
The GSAKMP LKH method requires a gsakmp type value for identifying
the cryptographic algorithm used to wrap the keys. This value maps
to the GSAKMP encryption type.
B.5.5 Rekey Interval
Rekey interval defines the maximum delay the GM should see
between valid rekeys. This provides a means to ensure the GM is
synchronized, from a key management perspective, with the rest of the
group. It is defined as a time/date stamp.
B.5.6 Rekey Reliability
The Rekey message in the GSAKMP protocol is a one sided exchange
of data. There are reliability concerns with one sided exchanges.
The Reliability policy defines the mechanism used to deal with these
concerns.
Reliability ::= SEQUENCE {
reliabilityMechanism OBJECT IDENTIFIER,
reliabilityMechContent OCTET STRING
}
The reliability mechanism is defined by an OBJECT IDENTIFIER and
the information needed to operate that mechanism is defined as
reliabilityMechContent and is an OCTET STRING. (as before)
B.5.6.1 Rekey Reliability Mechanism None
In networks with adequate reliability it may not be necessary to use
a mechanism to improve reliability of the Rekey Message. For these
networks the ReliabilityMechanism NONE is appropriate.
id-reliabilityNone OBJECT IDENTIFIER ::= {TBD}
ReliabilityContentNone ::= NULL
Colegrove and Harney [Page 27]
INTERNET-DRAFT Group Polcy Token v1 July 2005
B.5.6.2 Rekey Reliability Mechanism Resend
In networks with unknown or questionable reliability it may be
necessary to use a mechanism to improve reliability of the Rekey
Message. For these networks the ReliabilityMechanism RESEND is
potentially appropriate. This mechanism has the GC/KS repeatedly
sending out the same message.
id-reliabilityResend OBJECT IDENTIFIER ::= {TBD}
ReliabilityResendInfo ::= INTEGER
The INTEGER value in the ReliabilityResendInfo indicates the number
of times the message should be resent.
B.5.6.3 Rekey Reliability Mechanism Post
Another reliability mechanims is to post the rekey message on
some service that will make it generally available. This is the
reliabilityPost method.
id-reliabilityPost OBJECT IDENTIFIER ::= {TBD}
ReliabilityContentPost ::= IA5String
The IA5String associated with ReliabilityPost is the identifier of
the posting site and rekey message.
B.5.7 Distributed Operation Policy
The policy dictating the relationships between GC/KS and S-GC/KS for
distributed operations is defined as SubGCKSInfo. It is defined as
a couple of a subGCKSScheme and some information relating to that
Scheme in sGCKSContent.
SubGCKSInfo ::= SEQUENCE {
subGCKSScheme OBJECT IDENTIFIER,
sGCKSContent OCTET STRING
}
Colegrove and Harney [Page 28]
INTERNET-DRAFT Group Polcy Token v1 July 2005
B.5.7.1 No Distributed Operation
If the group is not to use S-GC/KS then that Scheme would be
SGCKSSchemeNone.
id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {TBD}
SGCKSNoneContent ::= NULL
B.5.7.2 Autonomous Distributed Mode
If the group is to use S-GC/KS as defined in the GSAKMP specification
as Autonomous mode, then that scheme would be SGCKSAutonomous.
id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= {TBD}
SGCKSAutonomous ::= SEQUENCE {
authSubs GCKSName,
domain OCTET STRING OPTIONAL
}
The policy information needed for autonomous mode is a list of
authorized S-GC/KSs and and restrictions on who they may serve.
The domain field, representing these restrictions is NULL for this
version.
B.6 GSAKMPv1 Rekey Policy ASN.1 Module
GSAKMPv1RekeySA -- {TBD}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
GCKSName
FROM GSAKMPv1RegistrationSA {TBD}
LifeDate
FROM PolicyToken {TBD};
-- id-GSAKMPv1Rekey OBJECT IDENTIFIER::= {TBD}
Colegrove and Harney [Page 29]
INTERNET-DRAFT Group Polcy Token v1 July 2005
GSAKMPv1RekeyInfo ::= SEQUENCE {
authorization RekeyAuthorization,
mechanism RekeyMechanisms,
rekeyEventDef RekeyEventDef, -- tells the GCKS when to rekey
rekeyMethod RekeyMethod,
rekeyInterval LifeDate, -- member knows when to rejoin
reliability Reliability, -- what mech will be used to
-- increase the likelyhood
-- of rekey delivery
subGCKSInfo SubGCKSInfo -- what subordinate gcks needs
}
RekeyAuthorization ::= GCKSName
RekeyMechanisms ::= SEQUENCE {
sigAlgorithm INTEGER,
hashAlgorithm INTEGER
}
RekeyEventDef ::= CHOICE {
none [0] NULL, -- never rekey
timeOnly [1] EXPLICIT LifeDate, -- rekey every x units
event [2] INTEGER, -- rekey after x events
timeAndEvent [3] TimeAndEvent
}
TimeAndEvent ::= SEQUENCE {
time LifeDate, -- rekey after x units of time OR
event INTEGER -- x events occur
}
RekeyMethod ::= SEQUENCE {
rekeyMethodType OBJECT IDENTIFIER,
rekeyMethodInfo OCTET STRING
}
-- REKEY METHOD NONE --
-- id-rekeyNone OBJECT IDENTIFIER ::= {TBD}
RekeyMethodNoneInfo ::= NULL
-- REKEY METHOD GSAKMP LKH --
-- id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {TBD}
RekeyMethodGSAKMPLKHInfo ::= INTEGER -- gsakmp type value for
-- wrapping mechanism
Reliability ::= SEQUENCE {
reliabilityMechanism OBJECT IDENTIFIER,
Colegrove and Harney [Page 30]
INTERNET-DRAFT Group Polcy Token v1 July 2005
reliabilityMechContent OCTET STRING
}
-- RELIABILITY MECHANISM NONE --
-- id-reliabilityNone OBJECT IDENTIFIER ::= {TBD}
ReliabilityContentNone ::= NULL
-- RELIABILITY MECHANISM RESEND --
-- id-reliabilityResend OBJECT IDENTIFIER ::= {TBD}
ReliabilityResendInfo ::= INTEGER -- # of times rekey message should
-- be resent
-- RELIABILITY MECHANISM POST --
-- id-reliabilityPost OBJECT IDENTIFIER ::= {TBD}
ReliabilityContentPost ::= IA5String
SubGCKSInfo ::= SEQUENCE {
subGCKSScheme OBJECT IDENTIFIER,
sGCKSContent OCTET STRING
}
-- id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {TBD}
SGCKSNoneContent ::= NULL
-- id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= {TBD}
SGCKSAutonomous ::= SEQUENCE {
authSubs GCKSName,
domain OCTET STRING OPTIONAL
}
END
C APPENDIX C -- Data SA Policy
The Data SA provides the data structures needed for the protection
of the data exchanged between group members. This appendix defines
the data structures needed for a simple, generic security application
making use of fixed security mechanisms. Such a Data SA requires
only that keys delivered by the registration and rekey protocols be
mapped to the service using them.
Colegrove and Harney [Page 31]
INTERNET-DRAFT Group Polcy Token v1 July 2005
C.1 Generic Data Policy
The Generic Data Policy has the following identifier:
id-genericDataSA OBJECT IDENTIFIER :: = TBD
If an authentication mechanism is used within the security
application, the key identifier used in the key management protocol
is given, as well as an optional key expiration date. Likewise,
if an encryption mechanism is used within the security application,
the encryption key identifier is given, as well as an optional key
expiration date.
GenericDataSAInfo ::= SEQUENCE {
authentication [0] KeyInfo OPTIONAL,
encryption [1] KeyInfo OPTIONAL
}
KeyInfo ::= SEQUENCE{
kMKeyID OCTET STRING,
keyExpirationDate LifeDate OPTIONAL
}
C.2 Generic Data Policy ASN.1 Module
GenericDataSA -- {TBD}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- DATA APPLICATION: Generic
-- This token specification is for data applications with
-- fixed security mechanisms. Such data applications only
-- need a mapping of management protocol key identification
-- tags to security service.
IMPORTS
LifeDate
FROM PolicyToken {TBD}
KeyIdentifier
FROM PKIX1Implicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
Colegrove and Harney [Page 32]
INTERNET-DRAFT Group Polcy Token v1 July 2005
id-mod(0) id-pkix1-implicit(19) };
-- id-genericDataSA OBJECT IDENTIFIER ::= {TBD}
GenericDataSAInfo ::= SEQUENCE {
authentication [0] KeyInfo OPTIONAL,
encryption [1] KeyInfo OPTIONAL
}
KeyInfo ::= SEQUENCE{
kMKeyID OCTET STRING,
keyExpirationDate LifeDate OPTIONAL
}
END
D APPENDIX D -- Change History (To Be Removed from RFC)
D.1 Changes from Group Policy Token v-00 to v-01, December 2004
- Editorial/Grammatical changes throughout the document.
- Core Policy Token ASN.1 Module Appendix rewritten.
- GSAKMPv1 Registration ASN.1 Module Appendix rewritten.
- GSAKMPv1 De-Registration ASN.1 Module Appendix rewritten.
- GSAKMPv1 Rekey Policy ASN.1 Module Appendix rewritten.
- RFC 3711 Policy Appendix was rewritten.
D.2 Changes from Group Policy Token v-01 to v-02, March 2005
- RFC 3711 policy removed.
- Generic Data SA provided.
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
Colegrove and Harney [Page 33]
INTERNET-DRAFT Group Polcy Token v1 July 2005
ambiguities.
Colegrove and Harney [Page 34]
INTERNET-DRAFT Group Polcy Token v1 July 2005
Authors' Addresses
Andrea Colegrove
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
(410) 872-1515 ext 232
FAX (410) 872-8079
acc@sparta.com
Hugh Harney
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
(410) 872-1515 ext 203
FAX (410) 872-8079
hh@sparta.com
Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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.
Colegrove and Harney [Page 35]
INTERNET-DRAFT Group Polcy Token v1 July 2005
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
Colegrove and Harney [Page 36]
| PAFTECH AB 2003-2026 | 2026-04-24 01:55:52 |