[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/