draft-ietf-msec-policy-token-sec-03.txt   draft-ietf-msec-policy-token-sec-04.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-03.txt SPARTA, Inc. draft-ietf-msec-policy-token-sec-04.txt SPARTA, Inc.
Expires: January 7, 2006 July 2005 Expires: March 30, 2006 September 2005
Group Policy Token v1: Group Security Policy Token v1
Group Policy Token V1 with Application to GSAKMP
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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note Task Force (IETF), its areas, and its working groups. Note
that other groups may also distribute working documents as that other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress." material or to cite them other than as "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/1id-abstracts.html 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 The Group Security Policy Token is a structure used to
security policy and configurable parameters for a specify the security policy and configurable parameters for
cryptographic group, such as a secure multicast group. This a cryptographic group, such as a secure multicast group.
document specifies the structure of such a token in order to This document specifies the structure of such a token in
securely bind system-level security to protocols supporting order to securely bind system-level security to protocols
the management of cryptographic groups. supporting the management of cryptographic groups.
Copyright Notice Copyright (c) The Internet Society (2005). All
Rights Reserved.
Contents Contents
1 Introduction 5 1 Introduction 4
2 Token Creation and Receipt 6 2 Token Creation and Receipt 5
3 The Policy Token 6 3 The Policy Token 5
3.1 tokenInfo . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Token Identifiers . . . . . . . . . . . . . . . . . . . . . 6
3.2 registration . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Registration Policy . . . . . . . . . . . . . . . . . . . . 7
3.3 rekey . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3 Rekey Policy . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 data . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4 Group Data Policy . . . . . . . . . . . . . . . . . . . . . 8
4 Security Considerations 9 4 Security Considerations 9
5 IANA Considerations 10 5 IANA Considerations 9
6 References 11 6 References 10
6.1 Normative References . . . . . . . . . . . . . . . . . . . 11 6.1 Normative References . . . . . . . . . . . . . . . . . . . 10
6.2 Non-Normative References . . . . . . . . . . . . . . . . . 11 6.2 Non-Normative References . . . . . . . . . . . . . . . . . 10
7 Acknowledgements 11 7 Acknowledgments 11
A APPENDIX A -- Core Policy Token ASN.1 Module 13 A APPENDIX A -- Core Policy Token ASN.1 Module 12
B APPENDIX B -- GSAKMPv1 Base Policy 15 B APPENDIX B -- GSAKMPv1 Base Policy 14
B.1 GSAKMPv1 Registration Policy . . . . . . . . . . . . . . . 15 B.1 GSAKMPv1 Registration Policy . . . . . . . . . . . . . . . 14
B.1.1 Authorization . . . . . . . . . . . . . . . . . . . . . 15 B.1.1 Authorization . . . . . . . . . . . . . . . . . . . . . 14
B.1.2 AccessControl . . . . . . . . . . . . . . . . . . . . . 16 B.1.2 AccessControl . . . . . . . . . . . . . . . . . . . . 16
B.1.3 JoinMechanisms . . . . . . . . . . . . . . . . . . . . 17 B.1.3 JoinMechanisms . . . . . . . . . . . . . . . . . . . . 16
B.1.3.1 alaCarte . . . . . . . . . . . . . . . . . . . . 17
B.1.3.2 suite . . . . . . . . . . . . . . . . . . . . . 18
B.1.4 Transport . . . . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . 22 B.3 GSAKMPv1 De-Registration Policy . . . . . . . . . . . . . . 22
B.4 GSAKMPv1 De-Registration ASN.1 Module . . . . . . . . . . . 23 B.4 GSAKMPv1 De-Registration ASN.1 Module . . . . . . . . . . . 23
B.5 GSAKMPv1 Rekey Policy . . . . . . . . . . . . . . . . . . . 24 B.5 GSAKMPv1 Rekey Policy . . . . . . . . . . . . . . . . . . . 23
B.5.1 Rekey Authorization . . . . . . . . . . . . . . . . . . 24 B.5.1 Rekey Authorization . . . . . . . . . . . . . . . . . . 24
B.5.2 Rekey Mechanisms . . . . . . . . . . . . . . . . . . . 25 B.5.2 Rekey Mechanisms . . . . . . . . . . . . . . . . . . . 24
B.5.3 Rekey Event Definition . . . . . . . . . . . . . . . . 25 B.5.3 Rekey Event Definition . . . . . . . . . . . . . . . . 25
B.5.4 Rekey Methods . . . . . . . . . . . . . . . . . . . . . 26 B.5.4 Rekey Methods . . . . . . . . . . . . . . . . . . . . . 26
B.5.4.1 Rekey Method NONE . . . . . . . . . . . . . . . . 26 B.5.4.1 Rekey Method NONE . . . . . . . . . . . . . . . . 26
B.5.4.2 Rekey Method GSAKMP LKH . . . . . . . . . . . . . 26 B.5.4.2 Rekey Method GSAKMP LKH . . . . . . . . . . . . . 26
B.5.5 Rekey Interval . . . . . . . . . . . . . . . . . . . . 27 B.5.5 Rekey Interval . . . . . . . . . . . . . . . . . . . . 27
B.5.6 Rekey Reliability . . . . . . . . . . . . . . . . . . . 27 B.5.6 Rekey Reliability . . . . . . . . . . . . . . . . . . . 27
B.5.6.1 Rekey Reliability Mechanism None . . . . . . . . 27 B.5.6.1 Rekey Reliability Mechanism None . . . . . . . . 27
B.5.6.2 Rekey Reliability Mechanism Resend . . . . . . . 28 B.5.6.2 Rekey Reliability Mechanism Resend . . . . . . . 27
B.5.6.3 Rekey Reliability Mechanism Post . . . . . . . . 28 B.5.6.3 Rekey Reliability Mechanism Post . . . . . . . . 28
B.5.7 Distributed Operation Policy . . . . . . . . . . . . . 28 B.5.7 Distributed Operation Policy . . . . . . . . . . . . . 28
B.5.7.1 No Distributed Operation . . . . . . . . . . . . 29 B.5.7.1 No Distributed Operation . . . . . . . . . . . . 28
B.5.7.2 Autonomous Distributed Mode . . . . . . . . . . . 29 B.5.7.2 Autonomous Distributed Mode . . . . . . . . . . . 29
B.6 GSAKMPv1 Rekey Policy ASN.1 Module . . . . . . . . . . . . 29 B.6 GSAKMPv1 Rekey Policy ASN.1 Module . . . . . . . . . . . . 29
C APPENDIX C -- Data SA Policy 31 C APPENDIX C -- Data SA Policy 32
C.1 Generic Data Policy . . . . . . . . . . . . . . . . . . . . 32 C.1 Generic Data Policy . . . . . . . . . . . . . . . . . . . . 32
C.2 Generic Data Policy ASN.1 Module . . . . . . . . . . . . . 32 C.2 Generic Data Policy ASN.1 Module . . . . . . . . . . . . . 33
D APPENDIX D -- Change History (To Be Removed from RFC) 33 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 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 . 33 D.2 Changes from Group Policy Token v-01 to v-02, March 2005 . 34
D.3 Changes from Group Policy Token v-02 to v-03, July 2005 . . 33 D.3 Changes from Group Policy Token v-02 to v-03, July 2005 . . 34
D.4 Changes from Group Policy Token v-03 to v-04, September 2005 34
Authors Addresses 35 Authors Addresses 35
Full Copyright Statement 35 Full Copyright Statement 35
IPR Considerations 35 IPR Considerations 35
1 Introduction 1 Introduction
The Multicast Group Security Architecture [HW05] defines the security The Multicast Group Security Architecture [RFC3740] defines the
infrastructure to support secure group communications. The Policy security infrastructure to support secure group communications. The
Token assumes this architecture in its definition. It defines the Policy Token assumes this architecture in its definition. It defines
enforceable security parameters for a Group Secure Association. the enforceable security parameters for a Group Secure Association.
The Policy Token is a verifiable data construct signed by the group The Policy Token is a verifiable data construct signed by the group
owner, the entity with the authorization to create security policy. owner, the entity with the authorization to create security policy.
The group controllers in a group will use the policy token to ensure The group controllers in a group will use the policy token to ensure
that the mechanisms used to secure the group are correct and to that the mechanisms used to secure the group are correct and to
enforce the access control rules for joining members. The group enforce the access control rules for joining members. The group
members, who may contribute data to the group or access data from the members, who may contribute data to the group or access data from the
group, will use the policy token to ensure that the group is owned by group, will use the policy token to ensure that the group is owned by
a trusted authority. Also, the members may want to verify that the a trusted authority. Also, the members may want to verify that the
access control rules are adequate to protect the data that member is access control rules are adequate to protect the data that member is
submitting to the group. submitting to the group.
The policy token is specified in ASN.1 and is to be DER encoded. The Policy Token is specified in ASN.1 and is to be DER encoded.
This specification ability allows the token to easily import group This specification ability allows the token to easily import group
definitions that span different applications and environments. definitions that span different applications and environments.
ASN.1 allows the token to specify branches that can be used by any ASN.1 allows the token to specify branches that can be used by any
multicast security protocol. Any group can use this policy token multicast security protocol. Any group can use this policy token
structure to specify the use of multiple protocols in securing the structure to specify the use of multiple protocols in securing the
group. group.
Care was taken in this specification to provide a core level of token Care was taken in this specification to provide a core level of token
specificity that would allow ease of extensibility and flexibility specificity that would allow ease of extensibility and flexibility
in supporting mechanisms. This was done by using the following in supporting mechanisms. This was done by using the following
skipping to change at page 7, line 20 skipping to change at page 6, line 20
} }
tokenInfo provides information about the instance of the Policy tokenInfo provides information about the instance of the Policy
Token (PT). Token (PT).
registration provides a list of acceptable registration and registration provides a list of acceptable registration and
deregistration policy and mechanisms that may be used to manage deregistration policy and mechanisms that may be used to manage
member-initiated joins and departures from a group. A NULL member-initiated joins and departures from a group. A NULL
sequence indicates that the group does not support registration sequence indicates that the group does not support registration
and deregistration of members. A member MUST be able to support and deregistration of members. A member MUST be able to support
at least one set of Registration mechansims in order to join the at least one set of Registration mechanisms in order to join
group. When multiple mechanisms are present, a member MAY use the group. When multiple mechanisms are present, a member MAY
any of the listed methods. The list is ordered in terms of Group use any of the listed methods. The list is ordered in terms of
Owner preference. A member SHOULD choose the highest listed Group Owner preference. A member MUST choose the highest listed
mechanism that local policy supports. mechanism that local policy supports.
rekey provides the rekey protocols that will be used in managing the rekey provides the rekey protocols that will be used in managing
group. The member MUST be able to accept one of the types of the group. The member MUST be able to accept one of the types
rekey messages listed. The list is ordered in terms of Group of rekey messages listed. The list is ordered in terms of
Owner preference. A member SHOULD 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.
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 tokenInfo 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 {
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
skipping to change at page 8, line 22 skipping to change at page 7, line 22
PT. If edition is present, group entities MUST accept a PT only PT. If edition is present, group entities MUST accept a PT only
when the value is greater than the last value seen in a valid PT when the value is greater than the last value seen in a valid PT
for that group. for that group.
The type LifeDate is also defined to provide standard methods of The type LifeDate is also defined to provide standard methods of
indicating timestamps and intervals in the Tokens. indicating timestamps and intervals in the Tokens.
LifeDate ::= CHOICE { LifeDate ::= CHOICE {
gt [0] GeneralizedTime, gt [0] GeneralizedTime,
utc [1] UTCTime, utc [1] UTCTime,
interval [2] INTEGER, interval [2] INTEGER
} }
3.2 registration 3.2 Registration Policy
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 registration, a prospective group member and the group controller
will interact to give the group member access to the keys and will interact to give the group member access to the keys and
information it needs to join and participate in the group data SA. information it needs to join the group and participate in the group
data SA.
The deregistration piece allows a current group member to notify the 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. GC/KS that it will no longer be participating in the data SA.
Registration ::= SEQUENCE { Registration ::= SEQUENCE {
register GroupMngmtProtocol, register GroupMngmtProtocol,
de-register GroupMngmtProtocol de-register GroupMngmtProtocol
} }
The protocol for registration and de-registration are each specified The protocol for registration and de-registration are each specified
as as
GroupMngmtProtocol ::= CHOICE { GroupMngmtProtocol ::= CHOICE {
none [0] NULL, none [0] NULL,
skipping to change at page 9, line 19 skipping to change at page 8, line 19
Protocol ::= SEQUENCE { Protocol ::= SEQUENCE {
protocol OBJECT IDENTIFIER, protocol OBJECT IDENTIFIER,
protocolInfo OCTET STRING protocolInfo OCTET STRING
} }
For example, register might be specified as the GSAKMP [HMCG] For example, register might be specified as the GSAKMP [HMCG]
registration protocol. The OBJECT IDENTIFIER TBS would be followed registration protocol. The OBJECT IDENTIFIER TBS would be followed
by the parameters used in GSAKMP registration as specified in by the parameters used in GSAKMP registration as specified in
appendix B.1. appendix B.1.
3.3 rekey 3.3 Rekey Policy
The Rekey SA is defined in the MSEC Architecture. During Rekey, the The Rekey SA is defined in the MSEC Architecture. During the Rekey
membership of the group can be modified as well as refreshing the of a group, several changes can potentially be made:
group traffic protection keys and updating the Policy Token.
- 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 This field is also specified as a sequence of protocols that will be
used by the GC/KS. used by the GC/KS.
3.4 data 3.4 Group Data Policy
The Data SA is the ultimate consumer of the group keys. The data The Data SA is the ultimate consumer of the group keys. The data
field will indicate the keys and mechanisms that are to be used in field will indicate the keys and mechanisms that are to be used in
communications between group members. There are several protocols communications between group members. There are several protocols
that could make use of multicast key, ranging from simple security that could make use of group keys, ranging from simple security
applications needing key only to more complex configurable security applications that only need key for encryption and/or integrity
protocols such as IPSec and SRTP. The sequencing of the Data SA protection to more complex configurable security protocols such as
mechanisms are from "inside" to "outside". That is, the first Data IPsec and SRTP. The sequencing of the Data SA mechanisms are from
SA defined in a policy token must act on the raw data. Any data SA "inside" to "outside". That is, the first Data SA defined in a
specified after that will be applied in turn. 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 This document specifies the structure for a Group Policy Token. As
such, the structure as received by a group entity must be verifiably such, the structure as received by a group entity must be verifiably
authentic. This Policy Token uses CMS to apply authentication authentic. This Policy Token uses CMS to apply authentication
through digital signatures. The security of this scheme relies through digital signatures. The security of this scheme relies
upon a secure CMS implementation, choice of signature mechanism upon a secure CMS implementation, choice of signature mechanism
of appropriate strength for the group using the Policy Token, of appropriate strength for the group using the Policy Token,
and secure, sufficiently strong keys. Additionally, it relies and secure, sufficiently strong keys. Additionally, it relies
upon knowledge of a well-known Group Owner as the root of policy upon knowledge of a well-known Group Owner as the root of policy
enforcement. enforcement.
Furthermore, while the Group Owner may list alternate mechanisms Furthermore, while the Group Owner may list alternate mechanisms
skipping to change at page 11, line 16 skipping to change at page 10, line 23
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.
[RFC 3280] R. Housley, W. Polk, W. Ford, D. Solo, Internet X.509 [RFC 3280] R. Housley, W. Polk, W. Ford, D. Solo, Internet X.509
Pulbic Key Infrastructure Certificate and Certificate Revocation List Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile, April 2002. (CRL) Profile, RFC 3280, April 2002.
[RFC 3852] R. Housley, Cryptographic Message Syntax, July 2004. [RFC 3852] R. Housley, Cryptographic Message Syntax, RFC 3825, July
2004.
6.2 Non-Normative References 6.2 Non-Normative References
[HCLM00] H. Harney, A. Colegrove, P. Lough, and U. Meth, "GSAKMP [HCLM00] H. Harney, A. Colegrove, P. Lough, and U. Meth, "GSAKMP
Token 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. [RFC 3711] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K.
Norrman, "The Secure Real-Time Transport Protocol (SRTP)", March Norrman, "The Secure Real-Time Transport Protocol (SRTP)", RFC 3711,
2004. 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", RFC 3740, March 2004.
[HCM01] H. Harney, A. Colegrove, P. McDaniel, "Principles of Policy [HCM01] H. Harney, A. Colegrove, P. McDaniel, "Principles of Policy
in Secure Groups", Proceedings of Network and Distributed Systems in Secure Groups", Proceedings of Network and Distributed Systems
Security 2001 Internet Society, San Diego, CA, February 2001 Security 2001 Internet Society, San Diego, CA, February 2001
[HHMCD01] , Thomas Hardjono, Hugh Harney, Pat McDaniel, Andrea [HHMCD01] , Thomas Hardjono, Hugh Harney, Pat McDaniel, Andrea
Colgrove, Pete Dinsmore, Group Security Policy Token: Definition and Colgrove, Pete Dinsmore, Group Security Policy Token: Definition and
Payloads', draft-ietf-msec-gspt-00.txt, Work in progress. Payloads', draft-ietf-msec-gspt-00.txt, Expired.
7 Acknowledgements 7 Acknowledgments
The following individuals deserve recognition and thanks for their The following individuals deserve recognition and thanks for their
contributions which have greatly improved this specification: Uri contributions which have greatly improved this specification: Uri
Meth whose knowledge of GSAKMP and tokens was greatly appreciated Meth whose knowledge of GSAKMP and tokens was greatly appreciated
as well as his help in getting this document submitted; Peter Lough, as well as his help in getting this document submitted; Peter Lough,
Thomas Hardjono, Patrick McDaniel, and Pete Dinsmore for their work Thomas Hardjono, Patrick McDaniel, and Pete Dinsmore for their work
on earlier versions of policy tokens; George Gross for the impetus to on earlier versions of policy tokens; George Gross for the impetus to
have a well-specified, extensible policy token; and Rod Fleischer for have a well-specified, extensible policy token; and Rod Fleischer for
catching implementation issues. catching implementation issues.
skipping to change at page 15, line 36 skipping to change at page 14, line 36
GSAKMPv1RegistrationInfo ::= SEQUENCE { GSAKMPv1RegistrationInfo ::= SEQUENCE {
joinAuthorization JoinAuthorization, joinAuthorization JoinAuthorization,
joinAccessControl SEQUENCE OF AccessControl, joinAccessControl SEQUENCE OF AccessControl,
joinMechanisms JoinMechanisms, joinMechanisms JoinMechanisms,
transport Transport transport Transport
} }
B.1.1 Authorization B.1.1 Authorization
joinAuthorization provides information on who is allowed to be a joinAuthorization provides information on who is allowed to be a
Group Controller/Key Server (GC/KS) and a sub-GC/KS. 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 { JoinAuthorization ::= SEQUENCE {
gCKS GCKSName, gCKS GCKSName,
subGCKS SEQUENCE OF GCKSName OPTIONAL subGCKS SEQUENCE OF GCKSName OPTIONAL,
senders SenderAuthorization
} }
The authorization information is in the form of an access control The authorization information is in the form of an access control
list indicating entity name and acceptable certification authority list indicating entity name and acceptable certification authority
information for the entity's certificate. information for the entity's certificate.
GCKSName ::= SEQUENCE OF UserCAPair GCKSName ::= SEQUENCE OF UserCAPair
UserCAPair ::= SEQUENCE { UserCAPair ::= SEQUENCE {
groupEntity GSAKMPID, groupEntity GSAKMPID,
cA CertAuth cA CertAuth
skipping to change at page 16, line 27 skipping to change at page 15, line 27
When a portion of a defined name type is filled with an "*", this When a portion of a defined name type is filled with an "*", this
indicates a wildcard, representing any valid choice for a field. indicates a wildcard, representing any valid choice for a field.
This allows the specification of an authorization rule that is a This allows the specification of an authorization rule that is a
set of related names. set of related names.
GSAKMPID ::= SEQUENCE { GSAKMPID ::= SEQUENCE {
typeValue INTEGER, typeValue INTEGER,
typeData OCTET STRING typeData OCTET STRING
} }
The certificate authority is identified by the X.509 key identifier. The certificate authority is identified by the X.509 [RFC 3280] key
identifier.
CertAuth ::= KeyIdentifier CertAuth ::= KeyIdentifier
Senders within a group can either 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 B.1.2 AccessControl
joinAccessControl provides information on who is allowed to be a joinAccessControl provides information on who is allowed to be a
Group Member. The access control list is implemented as a set Group Member. The access control list is implemented as a set
of permissions that the member must satisfy and a list of name of permissions that the member must satisfy and a list of name
rules and the certificate authority that each must satisfy. rules and the certificate authority that each must satisfy.
Additionally, a list of exclusions to the list is provided. Additionally, a list of exclusions to the list may be provided.
AccessControl ::= SEQUENCE { AccessControl ::= SEQUENCE {
permissions [1] EXPLICIT SEQUENCE OF Permission OPTIONAL, permissions [1] EXPLICIT SEQUENCE OF Permission OPTIONAL,
accessRule [2] EXPLICIT SEQUENCE OF UserCAPair, accessRule [2] EXPLICIT SEQUENCE OF UserCAPair,
exclusionsRule [3] EXPLICIT SEQUENCE OF UserCAPair OPTIONAL exclusionsRule [3] EXPLICIT SEQUENCE OF UserCAPair OPTIONAL
} }
The permissions initially available are an abstract set of numeric The permissions initially available are an abstract set of numeric
levels that may be interpretted internal to a community. levels that may be interpreted 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),
skipping to change at page 17, line 30 skipping to change at page 17, line 4
nine(9) nine(9)
} }
B.1.3 JoinMechanisms B.1.3 JoinMechanisms
Allowable GSAKMP mechanism choices for a particular group are Allowable GSAKMP mechanism choices for a particular group are
specified in joinMechanisms. Any set of JoinMechanism is acceptable specified in joinMechanisms. Any set of JoinMechanism is acceptable
from a policy perspective. from a policy perspective.
JoinMechanisms ::= SEQUENCE OF JoinMechanism JoinMechanisms ::= SEQUENCE OF JoinMechanism
Each set of mechanisms used in the GSAKMP Registration may be Each set of mechanisms used in the GSAKMP Registration may be
specified either as an explicitly defined set or as a pre-defined specified either as an explicitly defined set or as a pre-defined
security suite. security suite.
JoinMechanism ::= CHOICE { JoinMechanism ::= CHOICE {
alaCarte [0] Mechanisms, alaCarte [0] Mechanisms,
suite [1] SecuritySuite suite [1] SecuritySuite
} }
B.1.3.1 alaCarte
In an explicitly defined -- or alaCarte -- set, a mechanism In an explicitly defined -- or alaCarte -- set, a mechanism
is defined for the signature, the key exchange algorithm, the is defined for the signature, the key exchange algorithm, the
key wrapping algorithm, the type of acknowledgement data, and key wrapping algorithm, the type of acknowledgment data, and
configuration data for the setting of timeouts. configuration data for the setting of timeouts.
Mechanisms ::= SEQUENCE { Mechanisms ::= SEQUENCE {
signatureDef SigDef, signatureDef SigDef,
kEAlg KEAlg, kEAlg KEAlg,
keyWrap KeyWrap, keyWrap KeyWrap,
ackData AckData, ackData AckData,
opInfo OpInfo opInfo OpInfo
} }
The signature definition requires specification of the signature The signature definition requires specification of the signature
algorithm for message signing. The INTEGER that defines the choice algorithm for message signing. The INTEGER that defines the choice
corresponds to the GSAKMP Signature type. corresponds to the GSAKMP Signature type.
SigDef ::= SEQUENCE { SigDef ::= SEQUENCE {
sigAlgorithmID INTEGER, sigAlgorithmID INTEGER,
hashAlgorithmID INTEGER hashAlgorithmID INTEGER
} }
The 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 The INTEGER corresponding to hashAlgorithm will map to the GSAKMP
Nonce Hash type values. This algorithm is used in computing the Nonce Hash type values. This algorithm is used in computing the
combined nonce. combined nonce.
The key exchange algorithm requires an integer to define the GSAKMP
key creation type and may require additional per type data.
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) 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 and the policy token (if included). The integer corresponds to the
GSAKMP encryption type. GSAKMP encryption type.
KeyWrap ::= INTEGER KeyWrap ::= INTEGER
skipping to change at page 19, line 4 skipping to change at page 18, line 23
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 message. The type of data required by a group is specified by
AckData. No 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. timeout indicates the elapsed amount of time registration. timeOut indicates the elapsed amount of time
before a sent message is considered to be misrouted or lost. It before a sent message is considered to be misrouted or lost. It
is specified as a time. terse informs a GC/KS whether the group is specified as the timestamp type LifeDate, previously defined
in the core token. terse informs a GC/KS whether the group
should be operated in terse (TRUE) or verbose (FALSE) mode. should be operated in terse (TRUE) or verbose (FALSE) mode.
OpInfo ::= SEQUENCE { OpInfo ::= SEQUENCE {
timeOut LifeDate, timeOut LifeDate,
terse BOOLEAN terse BOOLEAN
} }
B.1.3.2 suite
If the choice of mechanism for the join is a predefined security If the choice of mechanism for the join is a predefined security
suite, then it is identified by OBJECT IDENTIFIER (OID). Other suite, then it is identified by OBJECT IDENTIFIER (OID). Other
security suites may be defined elsewhere by specification and security suites may be defined elsewhere by specification and
registration of an OID. registration of an OID.
SecuritySuite ::= OBJECT IDENTIFIER SecuritySuite ::= OBJECT IDENTIFIER
The OID for security suite 1, as defined within the GSAKMPv1 The OID for security suite 1, as defined within the GSAKMPv1
specification is specification is
id-securitySuiteOne OBJECT IDENTIFIER ::= {TBD} id-securitySuiteOne OBJECT IDENTIFIER ::= {TBD}
B.1.4 Transport B.1.4 Transport
transport indicates what protocol GSAKMP should ride over. The transport indicates what protocol GSAKMP should ride over. The
choice of udpRTJtcpOther indicates that the GSAKMP Request to choice of udpRTJtcpOther indicates that the GSAKMP Request to
Join message is carried by UDP and all other group establishment Join message is carried by UDP and all other group establishment
skipping to change at page 20, line 30 skipping to change at page 20, line 8
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,
subGCKS SEQUENCE OF GCKSName OPTIONAL subGCKS SEQUENCE OF GCKSName OPTIONAL,
senders SenderAuthorization
} }
GCKSName ::= SEQUENCE OF UserCAPair GCKSName ::= SEQUENCE OF UserCAPair
UserCAPair ::= SEQUENCE { UserCAPair ::= SEQUENCE {
groupEntity GSAKMPID, groupEntity GSAKMPID,
cA CertAuth cA CertAuth
} }
CertAuth ::= KeyIdentifier CertAuth ::= KeyIdentifier
SenderAuthorization ::= CHOICE {
all [0] NULL,
limited [1] EXPLICIT SEQUENCE OF UserCAPair
}
AccessControl ::= SEQUENCE { AccessControl ::= SEQUENCE {
permissions [1] EXPLICIT SEQUENCE OF Permission OPTIONAL, permissions [1] EXPLICIT SEQUENCE OF Permission OPTIONAL,
accessRule [2] EXPLICIT SEQUENCE OF UserCAPair, accessRule [2] EXPLICIT SEQUENCE OF UserCAPair,
exclusionsRule [3] EXPLICIT SEQUENCE OF UserCAPair OPTIONAL exclusionsRule [3] EXPLICIT SEQUENCE OF UserCAPair OPTIONAL
} }
Permission ::= CHOICE { Permission ::= CHOICE {
simplePermission [1] SimplePermission simplePermission [1] SimplePermission
} }
skipping to change at page 24, line 25 skipping to change at page 24, line 14
rekey protocol: rekey protocol:
id-GSAKMPv1Rekey OBJECT IDENTIFIER::= {TBD} id-GSAKMPv1Rekey OBJECT IDENTIFIER::= {TBD}
The GSAKMP Rekey Policy provides authorization information, The GSAKMP Rekey Policy provides authorization information,
mechanisms for the GSAKMP Rekey messages, indicators defining rekey mechanisms for the GSAKMP Rekey messages, indicators defining rekey
event definitions that define when the GC/KS should send a rekey event definitions that define when the GC/KS should send a rekey
message, the protocol or method the rekey event will use, the rekey message, the protocol or method the rekey event will use, the rekey
interval that will allow a member to recognize a failure in the rekey interval that will allow a member to recognize a failure in the rekey
process, a reliability indicator that defines the method the rekey process, a reliability indicator that defines the method the rekey
will use to increase the likelyhood of a rekey delivery (if any), and will use to increase the likelihood of a rekey delivery (if any), and
finally an indication of how subordinate-GC/KSs will handle rekey. finally an indication of how subordinate-GC/KSs will handle rekey.
This policy also describes the specific Rekey policy methods "None" This policy also describes the specific Rekey policy methods "None"
and "GSAKMP LKH REKEY". and "GSAKMP LKH REKEY".
GSAKMPv1RekeyInfo ::= SEQUENCE { GSAKMPv1RekeyInfo ::= SEQUENCE {
authorization RekeyAuthorization, authorization RekeyAuthorization,
mechanism RekeyMechanisms, mechanism RekeyMechanisms,
rekeyEventDef RekeyEventDef, -- tells the GCKS when to rekey rekeyEventDef RekeyEventDef,
rekeyMethod RekeyMethod, rekeyMethod RekeyMethod,
rekeyInterval LifeDate, -- member knows when to rejoin rekeyInterval LifeDate,
reliability Reliability, -- what mech will be used to reliability Reliability,
-- increase the likelihood subGCKSInfo SubGCKSInfo
-- of rekey delivery
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 The policy dictating the mechanisms needed for Rekey message
processing is defined by RekeyMechanisms. This field is specified processing is defined by RekeyMechanisms. This field is specified
skipping to change at page 25, line 41 skipping to change at page 25, line 29
or 24 hours, which ever comes first). 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 The LifeDate specifies the maximum time a group should exist between
rekeys. This does not require clock synchronization as this is used rekeys. This does not require clock synchronization as this is
with respect to a local clock. used with respect to a local clock. (GC/KS clock for sending rekey
messages or member clock for determining whether a message has been
missed.)
The INTEGER corresponding to the event is an indicator of the number The INTEGER corresponding to the event is an indicator of the number
of events a group should sustain before a rekey message is sent. of events a group should sustain before a rekey message is sent.
This defines the events between rekeys. An example of a relevant This defines the events between rekeys. An example of a relevant
event is de-registration notifications. event is de-registration notifications.
The TimeAndEvent is defined as a couple of the LifeDate and Integer The TimeAndEvent is defined as a couple of the LifeDate and Integer
policies. policies.
TimeAndEvent ::= SEQUENCE { TimeAndEvent ::= SEQUENCE {
time LifeDate, -- rekey after x units of time OR time LifeDate, -- rekey after x units of time OR
event INTEGER -- x events occur event INTEGER -- x events occur
} }
B.5.4 Rekey Methods B.5.4 Rekey Methods
The policy dictating the rekey method supported by the Rekey message Rekey Method defines the policy of how the rekey is to be
is defined by RekeyMethod. This field is specified as accomplished. This field is specified as
RekeyMethod ::= SEQUENCE { RekeyMethod ::= SEQUENCE {
rekeyMethodType OBJECT IDENTIFIER, rekeyMethodType OBJECT IDENTIFIER,
rekeyMethodInfo OCTET STRING rekeyMethodInfo OCTET STRING
} }
The rekeyMethodType will define the rekey method to be used by the The rekeyMethodType will define the rekey method to be used by the
group. group.
The rekeyMethodInfo will supply the GMs with the information they The rekeyMethodInfo will supply the GMs with the information they
skipping to change at page 27, line 22 skipping to change at page 27, line 14
B.5.5 Rekey Interval B.5.5 Rekey Interval
Rekey interval defines the maximum delay the GM should see Rekey interval defines the maximum delay the GM should see
between valid rekeys. This provides a means to ensure the GM is between valid rekeys. This provides a means to ensure the GM is
synchronized, from a key management perspective, with the rest of the synchronized, from a key management perspective, with the rest of the
group. It is defined as a time/date stamp. group. It is defined as a time/date stamp.
B.5.6 Rekey Reliability B.5.6 Rekey Reliability
The Rekey message in the GSAKMP protocol is a one sided exchange The Rekey message in the GSAKMP protocol is a single push message.
of data. There are reliability concerns with one sided exchanges. There are reliability concerns with such non-acknowledged messages
The Reliability policy defines the mechanism used to deal with these (i.e. message exchange). The Reliability policy defines the
concerns. mechanism used to deal with these concerns.
Reliability ::= SEQUENCE { Reliability ::= SEQUENCE {
reliabilityMechanism OBJECT IDENTIFIER, reliabilityMechanism OBJECT IDENTIFIER,
reliabilityMechContent OCTET STRING reliabilityMechContent OCTET STRING
} }
The reliability mechanism is defined by an OBJECT IDENTIFIER and The reliability mechanism is defined by an OBJECT IDENTIFIER and
the 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)
skipping to change at page 28, line 22 skipping to change at page 28, line 14
id-reliabilityResend OBJECT IDENTIFIER ::= {TBD} id-reliabilityResend OBJECT IDENTIFIER ::= {TBD}
ReliabilityResendInfo ::= INTEGER ReliabilityResendInfo ::= INTEGER
The INTEGER value in the ReliabilityResendInfo indicates the number The INTEGER value in the ReliabilityResendInfo indicates the number
of times the message should be resent. of times the message should be resent.
B.5.6.3 Rekey Reliability Mechanism Post B.5.6.3 Rekey Reliability Mechanism Post
Another reliability mechanims is to post the rekey message on Another reliability mechanism is to post the rekey message on
some service that will make it generally available. This is the some service that will make it generally available. This is the
reliabilityPost method. 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 IA5String associated with ReliabilityPost is the identifier of
the posting site and rekey message. the posting site and rekey message.
skipping to change at page 30, line 4 skipping to change at page 29, line 41
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 reliability Reliability, -- what mech will be used to
-- increase the likelyhood -- increase the likelihood
-- of rekey delivery -- of rekey delivery
subGCKSInfo SubGCKSInfo -- what subordinate gcks needs subGCKSInfo SubGCKSInfo -- what subordinate gcks needs
} }
RekeyAuthorization ::= GCKSName RekeyAuthorization ::= GCKSName
RekeyMechanisms ::= SEQUENCE { RekeyMechanisms ::= SEQUENCE {
sigAlgorithm INTEGER, sigAlgorithm INTEGER,
hashAlgorithm INTEGER hashAlgorithm INTEGER
} }
skipping to change at page 32, line 12 skipping to change at page 32, line 21
only that keys delivered by the registration and rekey protocols be only that keys delivered by the registration and rekey protocols be
mapped to the service using them. mapped to the service using them.
C.1 Generic Data Policy C.1 Generic Data Policy
The Generic Data Policy has the following identifier: The Generic Data Policy has the following identifier:
id-genericDataSA OBJECT IDENTIFIER :: = TBD id-genericDataSA OBJECT IDENTIFIER :: = TBD
If an authentication mechanism is used within the security If an authentication mechanism is used within the security
application, the key identifier used in the key management protocol application, the key identifier (kMKeyID) used in the key management
is given, as well as an optional key expiration date. Likewise, protocol is given, as well as an optional key expiration date.
if an encryption mechanism is used within the security application, Likewise, if an encryption mechanism is used within the security
the encryption key identifier is given, as well as an optional key application, the encryption key identifier is given, as well as an
expiration date. optional key expiration date (keyExpirationDate).
GenericDataSAInfo ::= SEQUENCE { GenericDataSAInfo ::= SEQUENCE {
authentication [0] KeyInfo OPTIONAL, authentication [0] EXPLICIT KeyInfo OPTIONAL,
encryption [1] KeyInfo OPTIONAL encryption [1] EXPLICIT KeyInfo OPTIONAL
} }
KeyInfo ::= SEQUENCE{ KeyInfo ::= SEQUENCE{
kMKeyID OCTET STRING, kMKeyID OCTET STRING,
keyExpirationDate LifeDate OPTIONAL keyExpirationDate LifeDate OPTIONAL
} }
C.2 Generic Data Policy ASN.1 Module C.2 Generic Data Policy ASN.1 Module
GenericDataSA -- {TBD} GenericDataSA -- {TBD}
skipping to change at page 33, line 9 skipping to change at page 33, line 31
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) security(5) mechanisms(5) pkix(7) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit(19) }; id-mod(0) id-pkix1-implicit(19) };
-- id-genericDataSA OBJECT IDENTIFIER ::= {TBD} -- id-genericDataSA OBJECT IDENTIFIER ::= {TBD}
GenericDataSAInfo ::= SEQUENCE { GenericDataSAInfo ::= SEQUENCE {
authentication [0] KeyInfo OPTIONAL, authentication [0] EXPLICIT KeyInfo OPTIONAL,
encryption [1] KeyInfo OPTIONAL encryption [1] EXPLICIT KeyInfo OPTIONAL
} }
KeyInfo ::= SEQUENCE{ KeyInfo ::= SEQUENCE{
kMKeyID OCTET STRING, kMKeyID OCTET STRING,
keyExpirationDate LifeDate OPTIONAL keyExpirationDate LifeDate OPTIONAL
} }
END END
D APPENDIX D -- Change History (To Be Removed from RFC) D APPENDIX D -- Change History (To Be Removed from RFC)
skipping to change at page 33, line 44 skipping to change at page 34, line 19
- 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.
D.3 Changes from Group Policy Token v-02 to v-03, July 2005 D.3 Changes from Group Policy Token v-02 to v-03, July 2005
- Consistancy corrections between text and ASN.1 modules. - Consistency corrections between text and ASN.1 modules.
- Explicit tagging in sequences of sequences to avoid encoding - Explicit tagging in sequences of sequences to avoid encoding
ambiguities. ambiguities.
D.4 Changes from Group Policy Token v-03 to v-04, September 2005
- Authorization field for group senders.
- Editorial corrections.
- Renamed to "Group Security Policy Token".
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
skipping to change at page 36, line 18 skipping to change at page 36, 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: January 7, 2006 Document expiration: March 30, 2006
 End of changes. 71 change blocks. 
119 lines changed or deleted 163 lines changed or added

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