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]