One document matched: draft-harney-sparta-gsakmp-sec-00.txt
Group Secure Association Key Management Protocol
Status of this memo
This document is an Internet-Draft and is in full conformance with all provisions
of Section 10 of RFC2026.
This document is an Internet-Draft. 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.
To view the entire list of current Internet-Drafts, please check the ``lid-abstracts.txt''
listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za
(Africa), ftp.nordu.net(Northern Europe), ftp.nic.it (Southern Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Document expiration: November 30, 1999
Abstract
The Group Secure Association Key Management Protocol (GSAKMP) provides
a security framework for creating cryptographic groups on a network.
It provides mechanisms to disseminate group security policy, perform
access control based upon PKI certificates, generate group keys, and
recover from compromise. This framework addresses group scalability
issues by facillitating delegation of process-intensive actions in a
secure and controlled manner.
INTERNET-DRAFT GSAKM Protocol April, 1999
Copyright Notice
Copyright Oc The Internet Society (1999). All Rights Reserved.
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 2]
INTERNET-DRAFT GSAKM Protocol April, 1999
Contents
1 Overview 6
1.1 GSAKMP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Document Organization . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Terminology 8
2.1 GSAKMP Terminology . . . . . . . . . . . . . . . . . . . . . . . . 9
3 GROUP LIFE-CYCLE 12
3.1 Group Establishment . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1Create Group Key . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2Distribute Group Key . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Group Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1Member Joins/Leaves . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2CR Events . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Group Removal/Destruction . . . . . . . . . . . . . . . . . . . . . 17
4 Message formats 17
4.1 GSAKMP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Data Attributes Payload . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Policy Token Payload . . . . . . . . . . . . . . . . . . . . . . . 20
4.5 Key Download Payload . . . . . . . . . . . . . . . . . . . . . . . 22
4.6 CR Event Payload . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.7 Identification/Role Payload . . . . . . . . . . . . . . . . . . . . 24
4.8 Certificate Payload . . . . . . . . . . . . . . . . . . . . . . . . 25
4.9 Certificate Request Payload . . . . . . . . . . . . . . . . . . . . 27
4.10Signature Payload . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.11Notification Payload . . . . . . . . . . . . . . . . . . . . . . . 29
4.12Notify Message Types . . . . . . . . . . . . . . . . . . . . . . . 30
4.13Vendor ID Payload . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.14Key Creation Payload . . . . . . . . . . . . . . . . . . . . . . . 32
5 State Diagram 33
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 3]
INTERNET-DRAFT GSAKM Protocol April, 1999
List of Figures
1 Group Establishment Ladder Diagram . . . . . . . . . . . . . . . . 13
2 GSAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . . 18
3 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . . 19
4 Data Attributes Payload . . . . . . . . . . . . . . . . . . . . . . 20
5 Policy Token Payload Format . . . . . . . . . . . . . . . . . . . . 21
6 Key Download Payload Format . . . . . . . . . . . . . . . . . . . . 22
7 Key Download Data Payload Format . . . . . . . . . . . . . . . . . 23
8 CR Event Payload Format . . . . . . . . . . . . . . . . . . . . . . 24
9 Identification/Role Payload Format . . . . . . . . . . . . . . . . 25
10 Certificate Payload Format . . . . . . . . . . . . . . . . . . . . 26
11 Certificate Request Payload Format . . . . . . . . . . . . . . . . 27
12 Signature Payload Format . . . . . . . . . . . . . . . . . . . . . 28
13 Notification Payload Format . . . . . . . . . . . . . . . . . . . . 29
14 Vendor ID Payload Format . . . . . . . . . . . . . . . . . . . . . 32
15 Key Creation Payload Format . . . . . . . . . . . . . . . . . . . . 32
16 GSAKMP State Diagram . . . . . . . . . . . . . . . . . . . . . . . 34
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 4]
INTERNET-DRAFT GSAKM Protocol April, 1999
List of Tables
1 Message Definitions: Group Establishment . . . . . . . . . . . . . 14
2 Legend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Message Definitions: Compromise Recovery Event . . . . . . . . . . 17
4 Message Definitions: Group Removal and Destruction . . . . . . . . 17
5 Group Identification Type Values . . . . . . . . . . . . . . . . . 17
6 Exchange Type Values . . . . . . . . . . . . . . . . . . . . . . . 18
7 Payload Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8 Policy Token Types . . . . . . . . . . . . . . . . . . . . . . . . 21
9 Key Download Information Types . . . . . . . . . . . . . . . . . . 22
10 Key Download Data Types . . . . . . . . . . . . . . . . . . . . . . 23
11 CR Event Types . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12 Identity/Role Types . . . . . . . . . . . . . . . . . . . . . . . . 25
13 Certificate Payload Types . . . . . . . . . . . . . . . . . . . . . 26
14 Signature Types . . . . . . . . . . . . . . . . . . . . . . . . . . 29
15 Signature Context Types . . . . . . . . . . . . . . . . . . . . . . 29
16 Notify Messages -- Status Types . . . . . . . . . . . . . . . . . . 30
17 Notify Messages Types . . . . . . . . . . . . . . . . . . . . . . . 31
18 Types Of Key Creation Information . . . . . . . . . . . . . . . . . 33
19 State Transition Events . . . . . . . . . . . . . . . . . . . . . . 35
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 5]
INTERNET-DRAFT GSAKM Protocol April, 1999
1 Overview
The Group Secure Association Key Management Protocol (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 group members, delegate
group security functions and destroy the group.
The goals of the GSAKMP are to create a protocol that:
1. Distributes group policy,
2. Provides mechanisms for distributing the group key, and
3. Provides mechanisms for compromise recovery based on the Logical Key Hierarchy
(LKH) compromise recovery methodology.
1.1 GSAKMP Overview
Protecting information requires the definition of a security policy and the
enforcement of that policy by capable parties. Control and access to the
cryptographic key is the primary mechanism to enforce the access control
policy. The GSAKMP provides the mechanisms to control access to the group
key.
This document identifies the GSAKMP Message Passing Requirements. The group
key(s) are created by the group controller. The group controller must start
the group access control, policy enforcement process. The group controller
needs to have the access rules defined for joining the group and should be
able to identify and verify the permissions of the members to which they
will distribute keys.
The potential group members need to have ``knowledge'' of the access control
policy for the group, an unambiguous identification of any party downloading
keys to them, and verifiable chain of authority for key download. The group
members also need to verify that the key creator is authorized to act in
that capacity.
In order to establish a group Secure Association (SA) to support these activities,
the identity of each party in the security/access control process must be
unambiguously stated/asserted and authenticated to ensure that they are
authorized to be a member of the group as defined by the group's security
policy. The security characteristics of the establishment protocol for the
SA should include:
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 6]
INTERNET-DRAFT GSAKM Protocol April, 1999
1. Coherent permission topology,
2. Group policy,
3. Group policy dissemination,
4. Peer SA to protect data, and
5. Access control checking.
1.2 Assumptions
1. GSAKMP makes the following assumptions of the underlying host:
2. The operating system can provide the process and data separation services
to support software encryption.
3. A separate SA mechanism is present that is sufficient to protect the distribution
of the group key.
4. The host and all the applications on that host share the same certificate
identities (at least initially).
1.3 Document Organization
Section 1 presents an overview of secure group communications and identifies
additional reference documents. Section 2 presents the terminology and
concepts used to present the requirements of this protocol. Section 3 describes
the group management life-cycle and Section 4 presents the message types
and formats used during each phase of the life-cycle. Section 5 presents
a discussion of the states encountered in the protocol.
1.4 References
The following references were used in the preparation of this document:
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 7]
INTERNET-DRAFT GSAKM Protocol April, 1999
Wallner, D., Harder E., and Agee R., ``Key Management for Multicast: Issues
and Architectures,`` Internet Draft, Informational, September 1998.
``Multicast Security Management Protocol (MSMP) Requirements and Policy'',
SPARTA, October, 1998.
``Logical Key Hierarchy (LKH) Protocol'', SPARTA, October, 1998.
[RFC 2093] Harney H., Muckenhirn C., and Rivers T., ``Group Key, Management
Protocol Specification,`` RFC 2093, Experimental, July 1997.
[RFC 2094] Harney H., Muckenhirn C., and Rivers T., ``Group Key Management
Protocol Architecture,`` RFC 2094, Experimental, July 1997.
[RFC 2408] Maughan D., Schertler M., Schneider M., and Turner J., ``Internet
Security Association and Key Management Protocol (ISAKMP)``, RFC 2408, Proposed
Standard, November 1998.
[RFC 2409] Harkins D. and Carrel D., ``The Internet Key Exchange (IKE)'',
RFC 2409, Proposed Standard, November 1998.
[RFC 2412] Orman H. K., ``The OAKLEY Key Determination Protocol``, RFC 2412,
Informational, November 1998.
DCCM Architecture and System Design, June 1998, Mr David Balenson, Dr Dennis
Branstad, TIS Labs at Network Associates, Inc., Technical report to DARPA
Contract No. F30602-97-C-0277.
[RFC 2402] Kent S. and Atkinson, R., ``IP Authentication Header``, RFC 2402,
November 1998, Proposed Standard.
[RFC 2401] Kent S. and Atkinson, R., ``Security Architecture for the Internet
Protocol``, RFC 2401, November 1998, Proposed Standard.
[RFC 2406] Kent S. and Atkinson, R., ``IP Encapsulating Security Payload
(ESP)``, RFC 2406, November 1998, Proposed Standard.
Bhattacharya P. and Pereira R., ``IPSec Policy Data Model``, Internet Draft,
February 1998.
2 Terminology
The following terminology is used throughout the GSAKMP paper.
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 8]
INTERNET-DRAFT GSAKM Protocol April, 1999
2.1 GSAKMP Terminology
Group Member: A group member (GM) is any entity with access to the group keys.
Regardless of how a member becomes a part of the group or how the group is
structured, GMs will perform the following actions:
1. Validate the GC's authorization to perform actions,
2. Accept group keys from the GC,
3. Request group keys from the GC,
4. Maintain local CRL lists,
5. Enforce the cooperative group policies as stated in the group policy
token,
6. Perform peer review of key management actions, and
7. Manage their local key.
Group Secure Association (GSA): A cryptographic group is a logical association
of users or hosts that share cryptographic key(s). This group may be established
to support associations between applications or communication protocols.
Group Policy: The group policy completely describes the protection mechanisms
and security relevant behaviors of the group. This policy must be commonly
understood and enforced by the group for coherent secure operations.
Policy Token/Certificate: The policy token is a mechanism used to disseminate
the group policy. The policy token is issued and signed by an authorized
source. Each member of the group must verify the token, meet the group join
policy , and enforce the policy of the group. The group policy data element
will contain a variety of information including:
1. GSAKMP protocol format,
2. Key creation method,
3. Key dissemination policy,
4. Access control policy,
5. Group architecture policy, and
6. Compromise recovery policy.
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 9]
INTERNET-DRAFT GSAKM Protocol April, 1999
The policy token layout will be fully presented in the Group Policy Token
Specification document.
Group Controller: The Group Controller (GC) is a group member with authority
to perform any critical protocol actions including:
1. Creating and distributing keys
2. Maintain the CR infrastructure (LKH), and
3. Build and maintain the LKH arrays.
As the group evolves, it may become desirable to have multiple controllers
perform these functions (e.g., LKH Controller and Group Key Controller).
Subordinate Controller: Any group member, as defined in the group policy, has
the capability to act as a Subordinate Controller (SC) thus allowing the
group processing and communication requirements to be distributed equitably
throughout the network. If the group is structured in such a way, the delegated
group members, would be identified to via the policy token. The SCs may
perform actions delegated to them by the GC including:
1. Dissemination of the group key, and
2. Management of the status of the local group.
The ease of managing a very large group may also be improved by delegating
the creation of subordinate LKH arrays to the SCs. The SCs would have the
authority and mechanisms necessary to create and disseminate the LKH arrays
for the members under their control. A more detailed discussion of LKH arrays
may be found in the Logical Key Hierarchy (LKH) Protocol draft document.
Peer-to-Peer SA: Peer-to-Peer SA keys can be created by using any number of
key generation protocols including the Internet Secure Association Key Management
Protocol (ISAKMP)/IPSec and SSL/HS. These protocols rely on cooperative key
generation algorithms and on peer review of permissions. Modern SA protocols
are specifically developed to support this task. Once the peer-to-peer SA
is established, the group protocol can use that SA mechanism for secure confidential
group communications throughout the life of the group.
GSA Keys: GSA keys can be created using strong randomization key generation
protocols. These protocols rely on a cooperatively conferred policy. Once
the group keys are created and disseminated to the group members, the group
protocol can use that SA mechanism for secure confidential group communications
throughout the life of the group.
Group Traffic Encryption Key (GTEK): The key or keys created for encrypting
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 10]
INTERNET-DRAFT GSAKM Protocol April, 1999
the group data.
Logical Key Hierarchy (LKH) array: The group of keys created to facilitate the
LKH compromise recovery methodology.
Compromise Recovery: The act of recovering a secure operating state after detecting
that a group member cannot be trusted.
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 11]
INTERNET-DRAFT GSAKM Protocol April, 1999
3 GROUP LIFE-CYCLE
The management of a cryptographic group follows a life-cycle: group definition,
group establishment, group maintenance, and group removal. Each of these
life-cycle phases is discussed in the following sections. A cryptographic
group is established based on some need for secure communications among a
group of individuals. The activities involved in creating a cryptographic
group include:
1. Determine Access Policy: Group Join
2. Determine Authorization Policy: Key Dissemination, Computer Trust, and Architecture
Authorization
3. Determine Mechanisms: Algorithms and Infrastructure
4. Determine Architecture: Key Dissemination and Compromise Recovery
5. Create Group Policy Token
For the purposes of this document, it is assumed that the group definition
activity has occurred and the group information has been broadcast on a key
management channel or through a directory service.
3.1 Group Establishment
The Group Establishment Ladder diagram, Figure 1, is presented to illustrate
the process of establishing a cryptographic group. The left side of the
diagram represents the actions of the GC. The right side of the diagram
represents the actions of the GMs. The components of each message shown in
the diagram are presented in the Message Definitions sections following the
diagram.
Potential GMs may join a group in two ways: by invitation (push) or request
(pull). For purposes of illustration, the diagram presents a ``Request to
Join Group'', a ``pull'', message sent from a potential GM.
At this point, the GC must accept or deny the request. Mode 1 indicates a
provision for refusing the connection due to some specified reason (e.g., no
group, group full, repetitive attempts to join). If the results of Mode 1
indicate that the GC should reject the request, the session is terminated.
If the results of Mode 1 indicate that the GC should accept the request, the
session continues. The message traffic to an invited potential member also
begins at this point on the diagram.
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 12]
INTERNET-DRAFT GSAKM Protocol April, 1999
CONTROLLER MESSAGE MEMBER
!<------------Request to Join-------------!
<Mode 1> ! !
!<============SA ESTABLISHMENT===========>! (Outside GSAKMP)
! !
!-------------Invitation----------------->!
! !<Mode 2>
!<------------Invitation Response-------->!
<Mode 3> ! !
!-------------Key Download--------------->!
! !<Mode 4>
!<------------Acknowledgment--------------!
! !<Mode 5>
!<=======SHARED KEYED GROUP SESSION======>!
Figure 1: Group Establishment Ladder Diagram
The area of the diagram specified as ``Outside GSAKMP'' is merely illustrative
to show the confidentiality between the GC and GM. It is assumed, for the
purposes of this document, that the GC and GM are able to establish a SA
using protocols like ISAKMP and IPSec. The GC will specify the security
characteristics of the SA to the outside application. The level of protection
shall be as good or stronger than the SA characteristics specified in the
group policy token. A suggested minimal SA security level is confidentiality
with integrity.
To facilitate a well ordered group creation, security policy information
must be passed between the GC and the GMs using a group policy token. The
group policy token must specify the group's address, group permissions,
group join policy, group controller identity, group management information,
and digital signature of the controller.
3.1.1 Create Group Key
There are two options: key generation at a single point and shared generation.
In shared generation, the first member must cooperate with the GC to create
the group key. There are several established software-based key creation
protocols including Diffie-Hellman and RSA that support two group members
cooperating to create a cryptographic key. However, for this document, the
following discussion presents single-point key generation. Prior to the
first member join, the GC will have created the GTEK and the LKH array.
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 13]
INTERNET-DRAFT GSAKM Protocol April, 1999
Table 1: Message Definitions: Group Establishment
____________________________________________________________________
Message Name :Request to Join
Dissection : {HDR, Grp ID, GSA RQ} SigM, [CertM]
Payload Types : GSAKMP Header, Notification, Identification/Role,
Signature, [Certificate], [Certificate Request],
_________________[Vendor_ID]________________________________________
Message Name : Invitation
Dissection : {HDR, Policy Token, GSA RQ}SigC, [CertC],
[SigSC], [CertSC}
Payload Types : GSAKMP Header, Policy Token, Notification,
Signature, [Certificate], [Signature],
[Certificate], [Key Creation], [Certificate
_________________Request],_[Vendor_ID],_[Identification/Role]_______
Message Name : Invitation Response
Dissection : {HDR, GSA RS}SigM, [CertM], [RuleM]
Payload Types : GSAKMP Header, [Notification], Signature,
[Key Creation], [Certificate], [Vendor ID],
_________________[Identification/Role]______________________________
Message Name : Key Download
Dissection : {HDR,(GTEK, LKH)SigC}, [SigSC], [CertSC]
Payload Types : GSAKMP Header, Key Download, Signature, [Key
_________________Creation],_[Identification/Role],_[Vendor_ID]______
Message Name : Acknowledgment
Dissection : {HDR, ACK}SigM, [CertM]
Payload Types : GSAKMP Header, Notification, Signature,
_________________[Certificate],_[Vendor_ID]_________________________
3.1.2 Distribute Group Key
This function consists of four messages between the GC and the first member.
The initial message from the GC contains the following:
1. Signed group policy token,
2. GSA request, and
3. GC Certificate (optional).
The GM will receive this message and process it according to the provisions
of Mode 2. The GSA RQ contains the identity of the message source in enough
detail to allow the potential member to verify the signature. The GSA RQ
also contains the ID of the invited member. In Mode 2, the potential GM
will initially verify that the signature on the message to verify its authenticity.
If the message signature does not verify, the session is terminated.
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 14]
INTERNET-DRAFT GSAKM Protocol April, 1999
Table 2: Legend
_______________________________________________________________
SigC :Signature of Group Controller
SigSC : Signature of Subordinate Group Controller
SigM : Signature of Group Member
CertC : Certificate of Group Controller
CertSC : Certificate of Subordinate Group Controller
CertM : Certificate of Group Member
{}SigX :Indicates minimum fields used in Signature
[] Indicates an optional data item
If the message signature is authentic, then the potential GM will look at
who signed the message, verify the signer's authorities, and make a decision
to proceed. If the potential GM decides not to proceed, the session is
terminated.
If the potential GM has decided to continue, they will examine the information
within the policy token to determine if this is a group they are authorized
and interested in joining. If the decision is not to join, the session is
terminated.
If the potential GM is satisfied with the received information and decides
to join the group, he will pass back a message containing the following:
1. Signed GSA response, and
2. GM's certificate (optional).
The GC receives this message and processes it according to the provisions
of Mode 3. In Mode 3, the GC will verify the signature on the message to
ensure its authenticity. If the message signature does not verify, the
session is terminated.
If the message signature is verified, then the GC will then create and send
a signed message containing the GTEK and the LKH array to the GM.
The GM receives this message and processes it according to the provisions
in Mode 4. In Mode 4, the GM will verify the signature on the message to
ensure its authenticity. If the message signature does not verify, the
session is terminated.
If the message signature is verified, the GM will create a signed acknowledgment
message to return to the GC.
The GC receives the signed acknowledgment and processes it according to
the provision in Mode 5. In Mode 5, the GC will verify the signature on
the message to ensure its authenticity. If the message signature does not
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 15]
INTERNET-DRAFT GSAKM Protocol April, 1999
verify, the session is terminated.
If the message signature is verified, then the GC and GM have established a
Shared Keyed Group Session.
3.2 Group Maintenance
The Group Maintenance phase includes member joins and leaves, group rekey
activities, and the management of CR events. These activities are presented
in the following sections.
3.2.1 Member Joins/Leaves
The addition of group members to a previously established group will closely
follow the processing presented in Section 3.1 -- Group Establishment. With
the exception of the pure group establishment tasks (e.g., creation of policy
token, GTEK, and LKH array), an entity becomes a GM using the same message
exchanges described in Section 3.1.
A member who elects to voluntarily leave the group will be responsible for
destroying his key. Any further action for a voluntary leave should be
specifically addressed in the group's security policy.
3.2.2 CR Events
A CR event is any action, including compromises, that involves the creation
and dissemination of a new group key and/or LKH array. A complete presentation
of LKH events can be found in the draft document Logical Key Hierarchy (LKH)
Protocol.
Once it has been identified, using the group's security policy, that a CR
event has occurred, the GC must create and send a signed message containing
the GTEK and LKH array to the group.
Each GM who receives this message must verify the signature on the message
to ensure its authenticity. If the message signature does not verify, the
session is terminated. Upon verification the GM will find the appropriate
LKH key download packet and decrypt the information with a stored LKH key.
The components of a CR event message are shown in Table 3.
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 16]
INTERNET-DRAFT GSAKM Protocol April, 1999
Table 3: Message Definitions: Compromise Recovery Event
___________________________________________________________________
Message Name :CR Event
Dissection : {HDR, Grp ID, Policy Token, CR Array}SigC,
[CertC]
Payload Types : GSAKMP Header, [Policy Token], CR Event,
[Certificate], [Vendor ID], [Identification/Role],
___________________Signature_______________________________________
3.3 Group Removal/Destruction
At this point in the group's life-cycle, there has been a decision to destroy
the group and the notification is broadcast on a key management channel or
through a directory service.
The components of a Group Removal/Destruction message are shown in Table 4.
Table 4: Message Definitions: Group Removal and Destruction
___________________________________________________________________
Message Name :Group Removal/Destruction
Dissection : {HDR, Grp ID, Policy Token, Destruct}SigC,
[CertC]
Payload Types : GSAKMP Header, Policy Token, Notification,
___________________[Certificate],_[Vendor_ID],_[Identification/Role]_
4 Message formats
4.1 GSAKMP Header
The GSAKMP Header fields are shown in Figure 2 and defined below in Tables 5- 7.
Table 5: Group Identification Type Values
_Grp_ID_Type__Value__
IPSec IPv4 0
IPSec IPv6 1
TLS 2
SMIME 3
Other 4-255
Exchange Type (2 octets) - Indicates the type of exchange.
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 17]
INTERNET-DRAFT GSAKM Protocol April, 1999
0 1 2 3 4
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 ID Type! Group ID Value !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-++-+-+-+
~ ! Next Payload ! Ver ! Message ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-++-+
~ Msg ID ! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-++-+
! Length ! !
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+
Figure 2: GSAKMP Header Format
Table 6: Exchange Type Values
_Exchange_Type_______________Value_
Request to Join 0
Invitation 1
Invitation Response 2
Key Download 3
Acknowledgement 4
CR Event 5
Group Removal/Destruction 6
Other 7-255
Next Payload (1 octet) - Indicates the type of the first payload in the message.
The format for each payload is defined in the following sections. Table 7
presents the payload types.
Version (1 octet) - Indicates the version of the GSAKMP protocol in use.
Message ID (4 octets) - Unique Message Identifier used to identify protocol state
during negotiations. This value is randomly generated by the initiator of
communications for each group join activity. In the event of simultaneous
GSA establishments (i.e., collisions), the value of this field may be different
because they are independently generated and, thus, two group security associations
will progress toward establishment. However, it is unlikely there will be
absolute simultaneous establishments.
Length (4 octets) - Length of total message (header + payloads) in octets. Encryption
can expand the size of an GSAKMP message.
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 18]
INTERNET-DRAFT GSAKM Protocol April, 1999
Table 7: Payload Types
_Group_Identification_Type_(1_octet)_____
Next_Payload_Type Value
None 0
Policy Token/Certificate 1
Key Download Packet 2
CR even t 3
Identification/ Roles (ID) 4
Certificate (CERT) 5
Certificate Request (CR) 6
Hash (HASH) 7
Signature (SIG) 8
Notification (N) 9
Delete (D) 10
Vendor ID (VID) 11
Key Creation 12
Reserved 13 - 127
Private Use 128 -- 255
4.2 Generic Payload Header
Each GSAKMP payload defined in the following sections begins with a generic
header, shown in Figure 3, which provides a payload ``chaining`` capability
and clearly defines the boundaries of a payload. The Generic Payload Header
fields are defined as follows:
0 1 2 3 4
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! Next Payload ! Reserved ! Payload Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
~ !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 3: Generic Payload Header
Next Payload (1 octet) Identifier for the payload type of the next payload in
the message. If the current payload is the last in the message, then this
field will be 0. This field provides the ``chaining`` capability.
RESERVED (1 octet) Unused, set to 0.
Payload Length (4 octets) Length in octets of the current payload, including
the generic payload header.
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 19]
INTERNET-DRAFT GSAKM Protocol April, 1999
4.3 Data Attributes Payload
There are instances within GSAKMP where it is necessary to represent Data
Attributes. These Data Attributes are not a GSAKMP payload, but are contained
within GSAKMP payloads. The format of the Data Attributes provides the
flexibility for representation of many different types of information. There
can be multiple Data Attributes within a payload. The length of the Data
Attributes will either be 4 octets or defined by the Attribute Length field.
This is done using the Attribute Format bit described in Figure 4.
0 1 2 3 4
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! Attribute Type ! AF=0 Attribute Length !
! ! AF=1 Attribute Value !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! AF=0 Attribute Value !
! AF=1 Not Transmitted !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: Data Attributes Payload
The Data Attributes fields are defined as follows:
Attribute Type (2 octets) - Unique identifier for each type of attribute. The
most significant bit, or Attribute Format (AF), indicates whether the data
attributes follow the Type/Length/Value (TLV) format or a shortened Type/Value
(TV) format. If the AF bit is a zero (0), then the Data Attributes are of
the Type/Length/Value (TLV) form. If the AF bit is a one (1), then the Data
Attributes are of the Type/Value form.
Attribute Length (2 octets) - Length in octets of the Attribute Value. When
the AF bit is a one (1), the Attribute Value is only 2 octets and the Attribute
Length field is not present.
Attribute Value (variable length) - Value of the attribute associated with the
GSAKMP-specific Attribute Type. If the AF bit is a zero (0), this field
has a variable length defined by the Attribute Length field. If the AF bit
is a one (1), the Attribute Value has a length of 2 octets.
4.4 Policy Token Payload
The Policy Token Payload contains group specific information that describes
the group security relevant behaviors, access control parameters, and security
mechanisms this information may contain a digital signature(s) to prove
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 20]
INTERNET-DRAFT GSAKM Protocol April, 1999
authority and integrity of the information. Figure 5 shows the format of
the payload.
0 1 2 3 4
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! Next Payload ! Reserved ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! ID Type ! Policy Token Data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: Policy Token Payload Format
The Policy Token Payload fields are defined as follows:
Next Payload (1 octet) - Identifier for the payload type of the next payload
in the message. If the current payload is the last in the message, then
this field will be 0.
Reserved (1 octet) - Unused, set to 0.
Payload Length (2 octets) - Length in octets of the current payload, including
the generic payload header.
ID Type (1 octet) - Specifies the type of Policy Token being used. Table 8 identifies
the types of policy tokens.
Table 8: Policy Token Types
_ID_Type____________________________Value_
Establishment 0
Key Dissemination (Subordinate) 1
Access Control (change) 2
Rekey 3
Notification of GSAKMP resource 4
Compromise Recovery 5
Delete 6
Unassigned 7-255
Policy Token Data (variable length) - Contains Policy Token information. The
values for this field are group specific and the format is specified by the
ID Type field.
The payload type for the Policy Token Payload is one (1).
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 21]
INTERNET-DRAFT GSAKM Protocol April, 1999
0 1 2 3 4
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! Next Payload ! Reserved ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! ID Type ! Key Download Data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 6: Key Download Payload Format
4.5 Key Download Payload
The Key Download Payload contains group keys. These key download payloads
can have several security attributes applied to them based upon the security
policy of the group. Figure 6 shows the format of the payload.
If the security policy of the group dictates, the key download payload may
be encrypted with a key exchange key (KEK). The type of encryption used is
identified in the ID Type field. The group members may create the KEK using
the key creation method identified in the Key Creation Payload.
The Key Download Payload fields are defined as follows:
Next Payload (1 octet) - Identifier for the payload type of the next payload
in the message. If the current payload is the last in the message, then
this field will be 0.
Reserved (1 octet) - Unused, set to 0.
Payload Length (2 octets) - Length in octets of the current payload, including
the generic payload header.
ID Type (1 octet) - Specifies the type of Key Download being used. Figure 9
identifies the types of key download information.
Table 9: Key Download Information Types
_ID_Type______Value_
NONE 0
DES/ECB 1
3Des/ECB 2
Unassigned 3-255
Key Download Data (variable length) - Contains Key Download information. The
values for this field are group specific and the format is specified by the
ID Type field.
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 22]
INTERNET-DRAFT GSAKM Protocol April, 1999
0 1 2 3 4
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! # Key Datas ! KDD Type ! Length Key Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
~ ! Key Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 7: Key Download Data Payload Format
# Key Datas (1 octet) - Specifies the number of key data elements contained in
the payload - from 1 to n.
Key Download Data Type (1 octet) - Each key will have a type identifier associated
with it. This specifies what the key will be used for in the protocol.
Table 10: Key Download Data Types
_Key_Download_Data_Type___Value_
GTEK 0
LKH Key/Data 1
Unassigned 2-255
Length of Key (3 octets) - Defines the number of bytes for the key data that
follows.
The payload type for the Key Download Packet is two (2).
4.6 CR Event Payload
The CR Event Payload contains multiple keys encrypted in CR keys. These CR
Event payloads can have several security attributes applied to them based
upon the security policy of the group. Figure 8 shows the format of the
payload.
The CR Event Payload fields are defined as follows:
Next Payload (1 octet) - Identifier for the payload type of the next payload
in the message. If the current payload is the last in the message, then
this field will be 0.
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 23]
INTERNET-DRAFT GSAKM Protocol April, 1999
0 1 2 3 4
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! Next Payload ! Reserved ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! ID Type ! CR Event Data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 8: CR Event Payload Format
Reserved (1 octet) - Unused, set to 0.
Payload Length (2 octets) - Length in octets of the current payload, including
the generic payload header.
ID Type (1 octet) - Specifies the type of CR Event being used. Figure 11 presents
the types of CR events.
Table 11: CR Event Types
_ID_Type________________Value_
None 0
Group Recovery 1
Individual Recovery 2
Maintenance 3
Delete Group Key 4
Unassigned 5-255
CR Event Data (variable length) - Contains CR Event information. The values
for this field are group specific and the format is specified by the ID Type
field.
The CR Event payload type is three (3).
4.7 Identification/Role Payload
The Identification/Role Payload contains group-specific data used to exchange
identification information. This information is used for determining the
identities of subordinate controllers and may be used for determining authenticity
of information. Figure 9 shows the format of the Identification Payload.
The Identification/Role Payload fields are defined as follows:
Next Payload (1 octet) - Identifier for the payload type of the next payload
in the message. If the current payload is the last in the message, then
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 24]
INTERNET-DRAFT GSAKM Protocol April, 1999
0 1 2 3 4
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! Next Payload ! Reserved ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! ID Type ! Identification/Role Data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 9: Identification/Role Payload Format
this field will be 0.
Reserved (1 octet) - Unused, set to 0.
Payload Length (2 octets) - Length in octets of the current payload, including
the generic payload header.
ID Type (1 octet) - Specifies the type of Identification/Role being used. Table 12
identifies the types of identities/roles.
Table 12: Identity/Role Types
_ID_Type_______________________________Value_
Group Controller 0
Group and CR Controller 1
CR Controller 2
Subordinate Group Controller 3
Subordinate Group and CR Controller 4
Subordinate CR Controller 5
Member ID 6
Unassigned 7-255
Identification Data (variable length) - Contains identity information. The values
for this field are group-specific and the format is specified by the ID Type
field.
The payload type for the Identification Payload is four (4).
4.8 Certificate Payload
The Certificate Payload provides a means to transport certificates or other
certificate-related information via GSAKMP and can appear in any GSAKMP
message. Certificate payloads SHOULD be included in an exchange whenever an
appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 25]
INTERNET-DRAFT GSAKM Protocol April, 1999
to distribute certificates. The Certificate payload MUST be accepted at
any point during an exchange. Figure 10 shows the format of the Certificate
Payload.
0 1 2 3 4
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! Next Payload ! Reserved ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! Cert Encoding! Certificate Data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 10: Certificate Payload Format
The Certificate Payload fields are defined as follows:
Next Payload (1 octet) - Identifier for the payload type of the next payload
in the message. If the current payload is the last in the message, then
this field will be 0.
Reserved (1 octet) - Unused, set to 0.
Payload Length (2 octets) - Length in octets of the current payload, including
the generic payload header.
Certificate Encoding (1 octet) - This field indicates the type of certificate
or certificate-related information contained in the Certificate Data field.
Table 13 presents the types of certificate payloads.
Table 13: Certificate Payload Types
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
Certificate Data (variable length) - Actual encoding of certificate data. The
type of certificate is indicated by the Certificate Encoding field.
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 26]
INTERNET-DRAFT GSAKM Protocol April, 1999
The payload type for the Certificate Payload is five (5).
4.9 Certificate Request Payload
The Certificate Request Payload provides a means to request certificates
via GSAKMP and can appear in any message. Certificate Request payloads
SHOULD be included in an exchange whenever an appropriate directory service
(e.g., Secure DNS [DNSSEC]) is not available to distribute certificates.
The Certificate Request payload MUST be accepted at any point during the
exchange. The responder to the Certificate Request payload MUST send its
certificate, if certificates are supported, based on the values contained in
the payload. If multiple certificates are required, then multiple Certificate
Request payloads SHOULD be transmitted. Figure 11 shows the format of the
Certificate Request Payload.
0 1 2 3 4
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! Cert Type ! Certificate Authority !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 11: Certificate Request Payload Format
The Certificate Payload fields are defined as follows:
Next Payload (1 octet) - Identifier for the payload type of the next payload
in the message. If the current payload is the last in the message, then
this field will be 0.
Reserved (1 octet) - Unused, set to 0.
Payload Length (2 octets) - Length in octets of the current payload, including
the generic payload header.
Certificate Type (1 octet) - Contains an encoding of the type of certificate
requested.
Certificate Authority (variable length) - Contains an encoding of an acceptable
certificate authority for the type of certificate requested. As an example,
for an X.509 certificate this field would contain the Distinguished Name
encoding of the Issuer Name of an X.509 certificate authority acceptable
to the sender of this payload. This would be included to assist the responder
in determining how much of the certificate chain would need to be sent in
response to this request. If there is no specific certificate authority
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 27]
INTERNET-DRAFT GSAKM Protocol April, 1999
requested, this field SHOULD not be included.
The payload type for the Certificate Request Payload is six (6).
4.10 Signature Payload
The Signature Payload contains data generated by the digital signature function,
over some part of the message. Figure 12 shows the format of the Signature
Payload.
0 1 2 3 4
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! Next Payload ! Reserved ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! Sig Type ! Signature Payload Span !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! ! Signature Data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! ! Signer ID Type Length ! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! Signer ID Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 12: Signature Payload Format
The Signature Payload fields are defined as follows:
Next Payload (1 octet) - Identifier for the payload type of the next payload
in the message. If the current payload is the last in the message, then
this field will be 0.
Reserved (1 octet) - Unused, set to 0.
Payload Length (2 octets) - Length in octets of the current payload, including
the generic payload header.
Sig Type (1 octet) - Indicates the type of signature. Table 14 presents the
Signature Types.
Signature Payload Span (4 octets) - Identifies the information included in the
signature. The first two octets define the first signature payload. The
third and fourth octet define the last payload. Table 15 presents the Signature
Payload Span types.
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 28]
INTERNET-DRAFT GSAKM Protocol April, 1999
Table 14: Signature Types
_Signature_Type___Value_
DSS 0
Other 1-255
Table 15: Signature Context Types
_Signature_Payload_Span_Type_____Value_
No signature 0
Signature over generic header 1
Signature up to payload 2
Signature Data (variable length) - Data that results from applying the digital
signature function to the GSAKMP message and/or payload.
Signer ID Type Length (2 octets) - Length in octets of the Signer ID type.
Signer ID Type (variable length) - Data identifying the Signer's ID Type.
The payload type for the Signature Payload is eight (8).
4.11 Notification Payload
The Notification Payload can contain both GSAKMP and group specific data
and is used to transmit informational data, such as error conditions, to
an GSAKMP peer. It is possible to send multiple Notification payloads in
a single GSAKMP message. Figure 13 shows the format of the Notification
Payload.
0 1 2 3 4
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! Next Payload ! Reserved ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! Notify Message Type ! STATUS TYPE ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
~ Notification Data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 13: Notification Payload Format
The Notification Payload fields are defined as follows:
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 29]
INTERNET-DRAFT GSAKM Protocol April, 1999
Next Payload (1 octet) - Identifier for the payload type of the next payload
in the message. If the current payload is the last in the message, then
this field will be 0.
Reserved (1 octet) - Unused, set to 0.
Payload Length (2 octets) - Length in octets of the current payload, including
the generic payload header.
Notify Message Type (2 octets) - Specifies the type of notification message.
Status Type (1 octet) - Specifies the status of group with respect to originator
of notification.
Notification Data (variable length) - Informational or error data transmitted
in addition to the Notify Message Type. Values for this field are Domain
of Interpretation (DOI)-specific.
The payload type for the Notification Payload is nine (9).
4.12 Notify Message Types
Notification information can be messages specifying information. It can
also be status data that a process managing an SA database wishes to communicate
with a peer process. For example, a secure front end or security gateway
may use the Notify message to synchronize SA communication. Table 16 and 17
list the Notification Messages and their corresponding values.
Table 16: Notify Messages -- Status Types
_Status_______________________Value_
Not connected 0
Establishing group 1
Connected to group 2
Previously member of group 3
Reserved (future use) 4-255
4.13 Vendor ID Payload
The Vendor ID Payload contains a vendor defined constant. The constant is
used by vendors to identify and recognize remote instances of their implementations.
This mechanism allows a vendor to experiment with new features while maintaining
backwards compatibility. This is not a general extension facility of GSAKMP.
Figure 14 shows the format of the Vendor ID Payload.
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 30]
INTERNET-DRAFT GSAKM Protocol April, 1999
Table 17: Notify Messages Types
_Information_________________________Value_____
Invalid-Payload-Type 1
Situation-Not-Supported 2
Invalid-Major-Version 3
Invalid-Version 4
Invalid-Group-ID 5
Invalid-Message-ID 6
Payload-Malformed 7
Invalid-key-Information 8
Invalid-ID-Information 9
Invalid-Cert-Encoding 10
Invalid-Certificate 11
Cert-Type-Unsupported 12
Invalid-Cert-Authority 13
Authentication-Failed 14
Invalid-Signature 15
Notify-GSA-Lifetime 16
Certificate-Unavailable 17
Unequal-Payload-Lengths 18
Unauthorized Request 19
Unable To Take Requested Role 20
Group Deleted 21
Request Addition To Group 22
Acknowledgement 23
Invitation 24
Invitation Response 25
Reserved (future use) 26 - 8191
Private Use 8192 -- 16383
The Vendor ID payload is not an announcement from the sender that it will
send private payload types. A vendor sending the Vendor ID MUST not make
any assumptions about private payloads that it may send unless a Vendor ID
is received as well. Multiple Vendor ID payloads MAY be sent. An implementation
is NOT REQUIRED to understand any Vendor ID payloads. An implementation
is NOT REQUIRED to send any Vendor ID payload at all. If a private payload
was sent without prior agreement to send it, a compliant implementation may
reject a proposal with a notify message of type INVALID-PAYLOAD-TYPE.
The vendor defined constant MUST be unique. The choice of hash and text to
hash is left to the vendor to decide. As an example, vendors could generate
their vendor id by taking a plain (non-keyed) hash of a string containing
the product name, and the version of the product.
The Vendor ID Payload fields are defined as follows:
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 31]
INTERNET-DRAFT GSAKM Protocol April, 1999
0 1 2 3 4
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! Next Payload ! Reserved ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! Vendor ID (VID) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 14: Vendor ID Payload Format
Next Payload (1 octet) - Identifier for the payload type of the next payload
in the message. If the current payload is the last in the message, then
this field will be 0.
Reserved (1 octet) - Unused, set to 0.
Payload Length (2 octets) - Length in octets of the current payload, including
the generic payload header.
Vendor ID (variable length) - Hash of the vendor string plus version (as described
above).
The payload type for the Vendor ID Payload is eleven (11).
4.14 Key Creation Payload
The Key Creation Payload contains information used to create key encryption
keys for the key download payload. These key creation payloads can have
security attributes applied to them based upon the security policy of the
group. Figure 15 shows the format of the payload.
0 1 2 3 4
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! Next Payload ! Reserved ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
! ID Type ! Key Creation Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 15: Key Creation Payload Format
The Key Creation Payload fields are defined as follows:
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 32]
INTERNET-DRAFT GSAKM Protocol April, 1999
Next Payload (1 octet) - Identifier for the payload type of the next payload
in the message. If the current payload is the last in the message, then
this field will be 0.
Reserved (1 octet) - Unused, set to 0.
Payload Length (2 octets) - Length in octets of the current payload, including
the generic payload header.
ID Type (1 octet) - Specifies the type of Key Creation being used. Table 18
identifies the types of key download information.
Table 18: Types Of Key Creation Information
_ID_Type__________Value_
Diffie-Hellman 0
other 1-255
Key Creation Data (variable length) - Contains Key Creation information. The
values for this field are group specific and the format is specified by the
ID Type field.
The payload type for the Key Creation Packet is twelve (12).
5 State Diagram
Figure 16 presents the states encountered in the use of this protocol.
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 33]
INTERNET-DRAFT GSAKM Protocol April, 1999
(1)
| -----------------------------------(17)----------------
| | |
V V |
--------------(4)----------------> |
(idle) (queued) |
|
| ^ <------------------(5)----------- |
| | |
(2) (3) |
V | |
(Establishing Group) -(10)-> (GSA Established) -(16)->(Destroy GSA)
| ^ ^ | ^ ^
| | | | | |-----(15)----
| | | | -----(13)- |
(6)| ------(9)----- --(12)-- | |
|(7) | | | |
V | | V | |
(Establishing Group) (GSA Established) (Destroy GSA) (Destroy GSA)
Figure 16: GSAKMP State Diagram
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 34]
INTERNET-DRAFT GSAKM Protocol April, 1999
Table 19: State Transition Events
_________________________________________________________
Transition 1: Request to Join is received from TCP/IP
GUI Input
_____________________________Application_Input____________
_Transition_2:______________Group_SA_Required_____________
Transition 3: Failure of Peer SA service
Protocol Message failure
Incorrect format
Signature failed validation
Certificate on CRL
Access control invalid
Authorization invalid
_________________________________ Timeout_________________
Transition 4: Session required, but tables full
___________________Session required, but processor busy___
_Transition 5:____________________Timeout_________________
Transition 6: Request Peer SA service
___________________________Create Protocol Messages_______
_Transition 7:_____________Peer_SA_established____________
_Transition 8:______________________NA____________________
_Transition_9:__________Receipt_of_protocol_messages______
_Transition_10:_______Group_SA_establishment_complete_____
_Transition_11:______________________NA___________________
_Transition_12:_________LKH_event_message_completed_______
_Transition_13:______Group_SA_send_failure_notification___
_Transition_14:______________________NA___________________
_Transition_15:______________LKH_event_message____________
_Transition_16:___________Delete_Request_validated________
_Transition 17: Destruction complete
_________________________________________________________
Harney/Harder draft-harney-sparta-gsakmp-sec-00.txt [Page 35]
| PAFTECH AB 2003-2026 | 2026-04-23 00:30:13 |