SPARTA, Inc. H Harney (SPARTA)
INTERNET-DRAFT A Colegrove (SPARTA)
February 2003 P Lough (SPARTA)
U Meth (SPARTA)
GSAKMP Token Specification
draft-ietf-msec-tokenspec-sec-00.txt
Status of this memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress''.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Document expiration: August 31, 2003
Abstract
This document specifies the Group Secure Association Key Management
Protocol (GSAKMP) Policy Token. The Token provides a format to specify
a complete group security policy, necessary for formation of a group
secure association. The GSAKMP Token maintains procedures for key
dissemination, group membership, authorization and rekey.
Harney, Colegrove, Lough, Meth [Page 1]
Internet Draft GSAKMP Token Specification February 2003
Table of Contents
Status of this Memo..............................................1
Abstract.........................................................1
Table of Contents................................................2
1. Introduction..................................................4
2. GSAKMP Policy.................................................4
2.1. Identification..............................................5
2.1.1. Token ID..................................................5
2.1.1.1. Version.................................................5
2.1.1.2. Time Issued.............................................6
2.1.1.3. Protocol ID.............................................6
2.1.1.4. Group ID................................................6
2.2 Authorizations...............................................7
2.2.1. Owner Name ...............................................8
2.2.2. Rekey Controller Name.....................................8
2.2.3. Owner Name PKI............................................9
2.2.4. Rekey Controller Name PKI.................................10
2.2.5. Number of Key Server Authorizations.......................10
2.2.6. Key Server Authorization..................................11
2.3. Access Controls.............................................12
2.3.1. Inclusionary..............................................12
2.3.1.1. Permission..............................................12
2.3.1.2. Number of Name Rules....................................13
2.3.1.3. Name Rule...............................................13
2.3.1.4. Number of IP Rules......................................14
2.3.2. Exclusionary..............................................14
2.3.2.1. Permission..............................................14
2.3.2.2. Number of Name Rules ...................................14
2.3.2.3. Name Rule...............................................15
2.3.2.4. Number of IP Rules......................................16
2.4. Mechanisms..................................................16
2.4.1. Application SA............................................17
2.4.1.1. Encryption..............................................17
2.4.1.2. Rekey Information.......................................18
2.4.1.2.1. Frequency.............................................19
2.4.1.2.2. Rollover..............................................19
2.4.1.3. Group Specific Data.....................................20
2.4.1.3.1. IPSec Application Specific Data.......................20
2.4.1.3.1.1. Number of Secure Associations.......................20
2.4.1.3.1.2. Secure Associations.................................21
2.4.2. Unicast SA................................................23
2.4.2.1 Creation and Encryption..................................23
2.4.2.2 Rekey....................................................25
2.4.2.2.1. Frequency.............................................25
2.4.2.2.2. Rollover..............................................25
2.4.2.3. PKI.....................................................26
2.4.2.4. Signature...............................................26
2.4.3. Key Management SA.........................................27
2.4.3.1. Signature...............................................27
Harney, Colegrove, Lough, Meth [Page 2]
Internet Draft GSAKMP Token Specification February 2003
2.4.3.2. PKI.....................................................28
2.4.3.3. Rekey SA................................................28
2.4.3.3.1. Protocol and Encryption...............................28
2.4.3.3.2. Rekey.................................................29
2.4.3.3.2.1. Frequency...........................................30
2.4.3.3.2.2. Rollover............................................30
2.4.3.4. KEK SA..................................................31
2.4.3.4.1. p & g and Encryption..................................31
2.4.3.4.2. Rekey ................................................32
2.4.3.4.2.1. Frequency ..........................................32
2.4.3.4.2.2. Rollover............................................32
2.5. Signature...................................................33
2.5.1. Name......................................................33
2.5.2. PKI.......................................................33
2.5.3 Signature Data.............................................34
Acknowledgements.................................................35
References.......................................................35
Authors Address..................................................36
Appendix A ......................................................37
Harney, Colegrove, Lough, Meth [Page 3]
Internet Draft GSAKMP Token Specification February 2003
1. Introduction
Group communications, also commonly called multicast, refers to
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 implemented in a variety of ways and at numerous levels on the
network stack. Mailing list, conference calls and IP multicasting are
examples of group communication. Often the need for data protection
arises, which requires the group to handle the messages in a
consistently secure manner. To accomplish this, cryptographic
mechanisms and security policy must be shared and strictly followed by
the group as a whole. Because of this, special problems arise in
managing the cryptographic and policy material as it changes or as
the group changes.
The Group Secure Association Key Management Protocol (GSAKMP) [1] is
designed to manage these complex issues. GSAKMP provides symmetric key
to groups of users on a network. It provides mechanisms to disseminate
group policy, perform access control decisions during group
establishment, generate group key, recover from the compromise of a
group member, delegate group security functions, and destroy the group.
Fundamental to the security of the group communications is the GSAKMP
Policy Token, first presented in the GKMP [5], [6]. Group Policy define
s how and by whom data is handled in the group. It details the
authorizations needed to serve in special roles, it defines the access
control rules that govern the group, and it specifies the mechanisms
needed to protect communications. Furthermore, the token must be
signed by an authorized source and authenticated as such before use.
The need for consistent distributed enforcement of policy is critical
to the security of the group. The Policy Token is the vehicle by
which members can understand exactly how to manage the group data.
This paper details a relatively simple Policy Token to be used with GSAKMP.
The application specific data defined in Section 2.4.1.3.1.1 is to be
used with IPsec as the underlying protocol securing the group's
communications. GSAKMP's use of other secure protocols can be similarly
profiled.
2. GSAKMP Policy Token
The GSAKMP Security Policy Token is comprised of five fields
corresponding to the identification of the group, the authorizations
in it, the access control policies governing the group, the mechanisms
supporting secure communications, and the authentication of the contents
of the token.
Each of the fields of the GSAKMP Policy Token is further expanded in
following sections.
Harney, Colegrove, Lough, Meth [Page 4]
Internet Draft GSAKMP Token Specification February 2003
2.1. Identification
2.1.1. Token ID
The Token ID Field explicitly identifies the token as a GSAKMP token
for a particular group, generated at a particular time. The Token ID
Field consists of a Version Number indicating Token version, Protocol
ID indicating GSAKMP, Group ID consisting of IP Addresses and serial
numbers, and a Time Issued Field.
The time issued subfield of the TokenID is of particular interest in
the prevention of replay attacks. A replay attack is when an adversary
inserts an authenticated message or portion of a message into a new
run of a protocol. The time issued subfield of the GSAKMP Policy
Token helps to prevent such an attack. The receiver of a new token
can verify that the time issued is both appropriate for the policy
token and generated at a time later than the time issued on any
previous Policy Tokens for that group. This will prevent an adversary
from successfully replaying an old token and having it be accepted
as a new one. If a token with a bad timestamp is received, the
recipient of the token MUST reject the token.
2.1.1.1. Version
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Version Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Version ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version Length (4 bytes, unsigned integer) - Length in bytes of the
"Version" field.
Version (variable length, ASCII character) - This indicates the
version number of this token. The format for the version 1.1 token
is "V1.1". Note: the quotes are not included.
Harney, Colegrove, Lough, Meth [Page 5]
Internet Draft GSAKMP Token Specification February 2003
2.1.1.2. Time Issued
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Time Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Time Issued ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Time Length (4 bytes, unsigned integer) - Length in bytes of the "Time
Issued" field.
Internet Draft GSAKMP Token Specification February 2003
Time Issued (variable length, ASCII character) - This indicates the
time the token was created in the format "Thu Jan 3 10:01:11 2002".
Note: the quotes are not included.
2.1.1.3. Protocol ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ID Length (4 bytes, unsigned integer) - Length in bytes of the
"Protocol ID" field.
Protocol ID (variable length, ASCII character) - This indicates
the version of the GSAKMP protocol this token is designed to work with.
To identify protocol ID 1, the format would be "P1.0". Note: the quote
s are not included.
2.1.1.4. Group ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Group Serial Number !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IP Type ! IP Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! IP Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Group Serial Number (4 bytes, unsigned integer) - Integer chosen to
uniquely identify this group on the particular IP address.
IP Type (1 byte, unsigned integer) - Indicates the type of IP Address
that will be used for the following field. See Table 1
Table 1: IP Types
IP Type Value
_______________________
IPv4 0
IPv6 1
Reserved 2-255
IP Length (4 bytes, unsigned integer) - Length in bytes of the "IP
Value" field.
Harney, Colegrove, Lough, Meth [Page 6]
Internet Draft GSAKMP Token Specification February 2003
IP Value (variable length, ASCII character) - This indicates the IP
address that will be used to identify this group. The format for IPv4
is "224.100.100.100". Note: the quotes are not included and that
digits are their character representations.
2.2. Authorizations
The Authorization Field allows group members to ensure that security
relevant actions are being performed by authorized group entities. This
ensures that a rogue group member does not mislead other group members
into an insecure action.
The Authorization Field identifies those who are authorized to act in
the special roles of Group Owner, Group Controller and Rekey Controller.
This identification may be done explicitly, where the fields contain
actual identifiers, or implicitly, using sets of rules to define the
policy allowing one to assume the roles listed. For example, a policy
rule might state that anyone in a particular domain is authorized to
act as a Key Server. Such a rule might be stated as
"{/o=acme/ou=responsible}."
Authorization Fields will fulfill various needs during the lifetime of
a group. Both new and current members will need to make use of the
authorization field to maintain the level of security of the
communications group.
For new or potential members, this field of the group's token MUST be
used as input into the decision for joining a particular group and for
the acceptance of keying material. Specifically, the rules MUST be
examined to determine whether they are stringent enough for the
potential member's security needs, and the member trusts the entities
that will be assuming the roles. Furthermore, upon acceptance of the
invitation to join the group, the member will receive the group
communication keys. At that point, the member MUST verify that the
Key Server sending the keys fit the profile indicated by the
Authorization Field. The integrity of keys received from someone not
entitled to act as Key Server MUST be rejected.
The most common use of this field will be by current group members.
Current group members use the Authorization Field upon receipt of key
management or administrative messages. Before acting upon these
messages, it must be determined that the sender did indeed have the
necessary permissions to initiate a given action. For example, an
unauthorized rekey message might have the result of placing a member
on an incorrect key, thereby denying them access to the group's
communications. If the sender did not have the necessary permissions,
the recipient MUST reject the key.
Harney, Colegrove, Lough, Meth [Page 7]
Internet Draft GSAKMP Token Specification February 2003
The authorizations section is made up of an Owner Name, Rekey
Controller Name, Owner PKI, Rekey Controller PKI and one or more Key
Server identifiers. The Key Server identifier is made up of a Rule and
a Rule PKI.
2.2.1. Owner Name
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Serial Number !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Owner Name Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Owner Name ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Serial Number (4 bytes, unsigned integer) - Integer representing the
X509V3 signature certificate serial number from the certificate
representing the Group Owner.
Owner Name Length (4 bytes, unsigned integer) - Length in bytes of the
"Owner Name" field.
Owner Name (variable length, ASCII character) - This field represents
the X509V3 Subject data in the format "/C=US/ST=MD/L=Columbia/O=SPARTA,
Inc./OU=ISSO/CN=loughp/Email=loughp@sparta.com". Note: the quotes
are not included.
2.2.2. Rekey Controller Name
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Serial Number !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Rekey Controller Name Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Rekey Controller Name ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Serial Number (4 bytes, unsigned integer) - Integer representing the
X509V3 signature certificate serial number from the certificate
representing the Rekey Controller member.
Rekey Controller Name Length (4 bytes, unsigned integer) - Length in
bytes of the "Rekey Controller. Name" field.
Harney, Colegrove, Lough, Meth [Page 8]
Internet Draft GSAKMP Token Specification February 2003
Rekey Controller Name (variable length, ASCII character) - This field
represents the X509V3 Subject data in the format "/C=US/ST=MD/L=Columbia
/O=SPARTA, Inc./OU=ISSO/CN=loughp/Email=loughp@sparta.com". Note: the
quotes are not included.
2.2.3. Owner Name PKI
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! PKI Type ! Pub Key Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Serial Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Owner Name PKI Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Owner Name PKI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PKI Type (1 byte, unsigned integer) - Indicates the type of certificate
being used to identify the issuer Public Key Infrastructure (PKI) used
to validate the Owner Name. See Table 2.
Table 2: PKI Type
PKI Certificate Type Value
__________________________________________
None 0
PKCS #7 wrapped X.509 certificate 1
PGP Certificate 2
DNS Signed Key 3
X.509 Certificate -- Signature 4
X.509 Certificate - Key Exchange 5
Kerberos Tokens 6
Certificate Revocation List (CRL) 7
Authority Revocation List (ARL) 8
SPKI Certificate 9
X.509 Certificate - Attribute 10
Reserved 11 - 255
Public Key Length (4 bytes, unsigned integer) - Length in bits of the
public key used for this PKI.
Serial Number (4 bytes, unsigned integer) - Integer representing the
X509 certificate serial number from the Owner issuer certificate.
Owner Name PKI Length (4 bytes, unsigned integer) - Length in bytes of
the "Owner Name PKI" field.
Harney, Colegrove, Lough, Meth [Page 9]
Internet Draft GSAKMP Token Specification February 2003
Owner Name PKI (variable length, ASCII character) - This field
represents the X509 Subject data of the issuer certificate of the Owner Name
certificate (Section 2.2.1.) in the format "/C=US/ST=MD/L=Columbia/O=
SPARTA, Inc./CN=RootCA/Email=RootCA@sparta.com". Note: the quotes are
not included.
2.2.4. Rekey Controller Name PKI
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! PKI Type ! Pub Key Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Serial Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Rekey Controller Name PKI Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Rekey Controller Name PKI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PKI Type (1 byte, unsigned integer) - Indicates the type of certificate
being used to identify the issuer PKI used to validate the Rekey
Controller Name. See Table 2.
Public Key Length (4 bytes, unsigned integer) - Length in bits of the
public key used for this PKI.
Serial Number (4 bytes, unsigned integer) - Integer representing the
X509 certificate serial number from the Rekey Controller issuer
certificate.
Rekey Controller Name PKI Length (4 bytes, unsigned integer) - Length in
bytes of the "Rekey Controller Name PKI" field.
Rekey Controller Name PKI (variable length, ASCII character) - This
field represents the X509 Subject data of the issuer certificate of
the Rekey Controller Name certificate (Section 2.2.2) in the format
"/C=US/ST=MD/L=Columbia/O=SPARTA, Inc./CN=RootCA/Email=RootCA@sparta.com".
Note: the quotes are not included.
2.2.5. Number of Key Server Authorizations
Because multiple Key Server Authorizations are possible, this field is
included to indicate the number of authorizations that follow to allow
them to be more easily parsed.
Harney, Colegrove, Lough, Meth [Page 10]
Internet Draft GSAKMP Token Specification February 2003
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Num KS Auths !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number Key Server Authorizations (2 bytes, unsigned integer) - Number of
Key Server Authorizations that will follow.
2.2.6. Key Server Authorization
This section describes the rule used to determine an authorized Key
Server in the token. This field may be repeated as many times as
necessary and indicated in Section 2.2.5. Number of Key Server
Authorizations.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Rule Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Rule ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! PKI Type ! Pub Key Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Serial Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Issuer PKI Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Issuer PKI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rule Length (4 bytes, unsigned integer) - Length in bytes of the "Rule"
field.
Rule (variable length, ASCII character) - Textual representation of the
specific identifier to be used in determining Key Server Authorization.
To allow anyone with an X509V3 certificate with an Organization of
"SPARTA, Inc." the format would be "/O=SPARTA, Inc./".
Additionally, a single individual's certificate could be specified by
using the Common Name field such as "/CN=Joe User/". Note: the quotes
are not included.
PKI Type (1 byte, unsigned integer) - Indicates the type of certificate
being used to identify the issuer PKI used to validate the Rule. See
Table 2.
Public Key Length (4 bytes, unsigned integer) - Length in bits of the
public key used for this PKI.
Serial Number (4 bytes, unsigned integer) - Integer representing the
X509 certificate serial number for this issuer certificate.
Harney, Colegrove, Lough, Meth [Page 11]
Internet Draft GSAKMP Token Specification February 2003
Issuer PKI Length (4 bytes, unsigned integer) - Length in bytes of the
"Issuer PKI" field.
Issuer PKI (variable length, ASCII character) - This field represents
the X509 Subject data of the issuer certificate in the format
"/C=US/ST=MD/L=Columbia/O=SPARTA, Inc./CN=RootCA/Email=RootCA@sparta.com".
Note: the quotes are not included.
2.3. Access Controls
Access Controls are used to strictly define who can and cannot be a
member of this group and the mechanisms used to validate those rules.
Access Controls are made up of inclusionary and exclusionary rules. All
rules are cumulative; however, if a member passes both an inclusionary
and exclusionary rule, the exclusions MUST take precedence. 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 the
acceptance of keying material. Specifically, the rules should be
examined to determine whether they are stringent enough for the
potential member's security needs, and the member trusts the entities
that will be assuming the roles. Access Controls each have a Permission,
one or more Name Rules and one or more IP Rules. The Permissions are
hierarchical in the traditional military sense where access at a higher
level encompasses 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 particular knowledge group or groups.
2.3.1. Inclusionary
Inclusionary rules specify members, or groups of members, that are
allowed access to the group.
2.3.1.1. Permission
In the current SPARTA implementation of the GSAKMP Token, the Permission
field is used in conjunction with the Netscape Comment field available
in an X509V3 certificate. The Permissions are hierarchical in the
traditional military sense where access at a higher level encompasses
all the access of the lower levels plus new ones, and dominance rules
apply. If the token specifies a permission of 5 all certificates with
a Netscape Comment field of 5 OR HIGHER will pass this control.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Permission !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Permission (4 bytes, unsigned integer) - Integer representing the
minimum necessary permission level indicated by the X509V3 Netscape
Comment field. Note: Valid values are between 0 and 10. 11 and above
are reserved for future use.
Harney, Colegrove, Lough, Meth [Page 12]
Internet Draft GSAKMP Token Specification February 2003
2.3.1.2. Number of Name Rules
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Num Name Rules !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of Name Rules (2 bytes, unsigned integer) - Number of Name Rules
that will follow.
2.3.1.3. Name Rule
This section describes the rule used to determine who is authorized to
be a member based on the X509 Subject field. This field may be repeated
as many times as necessary and indicated in Section 2.3.1.2. Number of
Name Rules.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Rule Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Rule ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! PKI Type ! Pub Key Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Serial Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Issuer PKI Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Issuer PKI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rule Length (4 bytes, unsigned integer) - Length in bytes of the "Rule"
field.
Rule (variable length, ASCII character) - Textual representation of the
specific identifier to be used in determining membership. To allow
anyone with an X509V3 certificate with an Organization of "SPARTA, Inc."
the format would be "/O=SPARTA, Inc./". Note: the quotes are not
included.
PKI Type (1 byte, unsigned integer) - Indicates the type of certificate
being used to identify the issuer PKI used to validate the Rule. See
Table 2.
Public Key Length (4 bytes, unsigned integer) - Length in bits of the
public key used for this PKI.
Serial Number (4 bytes, unsigned integer) - Integer representing the
X509 certificate serial number for this issuer certificate.
Harney, Colegrove, Lough, Meth [Page 13]
Internet Draft GSAKMP Token Specification February 2003
Issuer PKI Length (4 bytes, unsigned integer) - Length in bytes of the
"Issuer PKI" field.
Issuer PKI (variable length, ASCII character) - This field represents
the X509 Subject data of the issuer certificate in the format
"/C=US/ST=MD/L=Columbia/O=SPARTA, Inc./CN=RootCA/Email=RootCA@sparta.com".
Note: the quotes are not included.
2.3.1.4. Number of IP Rules
This section is for future expansion of the policy token and MUST be set
to zero. IP Rules may be used in the future to restrict a group member
to certain IP or range of IP addresses.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Num IP Rules !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of IP Rules (2 bytes, unsigned integer) - Unused. MUST be set to
zero.
2.3.2. Exclusionary
Exclusionary rules specify members or groups of members that are
explicitly denied access to this group. This is most useful when used
in conjunction with an inclusionary rule. If we want to allow all of
SPARTA, Inc. with the exception of one employee, we make an inclusionary
rule for SPARTA, Inc. and an exclusionary rule for that one employee.
2.3.2.1. Permission
This field is only used to allow the format of the exclusionary rules to
match that of the inclusionary rules. It has no current use and MUST
be set to zero.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Permission !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Permission (4 bytes, unsigned integer) - Currently unused and MuST be set
to zero.
2.3.2.2. Number of Name Rules
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Num Name Rules !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Harney, Colegrove, Lough, Meth [Page 14]
Internet Draft GSAKMP Token Specification February 2003
Number of Name Rules (2 bytes, unsigned integer) - Number of Name Rules
that will follow.
2.3.2.3. Name Rule
This section describes the rule used to determine who is unauthorized to
be a member based on the X509 Subject field. This field may be repeated
as many times as necessary and indicated in Section 2.3.2.2. Number of
Name Rules.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Rule Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Rule ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! PKI Type ! Pub Key Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Serial Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Issuer PKI Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Issuer PKI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rule Length (4 bytes, unsigned integer) - Length in bytes of the "Rule"
field.
Rule (variable length, ASCII character) - Textual representation of the
specific identifier to be used in determining membership. To disallow
anyone with an X509V3 certificate with an Organization of "SPARTA, Inc."
the format would be "/O=SPARTA, Inc./". Note: the quotes are not included.
PKI Type (1 byte, unsigned integer) - Indicates the type of certificate
being used to identify the issuer PKI used to validate the Rule. See
Table 2.
Public Key Length (4 bytes, unsigned integer) - Length in bits of the
public key used for this PKI.
Serial Number (4 bytes, unsigned integer) - Integer representing the
X509 certificate serial number for this issuer certificate.
Issuer PKI Length (4 bytes, unsigned integer) - Length in bytes of the
"Issuer PKI" field.
Issuer PKI (variable length, ASCII character) - This field represents
the X509 Subject data of the issuer certificate in the format
"/C=US/ST=MD/L=Columbia/O=SPARTA, Inc./CN=RootCA/Email=RootCA@sparta.com".
Note: the quotes are not included.
Harney, Colegrove, Lough, Meth [Page 15]
Internet Draft GSAKMP Token Specification February 2003
2.3.2.4. Number of IP Rules
This section is for future expansion of the policy token and MUST be set to
zero. IP Rules may be used in the future to restrict a group member to
certain IP or range of IP addresses.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Num IP Rules !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of IP Rules (2 bytes, unsigned integer) - MUST be set to zero.
2.4. Mechanisms
The security services and related mechanisms used must be consistent
to maintain uniform data protection. For example, if the confidentiality
of data is protected by the Advanced Encryption Standard (AES) at one point
and by the Data Encryption Standard (DES) at another, the overall
protection afforded the data is only the strength offered by the weakest
mechanism.
The data mechanisms used to protect the various phases of the group
communications are specified in the Mechanisms Field of the GSAKMP Policy
Token. This field should be used as input into the decision for joining
a particular group. Specifically, the rules should be examined to determine
whether they are stringent enough for the potential member's security needs.
The actual Group Application Secure Association (SA), Unicast SA and Key
Management SAs are specified here. The mechanisms field will ensure that
the policy protecting communications is sufficient and consistent throughout
the group.
Harney, Colegrove, Lough, Meth [Page 16]
Internet Draft GSAKMP Token Specification February 2003
2.4.1. Application SA
The Application SA (Category-3 SA[2]) describes the protection afforded
Group Communications. The actual format of this field is largely determined
by the choice of security protocol for the protection of data. To this end,
section 2.4.1.3 defines Group Specific Data that is passed through to the
application. Allowing information to be passed through via the token ensures
both the authentication and group-wide distribution of the data. Mechanism
and mode choices for confidentiality and authentication, key determination,
key length and rekey must all be considered. Furthermore, agreed upon key
validity intervals (cryptoperiods) and possible data source authentication
MUST be specified.
2.4.1.1. Encryption
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Algorithm ! Mode ! Key Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Lifespan !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Type ! Key CM !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Algorithm (1 byte, unsigned integer) - Encryption algorithm to be used
for Group communication. See Table 3.
Table 3: Algorithm Type
Algorithm Value
_____________________________
None 0
DES 1
3DES 2
RC2 3
RC4 4
Reserved 5-255
Mode (1 byte, unsigned integer) - Mode for the given algorithm. See
Table 4.
Table 4: Encryption Mode
Mode Value
__________________________
None 0
CBC64 1
CFB64 2
CFB8 3
ECB 4
Reserved 5-255
Harney, Colegrove, Lough, Meth [Page 17]
Internet Draft GSAKMP Token Specification February 2003
Key Length (2 bytes, unsigned integer) - Length in bits of the GTEK.
Key Lifespan (4 bytes, unsigned integer) - Time in seconds the key is
to be valid.
Key Type (1 byte, unsigned integer) - Intended use for Encryption key.
See Table 5.
Table 5: Key Type
Key Type Value
__________________________
None 0
GTEK 1
GKEK 2
CR 3
Reserved 4-255
Key Creation Methodology (1 byte, unsigned integer) - Indicates if the
key was generated by cooperative pair wise methodology or self generated.
See Table 6.
Table 6: Key Creation Methodology
Methodology Value
___________________________
None 0
Self 1
Pair 2
Reserved 3-255
2.4.1.2. Rekey Information
This section will describe the frequency and rollover information for
the Group key. The frequency indicates how often a rekey event should
occur for this key. It is set up similar to a Unix Cron job. Fields
exist for minute, hour, day, month, day of week and day interval.
A -1 in a field indicates that field is not used. The rollover section
describes the method to use during a key rollover and the number of
seconds that methodology should be used.
Harney, Colegrove, Lough, Meth [Page 18]
Internet Draft GSAKMP Token Specification February 2003
2.4.1.2.1. Frequency
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Minutes !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Hours !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Day of Month !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Month !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Day of Week !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Day Interval !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Minutes (4 bytes, signed integer) - Time in seconds of Rekey.
Hours (4 bytes, signed integer) - Time in hours of Rekey.
Day of Month (4 bytes, signed integer) - Day of month of Rekey.
Month (4 bytes, signed integer) - Month of Rekey.
Day of Week (4 bytes, signed integer) - Day of Week of Rekey.
Day Interval (4 bytes, signed integer) - Day Interval of Rekey.
2.4.1.2.2. Rollover
The rollover section indicates what needs to be done on replacement of
key material. The time field will indicate how long the key being
replaced will be allowed to be used in conjunction with the new key
material.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Time ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+
Type (1 byte, unsigned integer) - Type of Rollover mechanism to use.
See Table 7.
Table 7: Rollover Type
Type Value
______________________
Send New 0
Reserved 1-255
Harney, Colegrove, Lough, Meth [Page 19]
Internet Draft GSAKMP Token Specification February 2003
Time (4 bytes, unsigned integer) - Time in seconds to enforce Rollover
mechanism.
2.4.1.3. Group Specific Data
This section allows additional application specific data to be carried
by the token. The next section specifies the use with IPSec. Other
applications can be similarly specified. If no additional group specific
data is used, Type is zero, length is zero and there is no data section.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Group Specific Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (1 byte, unsigned integer) - Type of Group Specific Data. See
Table 8.
Table 8: Group Specific Type
Type Value
______________________
None 0
IPSec 1
Reserved 2-255
Length (4 bytes, unsigned integer) - Length of Group Specific Data field.
Zero if none.
Data (variable, Group specific encoding) - Group Specific Data.
2.4.1.3.1 IPSec Application Specific Data
This section describes the Group Specific Data format for use with
IPSec implementations. Further discussion of the IPSec databases
populated by this information can be found in Appendix A. The Type
for Section 2.4.1.3. must be one (1) for this IPSec token implementation.
2.4.1.3.1.1. Number of Secure Associations
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
! Num SAs !
+-+-+-+-+-+-+-+-+
Number of Secure Associations (1 byte, unsigned integer) - Number of
Secure Associations that make up this set of IPSec rules.
Harney, Colegrove, Lough, Meth [Page 20]
Internet Draft GSAKMP Token Specification February 2003
2.4.1.3.1.2. Secure Associations
This is the data that will populate the SAD and SPD. This section will
be repeated the number of times indicated by Section 2.4.1.3.1.1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Sec Protocol ! Direction ! ESP Algor ! Auth !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Encap ! SA LifeType ! SA Lifetime ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Source Address Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Source Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ Destination Address Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ Destination Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~Trans Protocol ! Key Creation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SPI (4 bytes, unsigned integer) - Random number unique to this host for
this multicast address
Security Protocol (1 byte, unsigned integer) - Defines type of Security
Protocol. See Table 9.
Table 9. Security Protocol
Type Data
______________________
None 0
ESP 1
AH 2
Reserved 3-255
Direction (1 byte, unsigned integer) - Processing direction for this
rule. See Table 10.
Table 10. Direction
Type Data
_____________________
Bypass 0
Incoming 1
Outgoing 2
Reserved 3-255
ESP Algorithm (1 byte, unsigned integer) - Algorithm to be used if ESP
mode is selected. See Table 11.
Harney, Colegrove, Lough, Meth [Page 21]
Internet Draft GSAKMP Token Specification February 2003
Table 11. ESP Algorithm
Type Data
_____________________
None 0
ESP-DES 1
Reserved 2-255
Authentication (1 byte, unsigned integer) - Algorithm to be used for
authentication in AH only mode or for ESP authentication. See Table 12.
Table 12. ESP Authentication
Type Data
_____________________
None 0
HMAC-SHA 1
HMAC-MD5 2
Reserved 3-255
Encapsulation Mode (1 byte, unsigned integer) - Encapsulation Mode used
for this IPSec rule. See Table 13.
Table 13. Encapsulation Mode
Type Data
_____________________
None 0
Tunnel 1
Reserved 2-255
SA Lifetype (1 byte, unsigned integer) - Describes the way we will
calculate the lifetime for this SA. Used in conjunction with SA
Lifetime. See Table 14.
Table 14. SA Lifetype
Type Data
_____________________
None 0
Bytes 1
Kilobytes 2
Megabytes 3
Packets 4
Reserved 5-255
SA Lifetime (4 bytes, unsigned integer) - Valid integer to be used in
conjunction with the type found in SA Lifetype.
Source Address Length (4 bytes, unsigned integer) - Length in bytes of
the Source Address field.
Source Address (variable length, ASCII character) - ASCII dotted decimal
representation of source IP Address (for IPv4).
Destination Address Length (4 bytes, unsigned integer) - Length in bytes
of the Source Address field.
Harney, Colegrove, Lough, Meth [Page 22]
Internet Draft GSAKMP Token Specification February 2003
Destination Address (variable length, ASCII character) - ASCII dotted
decimal representation of destination IP Address (for IPv4).
Transport Protocol (1 byte, unsigned integer) - Indicates the type of
transport protocol used by this SA. See Table 15.
Table 15. Transport Protocol
Type Data
_____________________
None 0
TCP 1
UDP 2
Reserved 3-255
Key Creation (1 byte, unsigned integer) - Indicates the key creation
methodology for this SA. See Table 16.
Table 16. Key Creation
Type Data
_____________________
Preplaced Key 0
Reserved 1 - 255
2.4.2. Unicast SA
The Unicast SA defines the mechanisms that will be used any time two
group members perform peer-to-peer communication. Mainly used during
the GSAKMP "handshake" when a member attempts to join the group. This
section will define the protocol to be used, the p and g values (if
appropriate) and the encryption algorithm the resultant key will utilize.
Rekey mechanisms will also be covered. The PKI defined for Unicast
communication is also defined as well as necessary signature information.
This section will be broken down into the Creation and Encryption,
Rekey, PKI and Signature Info sections.
2.4.2.1. Creation and Encryption
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ! Group Est Type! p Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! p ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! g !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Algorithm ! Mode ! Key Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Lifespan !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Type ! Key CM !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Harney, Colegrove, Lough, Meth [Page 23]
Internet Draft GSAKMP Token Specification February 2003
Protocol (1 byte, unsigned integer) - Represents the type of Secure
Association being relied upon during unicast transactions. See Table 17.
Table 17: Unicast Protocol
Protocol Value
________________________
None 0
IPSEC 1
SSL 2
SMIME 3
ISAKMP 4
Reserved 5-255
Group Establishment Type (1 byte, unsigned integer) - Represents the
type of GSAKMP (Full or Lite) group this token is created to establish.
See Table 18.
Table 18: Group Establishment Type
Type Value
_____________________
Full 0
Lite 1
Reserved 2-255
p Length (4 bytes, unsigned integer) - Length in bytes of p.
p (variable length, Hexadecimal data) - Hex representation of p value
defined for this SA.
g (4 bytes, unsigned integer) - g value defined for this SA.
Algorithm (1 byte, unsigned integer) - Encryption algorithm to be used
for Unicast communication. See Table 3.
Mode (1 byte, unsigned integer) - Mode for the given algorithm. See
Table 4.
Key Length (2 bytes, unsigned integer) - Length in bits of the key.
Key Lifespan (4 bytes, unsigned integer) - Time in seconds the key is to
be valid.
Key Type (1 byte, unsigned integer) - Intended use for Encryption key.
See Table 5.
Key Creation Methodology (1 byte, unsigned integer) - Indicates if the
key was generated by cooperative pair wise methodology or self generated.
See Table 6.
Harney, Colegrove, Lough, Meth [Page 24]
Internet Draft GSAKMP Token Specification February 2003
2.4.2.2. Rekey
This section will describe the frequency and rollover information for
the Unicast key. The frequency indicates how often a rekey event should
occur for this key. It is set up similar to a Unix Cron job. Fields
exist for minute, hour, day, month, day of week and day interval.
A -1 in a field indicates that field is not used. The rollover section
describes the method to use during a key rollover and the number of
seconds that methodology should be used.
2.4.2.2.1. Frequency
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Minutes !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Hours !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Day of Month !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Month !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Day of Week !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Day Interval !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Minutes (4 bytes, signed integer) - Time in seconds of Rekey.
Hours (4 bytes, signed integer) - Time in hours of Rekey.
Day of Month (4 bytes, signed integer) - Day of month of Rekey.
Month (4 bytes, signed integer) - Month of Rekey.
Day of Week (4 bytes, signed integer) - Day of Week of Rekey.
Day Interval (4 bytes, signed integer) - Day Interval of Rekey.
2.4.2.2.2. Rollover
The rollover section indicates what needs to be done on replacement of
key material. The time field will indicate how long the key being
replaced will be allowed to be used in conjunction with the new key
material.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Time ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+
Harney, Colegrove, Lough, Meth [Page 25]
Internet Draft GSAKMP Token Specification February 2003
Type (1 byte, unsigned integer) - Type of Rollover mechanism to use.
See Table 7.
Time (4 bytes, unsigned integer) - Time in seconds to enforce Rollover
mechanism.
2.4.2.3. PKI
This section describes the PKI that will be used to validate the
certificates used in signing Unicast messages.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! PKI Type ! Pub Key Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Serial Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Issuer PKI Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Issuer PKI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PKI Type (1 byte, unsigned integer) - Indicates the type of certificate
being used to identify the issuer PKI used to validate certificates used
in signing the unicast messages. See Table 2.
Public Key Length (4 bytes, unsigned integer) - Length in bits of the
public key used for this PKI.
Serial Number (4 bytes, unsigned integer) - Integer representing the
X509 certificate serial number for this issuer certificate.
Issuer PKI Length (4 bytes, unsigned integer) - Length in bytes of the
"Issuer PKI" field.
Issuer PKI (variable length, ASCII character) - This field represents
the X509 Subject data of the issuer certificate in the format
"/C=US/ST=MD/L=Columbia/O=SPARTA, Inc./CN=RootCA/Email=RootCA@sparta.com".
Note: the quotes are not included.
2.4.2.4. Signature
This section describes the algorithm and hash functions that will be
used when signing unicast messages.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Algorithm ! Hash !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Algorithm (1 byte, unsigned integer) - Encryption algorithm to be used
for Unicast signatures. See Table 3.
Harney, Colegrove, Lough, Meth [Page 26]
Internet Draft GSAKMP Token Specification February 2003
Hash (1 byte, unsigned integer) - Hash to be used for Unicast signatures.
See Table 19.
Table 19: Hash Algorithm
Hash Value
_______________________
SHA1 0
MD5 1
MD2 2
Reserved 3-255
2.4.3. Key Management SA
Finally, the last portion of the Mechanisms Field corresponds to the
protection afforded GSAKMP key management messages, including the
possibility of issuing an amended token. This subfield is actually
broken down into further fields: Rekey and KEK. The Rekey SA
identifies the security mechanisms set up for key management messages.
For cases in which Unicast messages may not be sufficiently protected,
the KEK SA will allow further protection. Both of these correspond to
the Category-2 SA of the GKMBB draft[2].
2.4.3.1. Signature
This section describes the algorithm and hash functions that will be used
when signing Key Management messages.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Algorithm ! Hash !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Algorithm (1 byte, unsigned integer) - Encryption algorithm to be used
for Key Management signatures. See Table 3.
Hash (1 byte, unsigned integer) - Hash to be used for Key Management
signatures. See Table 19.
Harney, Colegrove, Lough, Meth [Page 27]
Internet Draft GSAKMP Token Specification February 2003
2.4.3.2. PKI
This section describes the PKI that will be used to validate the
certificates used in signing Key Management messages.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! PKI Type ! Pub Key Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Serial Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Issuer PKI Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Issuer PKI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PKI Type (1 byte, unsigned integer) - Indicates the type of certificate
being used to identify the issuer PKI used to validate certificates used
in signing the Key Management messages. See Table 2.
Public Key Length (4 bytes, unsigned integer) - Length in bits of the
public key used for this PKI.
Serial Number (4 bytes, unsigned integer) - Integer representing the
X509 certificate serial number for this issuer certificate.
Issuer PKI Length (4 bytes, unsigned integer) - Length in bytes of the
"Issuer PKI" field.
Issuer PKI (variable length, ASCII character) - This field represents
the X509 Subject data of the issuer certificate in the format
"/C=US/ST=MD/L=Columbia/O=SPARTA, Inc./CN=RootCA/Email=RootCA@sparta.com".
Note: the quotes are not included.
2.4.3.3. Rekey SA
The Rekey SA describes the mechanisms used when sending Rekey messages.
It is made up of Protocol and Encryption information and Rekey information.
2.4.3.3.1. Protocol and Encryption
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ! Algorithm ! Mode ! Key Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Key Lifespan ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Key Type ! Key CM !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Harney, Colegrove, Lough, Meth [Page 28]
Internet Draft GSAKMP Token Specification February 2003
Protocol (1 byte, unsigned integer) - Protocol being used for Rekey.
See Table 20.
Table 20: Rekey Protocol
Protocol Value
___________________________
None 0
LKH 1
OFT 2
Reserved 3-255
Algorithm (1 byte, unsigned integer) - Encryption algorithm to be used
for Rekey communication. See Table 3.
Mode (1 byte, unsigned integer) - Mode for the given algorithm.
See Table 4.
Key Length (2 bytes, unsigned integer) - Length in bits of the key.
Key Lifespan (4 bytes, unsigned integer) - Time in seconds the key is
to be valid.
Key Type (1 byte, unsigned integer) - Intended use for Encryption key.
See Table 5.
Key Creation Methodology (1 byte, unsigned integer) - Indicates if the
key was generated by cooperative pair wise methodology or self generated.
See Table 6.
2.4.3.3.2. Rekey
This section will describe the frequency and rollover information for
the Rekey key. The frequency indicates how often a rekey event should
occur for this key. It is set up similar to a Unix Cron job. Fields
exist for minute, hour, day, month, day of week and day interval.
A -1 in a field indicates that field is not used. The rollover section
describes the method to use during a key rollover and the number of
seconds that methodology should be used.
Harney, Colegrove, Lough, Meth [Page 29]
Internet Draft GSAKMP Token Specification February 2003
2.4.3.3.2.1. Frequency
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Minutes !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Hours !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Day of Month !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Month !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Day of Week !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Day Interval !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Minutes (4 bytes, signed integer) - Time in seconds of Rekey.
Hours (4 bytes, signed integer) - Time in hours of Rekey.
Day of Month (4 bytes, signed integer) - Day of month of Rekey.
Month (4 bytes, signed integer) - Month of Rekey.
Day of Week (4 bytes, signed integer) - Day of Week of Rekey.
Day Interval (4 bytes, signed integer) - Day Interval of Rekey.
2.4.3.3.2.2. Rollover
The rollover section indicates what needs to be done on replacement of
key material. The time field will indicate how long the key being
replaced will be allowed to be used in conjunction with the new key
material.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Time ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+
Type (1 byte, unsigned integer) - Type of Rollover mechanism to use.
See Table 7.
Time (4 bytes, unsigned integer) - Time in seconds to enforce Rollover
mechanism.
Harney, Colegrove, Lough, Meth [Page 30]
Internet Draft GSAKMP Token Specification February 2003
2.4.3.4. KEK SA
This section will discuss the encryption mechanisms to be used when
there is no underlying SA to rely upon for protection of the key
material, or when the underlying SA is not considered strong enough
for the purpose. This section will define the p and g values, the
encryption information and the rekey information necessary to generate
a cooperatively generated key.
2.4.3.4.1. p & g and Encryption
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! p ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! g !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Algorithm ! Mode ! Key Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Lifespan !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Type ! Key CM !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length (4 bytes, unsigned integer) - Length in bytes of p.
p (variable length, Hexadecimal data) - Hex representation of p value
defined for this SA.
g (4 bytes, unsigned integer) - g value defined for this SA.
Algorithm (1 byte, unsigned integer) - Encryption algorithm to be used
for KEK communication. See Table 3.
Mode (1 byte, unsigned integer) - Mode for the given algorithm.
See Table 4.
Key Length (2 bytes, unsigned integer) - Length in bits of the key.
Key Lifespan (4 bytes, unsigned integer) - Time in seconds the key is
to be valid.
Key Type (1 byte, unsigned integer) - Intended use for Encryption key.
See Table 5.
Key Creation Methodology (1 byte, unsigned integer) - Indicates if the
key was generated by cooperative pair wise methodology or self generated.
See Table 6.
Harney, Colegrove, Lough, Meth [Page 31]
Internet Draft GSAKMP Token Specification February 2003
2.4.3.4.2. Rekey
This section will describe the frequency and rollover information for
the KEK. The frequency indicates how often a rekey event should occur
for this key. It is set up similar to a Unix Cron job. Fields exist
for minute, hour, day, month, day of week and day interval.
A -1 in a field indicates that field is not used. The rollover section
describes the method to use during a key rollover and the number of
seconds that methodology should be used.
2.4.3.4.2.1. Frequency
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Minutes !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Hours !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Day of Month !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Month !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Day of Week !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Day Interval !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Minutes (4 bytes, signed integer) - Time in seconds of Rekey.
Hours (4 bytes, signed integer) - Time in hours of Rekey.
Day of Month (4 bytes, signed integer) - Day of month of Rekey.
Month (4 bytes, signed integer) - Month of Rekey.
Day of Week (4 bytes, signed integer) - Day of Week of Rekey.
Day Interval (4 bytes, signed integer) - Day Interval of Rekey.
2.4.3.4.2.2. Rollover
The rollover section indicates what needs to be done on replacement of
key material. The time field will indicate how long the key being
replaced will be allowed to be used in conjunction with the new key
material.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Type ! Time ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ !
+-+-+-+-+-+-+-+-+
Harney, Colegrove, Lough, Meth [Page 32]
Internet Draft GSAKMP Token Specification February 2003
Type (1 byte, unsigned integer) - Type of Rollover mechanism to use.
See Table 7.
Time (4 bytes, unsigned integer) - Time in seconds to enforce Rollover
mechanism.
2.5. Signature
The signature block field contains the information that verifies the
authenticity of the policy token. It clearly identifies the signer of
the token -- the Group Owner, the PKI information needed to establish
what is the proper certificate to use for the signature verification,
and the signature data. The signature covers all of the fields of the
GSAKMP Policy Token including portions of the Signature Block Field
itself. Because of this, any unauthorized change in the policy token
will invalidate the signature.
2.5.1. Name
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Serial Number !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Owner Name Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Owner Name ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Serial Number (4 bytes, unsigned integer) - Integer representing the
X509V3 signature certificate serial number from the certificate
representing the Group Owner.
Owner Name Length (4 bytes, unsigned integer) - Length in bytes of the
"Owner Name" field.
Owner Name (variable length, ASCII character) -This field represents
the X509V3 Subject data in the format "/C=US/ST=MD/L=Columbia/O=SPARTA,
Inc./OU=ISSO/CN=loughp/Email=loughp@sparta.com". Note: the quotes are
not included.
2.5.2. PKI
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! PKI Type ! Pub Key Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Serial Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Issuer PKI Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Issuer PKI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Harney, Colegrove, Lough, Meth [Page 33]
Internet Draft GSAKMP Token Specification February 2003
PKI Type (1 byte, unsigned integer) - Indicates the type of certificate
being used to identify the issuer PKI used to validate certificates used
in signing the token. See Table 2.
Public Key Length (4 bytes, unsigned integer) - Length in bits of the
public key used for this PKI.
Serial Number (4 bytes, unsigned integer) - Integer representing the
X509 certificate serial number for this issuer certificate.
Issuer PKI Length (4 bytes, unsigned integer) - Length in bytes of the
"Issuer PKI" field.
Issuer PKI (variable length, ASCII character) - This field represents
the X509 Subject data of the issuer certificate in the format
"/C=US/ST=MD/L=Columbia/O=SPARTA, Inc./CN=RootCA/Email=RootCA@sparta.com".
Note: the quotes are not included.
2.5.3. Signature Data
This is the only section of the token that the signature does not sign
over. All fields up to this point are put through the signature
algorithm and the resultant signature is appended in the format covered
in this section.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length of Signature Data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Signature Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length of Signature Data (4 bytes, unsigned integer) - Total length in
bytes of "Signature Data" field.
Signature Data (variable length, Hexadecimal data) - Hexadecimal
representation of signature data output by algorithm.
Harney, Colegrove, Lough, Meth [Page 34]
Internet Draft GSAKMP Token Specification February 2003
Acknowledgements:
The authors of this document would like to thank the following people
for their contribution to this specification:
Greg Bergren
Mark Houchens
Andy McFarland
References:
[1] H. Harney, A. Colegrove, E. Harder, U. Meth, R. Fleischer Group
Secure Association Key Management Protocol, draft-ietf-msec-gsakmp-sec-
00.txt, March 2001, Work in Progress.
[2] H. Harney, M. Baugher, T. Hardjono, GKM Building Block: Group
Security Association (GSA) Definition, September 2000, Work in Progress.
[3] D. Piper, The Internet IP Security Domain of Interpretation for
ISAKMP, RFC 2407, November 1998.
[4] S. Kent, R. Atkinson, Security Architecture for the Internet
Protocol, RFC 2401, November 1998.
[5] H. Harney, C. Muckenhirn, Group Key Management Protocol (GKMP)
Specification, RFC 2093, July 1997.
[6] H. Harney, C. Muckenhirn, Group Key Management Protocol (GKMP)
Architecture, RFC 2094, July 1997.
Harney, Colegrove, Lough, Meth [Page 35]
Internet Draft GSAKMP Token Specification February 2003
Authors Addresses:
Hugh Harney
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
(410) 872-1515 x203
hh@sparta.com
Andrea Colegrove
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
(410) 872-1515 x232
Peter Lough
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
(410) 872-1515 x234
Uri Meth
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
(410) 872-1515 x233
Harney, Colegrove, Lough, Meth [Page 36]
Internet Draft GSAKMP Token Specification February 2003
Appendix A.
The following section further describes the architecture for GSAKMP
using IPsec [3] to provide Security Associations (SAs) for unicast
communications and multicast group application communications. The
authenticated GSAKMP policy token that was described in the previous
section can clearly specify in its mechanisms field how the secure
group can translate its needs to the IPsec specific database policies
utilizing the following application specific information.
GSAKMP creates an association between multiple entities connected by
the Internet. The intent of the protocol is to use secure existing
protocol services that are standardized for the Internet to facilitate
setting up these secure groups. IPsec is one of the standard secure
services that GSAKMP can use. The GSAKMP Policy Token defines the
policy for protecting the multicast group traffic. IPsec can be used
to protect communications between these group members.
GSAKMP is an application layer protocol that exists above the IPsec
network layer encryption engine. Configuration of GSAKMP must include
configuration of the appropriate databases controlling IPsec. GSAKMP
must ensure that IPsec processes its messages appropriately. To
configure IPsec, GSAKMP will have to interact with the Security Policy
Database (SPD) and the Security Association Database (SAD).
Each group can have unique IPsec processing requirements for the unicast
and multicast messages pertaining to that particular group. These
group unique configurations must be conveyed to the IPsec controlling
databases in a way that will allow correct IPsec processing for each
groups' message. Special attention must be paid to the IPsec selector
fields. The standard source and destination pair selectors are not
adequate for multicast groups where multiple groups share the same
destination address.
A.1. IPsec Architecture
The IPsec architecture document [4] identifies two databases used by
IPsec - Security Policy Database (SPD) and Secure Association Database
(SAD). The former specifies the policies that determine the disposition
of all IP traffic (inbound or outbound) from a host, security gateway,
or BITS or BITW IPsec implementation. The latter database contains
parameters that are associated with each (active) security association.
The information in these databases allows the IPsec protocol to process
incoming and outgoing packets.
Harney, Colegrove, Lough, Meth [Page 37]
Internet Draft GSAKMP Token Specification February 2003
A.1.1 SPD Inputs
Purpose of the SPD (copied from RFC 2401)
A security association is a management construct used to enforce a
security policy in the IPsec environment. Thus an essential element of
SA processing is an underlying Security Policy Database (SPD) that
specifies what services are to be offered to IP datagrams and in what
fashion. The form of the database and its interface are outside the
scope of this specification. However, this section does specify certain
minimum management functionality that must be provided, to allow a user
or system administrator to control how IPsec is applied to traffic
transmitted or received by a host or transiting a security gateway.
The SPD must be consulted during the processing of all traffic
(INBOUND and OUTBOUND), including non-IPsec traffic. In order to support
this, the SPD requires distinct entries for inbound and outbound traffic
. One can think of this as separate SPDs (inbound vs. outbound). In
addition, a nominally separate SPD must be provided for each
IPsec-enabled interface.
An SPD must discriminate among traffic that is afforded IPsec protection
and traffic that is allowed to bypass IPsec. This applies to the IPsec
protection to be applied by a sender and to the IPsec protection that
must be present at the receiver. For any outbound or inbound datagram,
three processing choices are possible: discard, bypass IPsec, or apply
IPsec. The first choice refers to traffic that is not allowed to exit
the host, traverse the security gateway, or be delivered to an
application at all. The second choice refers to traffic that is allowed
to pass without additional IPsec protection. The third choice refers
to traffic that is afforded IPsec protection, and for such traffic the
SPD must specify the security services to be provided, protocols to be
employed, algorithms to be used, etc.
The critical elements of the SPD are:
* Destination IP Address
* Source IP Address
* Name
* Data sensitivity level
* Transport Layer Protocol
* Source and Destination (e.g., TCP/UDP) Ports
* Specific IPsec processing
* Specific IPsec Algorithms (spi, service, algorithm, mode)
Harney, Colegrove, Lough, Meth [Page 38]
Internet Draft GSAKMP Token Specification February 2003
A.1.2 SAD Inputs
Purpose of the SAD (copied from RFC 2401)
In each IPsec implementation there is a nominal Security Association
Database, in which each entry defines the parameters associated with one
SA. Each SA has an entry in the SAD. For 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 is appropriate for the packet, the
implementation creates an 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 the SAD is indexed by a destination IP address, IPsec
protocol type, and SPI. The following parameters are associated with
each entry in the SAD. This description does not purport to be a MIB,
but only a specification of the minimal data items required to support
an SA in an IPsec implementation.
The critical elements of the SAD are:
* SAD index
* Outer Header's Destination IP address
* IPsec Protocol
* SPI
* Sequence Number Counter
* Sequence Counter Overflow [only outbound]
* Anti-Replay Window: [only for inbound.]
* AH Authentication algorithm, keys, etc. [REQUIRED for AH
implementations]
* ESP Encryption algorithm, keys, IV mode, IV, etc. [REQUIRED for
ESP implementations]
* ESP authentication algorithm, keys, etc [REQUIRED for ESP
implementations]
* Lifetime of this Security Association: Required
* IPsec protocol mode: tunnel, transport or wildcard
* Path MTU: [REQUIRED for all implementations but used only for
outbound traffic]
Harney, Colegrove, Lough, Meth [Page 39]
