draft-ietf-msec-gspt-01.txt   draft-ietf-msec-gspt-02.txt 
Internet Research Task Force Thomas Hardjono (VeriSign) Internet Research Task Force Thomas Hardjono (VeriSign)
INTERNET-DRAFT Hugh Harney (Sparta) INTERNET-DRAFT Hugh Harney (Sparta)
draft-ietf-msec-gspt-01.txt Pat McDaniel (U. Michigan) draft-ietf-msec-gspt-02.txt Pat McDaniel (U. Michigan)
Andrea Colgrove (Sparta) Andrea Colgrove (Sparta)
Pete Dinsmore (NAI) Pete Dinsmore (NAI)
14 November 2001 Expires June 2002 18 August 2003 Expires December 2003
Group Security Policy Token The MSEC Group Security Policy Token
<draft-ietf-msec-gspt-01.txt> <draft-ietf-msec-gspt-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
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 that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at line 53 skipping to change at line 53
1. Introduction 1. Introduction
Group communications, also commonly called multicast, refers to Group communications, also commonly called multicast, refers to
communications in a group where the messages can be sent by any member communications in a group where the messages can be sent by any member
and are received by all members. The applications and encryption can be and are received by all members. The applications and encryption can be
implemented in a variety of ways and at numerous levels on the network implemented in a variety of ways and at numerous levels on the network
stack. They range from mailing lists to conference calls to IP stack. They range from mailing lists to conference calls to IP
Multicasting. Often the need for data protection arises, which requires Multicasting. Often the need for data protection arises, which requires
the group to handle the messages in a consistently secure manner. To the group to handle the messages in a consistently secure manner. To
Group Security Policy Token [PAGE 1] MSEC Policy Token [PAGE 1]
accomplish this, cryptographic mechanisms and security policy must be accomplish this, cryptographic mechanisms and security policy must be
shared and supported by the group as a whole. Because of this, special shared and supported by the group as a whole. Because of this, special
problems arise in managing the cryptographic and policy material as it problems arise in managing the cryptographic and policy material as it
changes or as the group changes. changes or as the group changes.
2. Framework for Group Security Policy 2. Framework for Group Security Policy
Group Security Policy represents an important building block within the Group Security Policy represents an important building block within the
Secure Multicast Group Framework of [HCBD00]. The Framework of [HCBD00] Secure Multicast Group Framework of [HCBD00]. The Framework of [HCBD00]
skipping to change at line 101 skipping to change at line 101
| v +--------+ | | | | v +--------+ | | |
| +------+ ^ | V | | +------+ ^ | V |
| | | | | +--------+ | | | | | | +--------+ |
| |Sender|<---------+ | | | | | |Sender|<---------+ | | | |
| | |<--------------------- |------>|Receiver| | | | |<--------------------- |------>|Receiver| |
| | | | | | | | | | | | | |
| +------+ | +--------+ | | +------+ | +--------+ |
+---------------------------------------------------------+ +---------------------------------------------------------+
FIGURE 1: Secure Multicast Group Reference Framework FIGURE 1: Secure Multicast Group Reference Framework
Group Security Policy Token [PAGE 2] MSEC Policy Token [PAGE 2]
Figure 1 shows the Secure Multicast Group Reference Framework of Figure 1 shows the Secure Multicast Group Reference Framework of
functional entities and the interfaces between them [HCBD00]. These functional entities and the interfaces between them [HCBD00]. These
entities and interfaces implement a secure group, which is defined as a entities and interfaces implement a secure group, which is defined as a
group of principals that share a secret. Secure groups are needed by group of principals that share a secret. Secure groups are needed by
unicast applications as well as multicast applications (single-source unicast applications as well as multicast applications (single-source
and multiple-source). The framework of Figure 1 identifies three group and multiple-source). The framework of Figure 1 identifies three group
key management entities, namely the "Group Controller and Key Server" key management entities, namely the "Group Controller and Key Server"
(GCKS) and two types of Members ("Receiver" and "Sender"). The GCKS (GCKS) and two types of Members ("Receiver" and "Sender"). The GCKS
entity embodies both the physical entity and functions of the group entity embodies both the physical entity and functions of the group
skipping to change at line 151 skipping to change at line 151
>From the perspective of access control to information about the group, >From the perspective of access control to information about the group,
the Group Owner determines pieces of information that are accessible the Group Owner determines pieces of information that are accessible
service-entities (such as GCKS and Policy Repositories), group members service-entities (such as GCKS and Policy Repositories), group members
and external entities. To this end, the Group Owner also decides form and external entities. To this end, the Group Owner also decides form
and content of group announcements made through the appropriate and content of group announcements made through the appropriate
announcement protocols. Such information may consists of certain parts announcement protocols. Such information may consists of certain parts
of the Policy Token or the entire Policy Token itself. Similarly, the of the Policy Token or the entire Policy Token itself. Similarly, the
Group Owner determines the information pertaining to a group that is Group Owner determines the information pertaining to a group that is
stored in the Policy Repository. stored in the Policy Repository.
Group Security Policy Token [PAGE 3] MSEC Policy Token [PAGE 3]
+---------------------------------------------------------+ +---------------------------------------------------------+
| | | |
| +-------------+ | | +-------------+ |
| | Group | | | | Group | |
| |----------->|Announcement |------------| | | |----------->|Announcement |------------| |
| | +-------------+ | | | | +-------------+ | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
skipping to change at line 197 skipping to change at line 197
An important aspect of secure group communications is the availability An important aspect of secure group communications is the availability
of enough information for potential newcomers to decide as to whether of enough information for potential newcomers to decide as to whether
they have sufficient permissions and suitable resources (e.g. crypto they have sufficient permissions and suitable resources (e.g. crypto
ability) to join the group. ability) to join the group.
The level of availability of such information is highly-dependent on the The level of availability of such information is highly-dependent on the
specific application employing secure groups. In some applications, all specific application employing secure groups. In some applications, all
the required permissions and resources maybe pre-published in a the required permissions and resources maybe pre-published in a
publicly-available location, protected using the group owner's digital publicly-available location, protected using the group owner's digital
Group Security Policy Token [PAGE 4] MSEC Policy Token [PAGE 4]
signature. In other applications, perhaps only limited information is signature. In other applications, perhaps only limited information is
published (e.g. required certificate-class of newcomer) to allow published (e.g. required certificate-class of newcomer) to allow
newcomers to decide whether or not to pursue further the act of joining newcomers to decide whether or not to pursue further the act of joining
the group. the group.
In this document, we do not address the issue of which parts of the In this document, we do not address the issue of which parts of the
Group Policy Token are announced or be published to prospective Group Policy Token are announced or be published to prospective
newcomers. newcomers.
skipping to change at line 246 skipping to change at line 246
A Group Security Policy must identify the entities allowed to perform A Group Security Policy must identify the entities allowed to perform
actions that affect group members. Group authorization partially actions that affect group members. Group authorization partially
determines the trust embodied by the group as a whole, by defining the determines the trust embodied by the group as a whole, by defining the
parties or entities that are allowed to participate in group activities. parties or entities that are allowed to participate in group activities.
Because of the wide range of expected environments, flexible Because of the wide range of expected environments, flexible
identification of entity authorizations is highly desirable. identification of entity authorizations is highly desirable.
Authorization given to an entity must be shown as being true and Authorization given to an entity must be shown as being true and
authentic coming from another entity that bequeathed that authority. authentic coming from another entity that bequeathed that authority.
Group Security Policy Token [PAGE 5] MSEC Policy Token [PAGE 5]
c. Access Control to Group Information c. Access Control to Group Information
Access control policy defines the entities that will have authorization Access control policy defines the entities that will have authorization
to hold the key protecting the group data. to hold the key protecting the group data.
d. Mechanisms for Group Security Services d. Mechanisms for Group Security Services
Identification of the security services used to support group Identification of the security services used to support group
communication is required. For example, policy must state the algorithms communication is required. For example, policy must state the algorithms
skipping to change at line 294 skipping to change at line 294
control policies governing the group, the mechanisms supporting secure control policies governing the group, the mechanisms supporting secure
communications, and the authentication of the contents of the token. communications, and the authentication of the contents of the token.
--------------------------------------------------------------------- ---------------------------------------------------------------------
| | | | | | | | | | | |
|Token ID | Authorization | Access Control | Mechanisms | Signature | |Token ID | Authorization | Access Control | Mechanisms | Signature |
| | | | | | | | | | | |
--------------------------------------------------------------------- ---------------------------------------------------------------------
Figure 3: Group Policy Token Overall Structure Figure 3: Group Policy Token Overall Structure
Group Security Policy Token [PAGE 6] MSEC Policy Token [PAGE 6]
Each of the fields of the GSAKMP Policy Token is further expanded in Each of the fields of the GSAKMP Policy Token is further expanded in
following sections. The specific data formats can be seen in the ASN.1 following sections. The specific data formats can be seen in the ASN.1
Policy Token Specification in Appendix A. Policy Token Specification in Appendix A.
4.1 Token ID Field and Sub-Fields 4.1 Token ID Field and Sub-Fields
The Token ID Field explicitly identifies the protocol family to which The Token ID Field explicitly identifies the protocol family to which
the Group Policy Token belongs (e.g. GSAKMP, GDOI). The Token ID Field the Group Policy Token belongs (e.g. GSAKMP, GDOI). The Token ID Field
consists of a Version number indicating Token version, Protocol ID consists of a Version number indicating Token version, Protocol ID
skipping to change at line 348 skipping to change at line 348
policy rule might state that anyone in a particular domain except two policy rule might state that anyone in a particular domain except two
people is authorized to act as a Key Server. Such a rule might be stated people is authorized to act as a Key Server. Such a rule might be stated
as "include {/o=acme/ou=responsible}, not {/o=acme/ou=responsible/s=bob, as "include {/o=acme/ou=responsible}, not {/o=acme/ou=responsible/s=bob,
{/o=acme/ou=responsible/s= ted}." {/o=acme/ou=responsible/s= ted}."
The Re-Key GCKS is included to cater for situations in which a back-up The Re-Key GCKS is included to cater for situations in which a back-up
GCKS (other than then one the member initially joined to) is specified GCKS (other than then one the member initially joined to) is specified
to handle emergency situations (e.g. Primary GCKS crashed, network to handle emergency situations (e.g. Primary GCKS crashed, network
partitions, etc). partitions, etc).
Group Security Policy Token [PAGE 7] MSEC Policy Token [PAGE 7]
Authorization Fields will fulfill various needs during the lifetime of a Authorization Fields will fulfill various needs during the lifetime of a
group. Both new and current members will need to make use of the group. Both new and current members will need to make use of the
authorization field to maintain the level of security of the authorization field to maintain the level of security of the
communications group. communications group.
For new or potential members, this field of the group's token should be For new or potential members, this field of the group's token should be
used as input into the decision for joining a particular group and for used as input into the decision for joining a particular group and for
the acceptance of keying material. Specifically, the rules should be the acceptance of keying material. Specifically, the rules should be
examined to determine whether they are stringent enough for the examined to determine whether they are stringent enough for the
skipping to change at line 399 skipping to change at line 399
permission to receive an appropriate subset of the group's keys. This is permission to receive an appropriate subset of the group's keys. This is
explicitly stated in the policy token to ensure a common access decision explicitly stated in the policy token to ensure a common access decision
space. space.
The Access Field defines who is permitted to join the group. As with The Access Field defines who is permitted to join the group. As with
authorizations, access controls can be defined by a combination of rules authorizations, access controls can be defined by a combination of rules
and explicit names. The rules portion of the Access Field is broken and explicit names. The rules portion of the Access Field is broken
down into a set of permissions that determine access into a group and down into a set of permissions that determine access into a group and
the definition (or pointer to the definition) of those permissions for a the definition (or pointer to the definition) of those permissions for a
Group Security Policy Token [PAGE 8] MSEC Policy Token [PAGE 8]
particular information domain. The Permissions are hierarchical in the particular information domain. The Permissions are hierarchical in the
traditional military sense where access at a higher level encompasses traditional military sense where access at a higher level encompasses
all the access of the lower levels plus new ones and dominance rules all the access of the lower levels plus new ones and dominance rules
apply. The Access List can also restrict access to those in a apply. The Access List can also restrict access to those in a
particular knowledge group or groups. particular knowledge group or groups.
As an example of how the Access Field might be filled, consider a As an example of how the Access Field might be filled, consider a
hypothetical group consisting of scientists with research and hypothetical group consisting of scientists with research and
development permissions working on the company's new product . development permissions working on the company's new product .
skipping to change at line 451 skipping to change at line 451
The three Categories of SAs (REF[2]) are described in this field. The three Categories of SAs (REF[2]) are described in this field.
The Category-1 SA defines the information for a newcomer to join the The Category-1 SA defines the information for a newcomer to join the
group by opening a secure channel to the GCKS. The secure channel group by opening a secure channel to the GCKS. The secure channel
establishment requirements and parameters are described in the Category- establishment requirements and parameters are described in the Category-
1 SA sub-field. 1 SA sub-field.
The Category-2 SA (or Re-Key SA) describes the Security Association that The Category-2 SA (or Re-Key SA) describes the Security Association that
will be used by the GCKS to perform a re-key of the group-key (TEK will be used by the GCKS to perform a re-key of the group-key (TEK
Group Security Policy Token [PAGE 9] MSEC Policy Token [PAGE 9]
and/or KEK vector) within the group. This sub-field is actually broken and/or KEK vector) within the group. This sub-field is actually broken
down into further fields: Protected Key Management and Bypass. The down into further fields: Protected Key Management and Bypass. The
Protected Key Management SA identifies the security mechanisms set up Protected Key Management SA identifies the security mechanisms set up
for key management messages. For cases in which Protected Key for key management messages. For cases in which Protected Key
Management messages cannot be correctly received and read by all Management messages cannot be correctly received and read by all
members, the Bypass SA will allow particular messages through without members, the Bypass SA will allow particular messages through without
confidentiality processing. Both of these correspond to the Category-2 confidentiality processing. Both of these correspond to the Category-2
SA (Re-Key SA) of the MSEC Key Management Architecture (GKM Arch [REF]). SA (Re-Key SA) of the MSEC Key Management Architecture (GKM Arch [REF]).
skipping to change at line 497 skipping to change at line 497
Because of this, any unauthorized change in the group policy token will Because of this, any unauthorized change in the group policy token will
invalidate the signature. invalidate the signature.
-------------------------------------------------- --------------------------------------------------
| | | | | | | |
| Signer ID | Certificate-Info | Signature-Data | | Signer ID | Certificate-Info | Signature-Data |
| | | | | | | |
-------------------------------------------------- --------------------------------------------------
Figure 8: Signature Sub-Fields Figure 8: Signature Sub-Fields
Group Security Policy Token [PAGE 10] MSEC Policy Token [PAGE 10]
5. Group Policy Token: Header and Payloads 5. Group Policy Token: Header and Payloads
5.1 Generic Payload Header 5.1 Generic Payload Header
Each payload defined in the following sections begins with a generic Each payload defined in the following sections begins with a generic
header, shown in Figure 3, which provides a payload ``chaining`` header, shown in Figure 3, which provides a payload ``chaining``
capability and clearly defines the boundaries of a payload. The Generic capability and clearly defines the boundaries of a payload. The Generic
Payload Header fields are defined as follows: Payload Header fields are defined as follows:
skipping to change at line 544 skipping to change at line 544
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length ! ! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! ID Type ! Policy Token Data ~ ! ID Type ! Policy Token Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
Figure 4: Policy Token Payload Format Figure 4: Policy Token Payload Format
Group Security Policy Token [PAGE 11] MSEC Policy Token [PAGE 11]
The Policy Token Payload fields are defined as follows: The Policy Token Payload fields are defined as follows:
Next Payload (1 octet) - Identifier for the payload type of the next Next Payload (1 octet) - Identifier for the payload type of the next
payload in the message. If the current payload is the last in the payload in the message. If the current payload is the last in the
message, then this field will be 0. message, then this field will be 0.
RESERVED (1 octet) - Unused, set to 0. RESERVED (1 octet) - Unused, set to 0.
Payload Length (2 octets) - Length in octets of the current payload, Payload Length (2 octets) - Length in octets of the current payload,
skipping to change at line 591 skipping to change at line 591
6.1 Description of Example 6.1 Description of Example
The this example the group security protocol (namely GSAKMP) creates an The this example the group security protocol (namely GSAKMP) creates an
association between multiple entities connected by the Internet. The association between multiple entities connected by the Internet. The
intent of the group security protocol is to use existing protocol- intent of the group security protocol is to use existing protocol-
services that are standardized for the Internet to facilitate setting up services that are standardized for the Internet to facilitate setting up
these secure groups. IPsec is one of the standard secure services that these secure groups. IPsec is one of the standard secure services that
can be used, though others (e.g. S/MIME or even SSL) can be used as a can be used, though others (e.g. S/MIME or even SSL) can be used as a
unicast security association mechanism. unicast security association mechanism.
Group Security Policy Token [PAGE 12] MSEC Policy Token [PAGE 12]
Additionally, the Group Policy Token defines the policy for protecting Additionally, the Group Policy Token defines the policy for protecting
the multicast data traffic (Category-3 SA). Once again, IPsec can be the multicast data traffic (Category-3 SA). Once again, IPsec can be
used to protect these messages, as can S/MIME. used to protect these messages, as can S/MIME.
In this particular example, IPsec is used as the underlying security In this particular example, IPsec is used as the underlying security
association protocol for both unicast (Cat-1) and multicast messages association protocol for both unicast (Cat-1) and multicast messages
(Cat-2 and Cat-3). (Cat-2 and Cat-3).
To configure IPsec, interaction will occur with the Security Policy To configure IPsec, interaction will occur with the Security Policy
skipping to change at line 643 skipping to change at line 643
incoming and outgoing packets. incoming and outgoing packets.
6.2.1 SPD Inputs 6.2.1 SPD Inputs
Purpose of the SPD (copied from RFC 2401): Purpose of the SPD (copied from RFC 2401):
"A security association is a management construct used to enforce "A security association is a management construct used to enforce
a security policy in the IPsec environment. Thus an essential a security policy in the IPsec environment. Thus an essential
element of SA processing is an underlying Security Policy Database element of SA processing is an underlying Security Policy Database
Group Security Policy Token [PAGE 13] MSEC Policy Token [PAGE 13]
(SPD) that specifies what services are to be offered to IP (SPD) that specifies what services are to be offered to IP
datagrams and in what fashion. The form of the database and its datagrams and in what fashion. The form of the database and its
interface are outside the scope of this specification. However, interface are outside the scope of this specification. However,
this section does specify certain minimum management functionality this section does specify certain minimum management functionality
that must be provided, to allow a user or system administrator to that must be provided, to allow a user or system administrator to
control how IPsec is applied to traffic transmitted or received by control how IPsec is applied to traffic transmitted or received by
a host or transiting a security gateway. a host or transiting a security gateway.
The SPD must be consulted during the processing of all traffic The SPD must be consulted during the processing of all traffic
skipping to change at line 695 skipping to change at line 695
Purpose of the SAD (copied from RFC 2401): Purpose of the SAD (copied from RFC 2401):
"In each IPsec implementation there is a nominal Security "In each IPsec implementation there is a nominal Security
Association Database, in which each entry defines the parameters Association Database, in which each entry defines the parameters
associated with one SA. Each SA has an entry in the SAD. For associated with one SA. Each SA has an entry in the SAD. For
outbound processing, entries are pointed to by entries in the SPD. outbound processing, entries are pointed to by entries in the SPD.
Note that if an SPD entry does not currently point to an SA that Note that if an SPD entry does not currently point to an SA that
is appropriate for the packet, the implementation creates an is appropriate for the packet, the implementation creates an
Group Security Policy Token [PAGE 14] MSEC Policy Token [PAGE 14]
appropriate SA (or SA Bundle) and links the SPD entry to the SAD appropriate SA (or SA Bundle) and links the SPD entry to the SAD
entry (see Section 5.1.1). For inbound processing, each entry in entry (see Section 5.1.1). For inbound processing, each entry in
the SAD is indexed by a destination IP address, IPsec protocol the SAD is indexed by a destination IP address, IPsec protocol
type, and SPI. The following parameters are associated with each type, and SPI. The following parameters are associated with each
entry in the SAD. This description does not purport to be a MIB, entry in the SAD. This description does not purport to be a MIB,
but only a specification of the minimal data items required to but only a specification of the minimal data items required to
support an SA in an IPsec implementation." support an SA in an IPsec implementation."
The critical elements of the SAD are The critical elements of the SAD are
skipping to change at line 746 skipping to change at line 746
There are several messages that need to be configured into IPsec SPDs. There are several messages that need to be configured into IPsec SPDs.
There is a need for some key management messages to bypass IPsec There is a need for some key management messages to bypass IPsec
processing. These messages are self-protecting or do not require processing. These messages are self-protecting or do not require
protection. During the process of establishing the group there are protection. During the process of establishing the group there are
unicast messages between the key servers and the members -- these unicast messages between the key servers and the members -- these
messages may be sensitive in nature and require IPsec processing. Once messages may be sensitive in nature and require IPsec processing. Once
a group has been established, there are messages that manage the group a group has been established, there are messages that manage the group
as a single entity, some these messages (LKH rekey [10]) are self as a single entity, some these messages (LKH rekey [10]) are self
Group Security Policy Token [PAGE 15] MSEC Policy Token [PAGE 15]
protecting and do not need IPsec, but other management messages like protecting and do not need IPsec, but other management messages like
policy updating or group deletion may be sensitive and need IPsec policy updating or group deletion may be sensitive and need IPsec
protection. Finally, the group key that is protecting the application protection. Finally, the group key that is protecting the application
data, separate from GSAKMP data will need IPsec processing. In each of data, separate from GSAKMP data will need IPsec processing. In each of
these instances, the group policy token will carry the configuration these instances, the group policy token will carry the configuration
information needed to configure their SPD and SAD. information needed to configure their SPD and SAD.
There is an enumerated example policy token that follows this section. There is an enumerated example policy token that follows this section.
We have included the field numbers from that example into the following We have included the field numbers from that example into the following
skipping to change at line 797 skipping to change at line 797
6.5 Category-1 SA 6.5 Category-1 SA
During the initial Regsitration phase between a newcomer/group member During the initial Regsitration phase between a newcomer/group member
and the GCKS, sensitive information will be exchanged. and the GCKS, sensitive information will be exchanged.
The group policy token example will specify the exact IPsec services The group policy token example will specify the exact IPsec services
that are required between key server and group member. It will also that are required between key server and group member. It will also
specify the key creation parameters that satisfy the group data security specify the key creation parameters that satisfy the group data security
requirements. requirements.
Group Security Policy Token [PAGE 16] MSEC Policy Token [PAGE 16]
In this example, we assumed the use of IKE as the key creation and In this example, we assumed the use of IKE as the key creation and
negotiation protocol. The group policy token will specify the correct negotiation protocol. The group policy token will specify the correct
IKE parameters for the group. IKE will create the pairwise key and IKE parameters for the group. IKE will create the pairwise key and
assign an appropriate SPI. assign an appropriate SPI.
Two SPDs are required to completely specify this interaction -- one for Two SPDs are required to completely specify this interaction -- one for
inbound messages in one for outbound messages. inbound messages in one for outbound messages.
Of special note: the standard selectors for IPsec are inadequate to Of special note: the standard selectors for IPsec are inadequate to
skipping to change at line 848 skipping to change at line 848
AH Authentication algo., AH Authentication algo.,
keys, etc. [REQUIRED keys, etc. [REQUIRED
for AH implementations] n/a n/a for AH implementations] n/a n/a
ESP Encryption algorithm, ESP Encryption algorithm,
keys, IV mode, IV, etc. keys, IV mode, IV, etc.
[REQUIRED for ESP [REQUIRED for ESP
implementations] From (73), IKE keys From (52), IKE keys implementations] From (73), IKE keys From (52), IKE keys
Group Security Policy Token [PAGE 17] MSEC Policy Token [PAGE 17]
ESP authentication alg., ESP authentication alg.,
keys, etc [REQUIRED for keys, etc [REQUIRED for
ESP implementations] From (74), IKE keys From (53), IKE keys ESP implementations] From (74), IKE keys From (53), IKE keys
Lifetime of this Security Lifetime of this Security
Association: Required From (76) From (55) Association: Required From (76) From (55)
IPsec protocol mode: IPsec protocol mode:
tunnel, transport or tunnel, transport or
wildcard From (75) From (54) wildcard From (75) From (54)
skipping to change at line 896 skipping to change at line 896
Category 3 is the final set of IPsec configurations (SPD and SAD Category 3 is the final set of IPsec configurations (SPD and SAD
entries) used to protect the data traffic (nb. Hence also called "Data entries) used to protect the data traffic (nb. Hence also called "Data
Security SA"). Here, it is assumed that Ipsec will be used to protect Security SA"). Here, it is assumed that Ipsec will be used to protect
the data. the data.
The group policy token will specify the IPsec parameters that are needed The group policy token will specify the IPsec parameters that are needed
to protect the data. A group Security Parameter Index (SPI) will be to protect the data. A group Security Parameter Index (SPI) will be
created and distributed across the entire group. created and distributed across the entire group.
Group Security Policy Token [PAGE 18] MSEC Policy Token [PAGE 18]
Cat-3 SPDs Outgoing Incoming Cat-3 SPDs Outgoing Incoming
---------------------- -------------- -------------- ---------------------- -------------- --------------
Destination IP Addr. From (32) From (45) Destination IP Addr. From (32) From (45)
Source IP Addr. From (31) From (44) Source IP Addr. From (31) From (44)
Name From (34) From (47) Name From (34) From (47)
Data sensitivity level From (35) From (48) Data sensitivity level From (35) From (48)
Transport Layer Protocol From (33) From (46) Transport Layer Protocol From (33) From (46)
Src & Dest Ports Src: */Dest:* Src: */Dest:* mask Src & Dest Ports Src: */Dest:* Src: */Dest:* mask
protocol bypass protocol bypass
Specific IPsec processing IPsec process IPsec process Specific IPsec processing IPsec process IPsec process
skipping to change at line 944 skipping to change at line 944
ESP implementations] From (27) From (40) ESP implementations] From (27) From (40)
Keys from Cat-1 Keys from Cat-1 Keys from Cat-1 Keys from Cat-1
Lifetime of this Security Lifetime of this Security
Association: Required From (29, 30) From (42, 43) Association: Required From (29, 30) From (42, 43)
IPsec protocol mode: IPsec protocol mode:
tunnel, transport or tunnel, transport or
wildcard From (28) From (41) wildcard From (28) From (41)
Group Security Policy Token [PAGE 19] MSEC Policy Token [PAGE 19]
Path MTU: [REQUIRED for ? ? Path MTU: [REQUIRED for ? ?
all implementations but all implementations but
used only for outbound used only for outbound
traffic] traffic]
6.8 A Complete Group Policy Token 6.8 A Complete Group Policy Token
In the following, the complete group policy token is presented, parts In the following, the complete group policy token is presented, parts
from which have been presented in then precious three subsections above. from which have been presented in then precious three subsections above.
skipping to change at line 992 skipping to change at line 992
(15) Rekey GCKS Distinguished Name C=US/ST=MD/L=Columbia/ (15) Rekey GCKS Distinguished Name C=US/ST=MD/L=Columbia/
O=SPARTA,Inc./ O=SPARTA,Inc./
CN = Johnny Member CN = Johnny Member
(16) Certificate Type X.509v3-DSS-SHA1 (16) Certificate Type X.509v3-DSS-SHA1
(17) Key Length 1024 (17) Key Length 1024
(18) Root CA C=US/ST=MD/L=Columbia/ (18) Root CA C=US/ST=MD/L=Columbia/
O=SPARTA,Inc./ O=SPARTA,Inc./
CN =John Root CN =John Root
Group Security Policy Token [PAGE 20] MSEC Policy Token [PAGE 20]
ACCESS CONTROL FIELD ACCESS CONTROL FIELD
(19) Permissions employee, projectA (19) Permissions employee, projectA
(20) Access List Distinguished Name C=US/ST=MD/L=Columbia/ (20) Access List Distinguished Name C=US/ST=MD/L=Columbia/
O=SPARTA,Inc./CN = * O=SPARTA,Inc./CN = *
(21) Certificate Type X.509v3-DSS-SHA1 (21) Certificate Type X.509v3-DSS-SHA1
(22) Key Length 1024 (22) Key Length 1024
(23) Root CA C=US/ST=MD/L=Columbia/ (23) Root CA C=US/ST=MD/L=Columbia/
O=SPARTA,Inc./ O=SPARTA,Inc./
CN =John Root CN =John Root
skipping to change at line 1044 skipping to change at line 1044
(51) Processing Direction Incoming (51) Processing Direction Incoming
(52) ESP Algorithm ESP-DES (52) ESP Algorithm ESP-DES
(53) ESP Authentication HMAC-SHA (53) ESP Authentication HMAC-SHA
(54) Encapsulation Mode Tunnel (54) Encapsulation Mode Tunnel
(55) SA Lifetype seconds (55) SA Lifetype seconds
(56) SA Lifelength 1000 (56) SA Lifelength 1000
(57) Source Addr * (except multicast) (57) Source Addr * (except multicast)
(58) Destination Addr self (58) Destination Addr self
(59) Transport Protocol TCP (59) Transport Protocol TCP
Group Security Policy Token [PAGE 21] MSEC Policy Token [PAGE 21]
(60) Destination Port 555 (GSAKMP) (60) Destination Port 555 (GSAKMP)
(61) GroupID 224.0.1, 12345678 (61) GroupID 224.0.1, 12345678
(62) Security Label Reference [7] (62) Security Label Reference [7]
(63) Key Creation IKE (63) Key Creation IKE
(64) IKE Encr. Algorithm DES-CBC (64) IKE Encr. Algorithm DES-CBC
(65) IKE Hash Algorithm SHA (65) IKE Hash Algorithm SHA
(66) IKE Auth. Method DSS-Signature (66) IKE Auth. Method DSS-Signature
(67) IKE Group Desc. MODP-1024 (67) IKE Group Desc. MODP-1024
(68) IKE Group Type MODP (68) IKE Group Type MODP
skipping to change at line 1095 skipping to change at line 1095
(98) Hash SHA (98) Hash SHA
(99) Cat-2 Bypass Security Protocol IPsec None (99) Cat-2 Bypass Security Protocol IPsec None
(100) Processing Direction Incoming (100) Processing Direction Incoming
(101) Source Addr * (101) Source Addr *
(102) Destination Addr * (102) Destination Addr *
(103) Transport Protocol * (103) Transport Protocol *
(104) Destination Port 777 (104) Destination Port 777
(105) Processing BYPASS (105) Processing BYPASS
Group Security Policy Token [PAGE 22] MSEC Policy Token [PAGE 22]
(106) Security Protocol IPsec None (106) Security Protocol IPsec None
(107) Processing Direction Outgoing (107) Processing Direction Outgoing
(108) Source Addr self (108) Source Addr self
(109) Destination Addr * (109) Destination Addr *
(110) Transport Protocol * (110) Transport Protocol *
(111) Destination Port 777 (111) Destination Port 777
(112) Processing BYPASS (112) Processing BYPASS
SIGNATURE FIELD SIGNATURE FIELD
skipping to change at line 1145 skipping to change at line 1145
(1992), Kluwer Academic Publishers. (1992), Kluwer Academic Publishers.
[FS00] N. Ferguson and B. Schneier, A Cryptographic Evaluation of IPsec, [FS00] N. Ferguson and B. Schneier, A Cryptographic Evaluation of IPsec,
CounterPane, http://www.counterpane.com/ipsec.html. CounterPane, http://www.counterpane.com/ipsec.html.
[HCBD99] T. Hardjono, R. Canetti, M. Baugher, P. Disnmore, Secure IP [HCBD99] T. Hardjono, R. Canetti, M. Baugher, P. Disnmore, Secure IP
Multicast: Problem areas, Framework, and Building Blocks, Multicast: Problem areas, Framework, and Building Blocks,
http://www.ietf.org/internet-drafts/draft-irtf-smug-framework-00.txt, http://www.ietf.org/internet-drafts/draft-irtf-smug-framework-00.txt,
Work in Progress 1999. Work in Progress 1999.
Group Security Policy Token [PAGE 23] MSEC Policy Token [PAGE 23]
[HCD99] T. Hardjono, B. Cain, N. Doraswamy, A framework for group key [HCD99] T. Hardjono, B. Cain, N. Doraswamy, A framework for group key
management for multicast security, http://www.ietf.org/internet- management for multicast security, http://www.ietf.org/internet-
drafts/draft-ietf-ipsec-gkmframework-01.txt, July 1999, Work in drafts/draft-ietf-ipsec-gkmframework-01.txt, July 1999, Work in
Progress. Progress.
[HH99a] H. Harney, E. Harder, Multicast Security Management Protocol [HH99a] H. Harney, E. Harder, Multicast Security Management Protocol
(MSMP) Requirements and Policy, draft-harney-msmp-sec-00.txt, March (MSMP) Requirements and Policy, draft-harney-msmp-sec-00.txt, March
1999, Work in Progress. 1999, Work in Progress.
skipping to change at line 1197 skipping to change at line 1197
[RFC2522] P. Karn, W. Simpson, Photuris: Session-Key Management [RFC2522] P. Karn, W. Simpson, Photuris: Session-Key Management
Protocol, March 1999. Protocol, March 1999.
[RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for [RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for
Multicast: Issues and Architectures, September 1998. Multicast: Issues and Architectures, September 1998.
[SDNS88] H. L. Rogers, An Overview of the CANEWARE Program, 10th [SDNS88] H. L. Rogers, An Overview of the CANEWARE Program, 10th
National Security Conference, National Security Agency, 1988. National Security Conference, National Security Agency, 1988.
Group Security Policy Token [PAGE 24] MSEC Policy Token [PAGE 24]
[WL98] C.K.Wong, S.S. Lam, Digital Signatures for Flows and Multicasts, [WL98] C.K.Wong, S.S. Lam, Digital Signatures for Flows and Multicasts,
Proceedings of IEEE ICNP'98, October 14-16, 1998. Proceedings of IEEE ICNP'98, October 14-16, 1998.
Authors Address: Authors Address:
Thomas Hardjono Thomas Hardjono
VeriSign VeriSign
401 Edgewater Pl, Suite 280 401 Edgewater Pl, Suite 280
Wakefield, MA 01880, USA Wakefield, MA 01880, USA
skipping to change at line 1241 skipping to change at line 1241
+1 410 381 9400 (ext. 203) +1 410 381 9400 (ext. 203)
ac@columbia.sparta.com ac@columbia.sparta.com
Peter Dinsmore Peter Dinsmore
NAI Labs NAI Labs
3060 Washington Road, 3060 Washington Road,
Glenwood, MD 21738 Glenwood, MD 21738
(443) 259-2346 (443) 259-2346
Pete_Dinsmore@NAI.com Pete_Dinsmore@NAI.com
Group Security Policy Token [PAGE 26] MSEC Policy Token [PAGE 26]
 End of changes. 

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