idnits 2.17.1 draft-ietf-msec-tokenspec-sec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 6) being 75 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 39 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 40 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 191 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 177: '...ent of the token MUST reject the token...' RFC 2119 keyword, line 286: '...his field of the group's token MUST be...' RFC 2119 keyword, line 288: '...rial. Specifically, the rules MUST be...' RFC 2119 keyword, line 293: '...point, the member MUST verify that the...' RFC 2119 keyword, line 296: '...to act as Key Server MUST be rejected....' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 731 has weird spacing: '...ms used must ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 31, 2003) is 7543 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 1671 looks like a reference -- Missing reference section? '5' on line 1684 looks like a reference -- Missing reference section? '6' on line 1687 looks like a reference -- Missing reference section? '2' on line 1675 looks like a reference -- Missing reference section? '3' on line 1719 looks like a reference -- Missing reference section? '4' on line 1752 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SPARTA, Inc. H Harney (SPARTA) 2 INTERNET-DRAFT A Colegrove (SPARTA) 3 February 2003 P Lough (SPARTA) 4 U Meth (SPARTA) 6 GSAKMP Token Specification 7 draft-ietf-msec-tokenspec-sec-00.txt 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as ``work in progress''. 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Document expiration: August 31, 2003 30 Abstract 32 This document specifies the Group Secure Association Key Management 33 Protocol (GSAKMP) Policy Token. The Token provides a format to specify 34 a complete group security policy, necessary for formation of a group 35 secure association. The GSAKMP Token maintains procedures for key 36 dissemination, group membership, authorization and rekey. 38 Table of Contents 40 Status of this Memo..............................................1 41 Abstract.........................................................1 42 Table of Contents................................................2 43 1. Introduction..................................................4 44 2. GSAKMP Policy.................................................4 45 2.1. Identification..............................................5 46 2.1.1. Token ID..................................................5 47 2.1.1.1. Version.................................................5 48 2.1.1.2. Time Issued.............................................6 49 2.1.1.3. Protocol ID.............................................6 50 2.1.1.4. Group ID................................................6 51 2.2 Authorizations...............................................7 52 2.2.1. Owner Name ...............................................8 53 2.2.2. Rekey Controller Name.....................................8 54 2.2.3. Owner Name PKI............................................9 55 2.2.4. Rekey Controller Name PKI.................................10 56 2.2.5. Number of Key Server Authorizations.......................10 57 2.2.6. Key Server Authorization..................................11 58 2.3. Access Controls.............................................12 59 2.3.1. Inclusionary..............................................12 60 2.3.1.1. Permission..............................................12 61 2.3.1.2. Number of Name Rules....................................13 62 2.3.1.3. Name Rule...............................................13 63 2.3.1.4. Number of IP Rules......................................14 64 2.3.2. Exclusionary..............................................14 65 2.3.2.1. Permission..............................................14 66 2.3.2.2. Number of Name Rules ...................................14 67 2.3.2.3. Name Rule...............................................15 68 2.3.2.4. Number of IP Rules......................................16 69 2.4. Mechanisms..................................................16 70 2.4.1. Application SA............................................17 71 2.4.1.1. Encryption..............................................17 72 2.4.1.2. Rekey Information.......................................18 73 2.4.1.2.1. Frequency.............................................19 74 2.4.1.2.2. Rollover..............................................19 75 2.4.1.3. Group Specific Data.....................................20 76 2.4.1.3.1. IPSec Application Specific Data.......................20 77 2.4.1.3.1.1. Number of Secure Associations.......................20 78 2.4.1.3.1.2. Secure Associations.................................21 79 2.4.2. Unicast SA................................................23 80 2.4.2.1 Creation and Encryption..................................23 81 2.4.2.2 Rekey....................................................25 82 2.4.2.2.1. Frequency.............................................25 83 2.4.2.2.2. Rollover..............................................25 84 2.4.2.3. PKI.....................................................26 85 2.4.2.4. Signature...............................................26 86 2.4.3. Key Management SA.........................................27 87 2.4.3.1. Signature...............................................27 88 2.4.3.2. PKI.....................................................28 89 2.4.3.3. Rekey SA................................................28 90 2.4.3.3.1. Protocol and Encryption...............................28 91 2.4.3.3.2. Rekey.................................................29 92 2.4.3.3.2.1. Frequency...........................................30 93 2.4.3.3.2.2. Rollover............................................30 94 2.4.3.4. KEK SA..................................................31 95 2.4.3.4.1. p & g and Encryption..................................31 96 2.4.3.4.2. Rekey ................................................32 97 2.4.3.4.2.1. Frequency ..........................................32 98 2.4.3.4.2.2. Rollover............................................32 99 2.5. Signature...................................................33 100 2.5.1. Name......................................................33 101 2.5.2. PKI.......................................................33 102 2.5.3 Signature Data.............................................34 103 Acknowledgements.................................................35 104 References.......................................................35 105 Authors Address..................................................36 106 Appendix A ......................................................37 107 1. Introduction 109 Group communications, also commonly called multicast, refers to 110 communications in a group where the messages can be sent by any member 111 and are received by all members. The applications and encryption can 112 be implemented in a variety of ways and at numerous levels on the 113 network stack. Mailing list, conference calls and IP multicasting are 114 examples of group communication. Often the need for data protection 115 arises, which requires the group to handle the messages in a 116 consistently secure manner. To accomplish this, cryptographic 117 mechanisms and security policy must be shared and strictly followed by 118 the group as a whole. Because of this, special problems arise in 119 managing the cryptographic and policy material as it changes or as 120 the group changes. 122 The Group Secure Association Key Management Protocol (GSAKMP) [1] is 123 designed to manage these complex issues. GSAKMP provides symmetric key 124 to groups of users on a network. It provides mechanisms to disseminate 125 group policy, perform access control decisions during group 126 establishment, generate group key, recover from the compromise of a 127 group member, delegate group security functions, and destroy the group. 129 Fundamental to the security of the group communications is the GSAKMP 130 Policy Token, first presented in the GKMP [5], [6]. Group Policy define 131 s how and by whom data is handled in the group. It details the 132 authorizations needed to serve in special roles, it defines the access 133 control rules that govern the group, and it specifies the mechanisms 134 needed to protect communications. Furthermore, the token must be 135 signed by an authorized source and authenticated as such before use. 137 The need for consistent distributed enforcement of policy is critical 138 to the security of the group. The Policy Token is the vehicle by 139 which members can understand exactly how to manage the group data. 140 This paper details a relatively simple Policy Token to be used with GSAKMP. 141 The application specific data defined in Section 2.4.1.3.1.1 is to be 142 used with IPsec as the underlying protocol securing the group's 143 communications. GSAKMP's use of other secure protocols can be similarly 144 profiled. 146 2. GSAKMP Policy Token 148 The GSAKMP Security Policy Token is comprised of five fields 149 corresponding to the identification of the group, the authorizations 150 in it, the access control policies governing the group, the mechanisms 151 supporting secure communications, and the authentication of the contents 152 of the token. 154 Each of the fields of the GSAKMP Policy Token is further expanded in 155 following sections. 157 2.1. Identification 159 2.1.1. Token ID 161 The Token ID Field explicitly identifies the token as a GSAKMP token 162 for a particular group, generated at a particular time. The Token ID 163 Field consists of a Version Number indicating Token version, Protocol 164 ID indicating GSAKMP, Group ID consisting of IP Addresses and serial 165 numbers, and a Time Issued Field. 167 The time issued subfield of the TokenID is of particular interest in 168 the prevention of replay attacks. A replay attack is when an adversary 169 inserts an authenticated message or portion of a message into a new 170 run of a protocol. The time issued subfield of the GSAKMP Policy 171 Token helps to prevent such an attack. The receiver of a new token 172 can verify that the time issued is both appropriate for the policy 173 token and generated at a time later than the time issued on any 174 previous Policy Tokens for that group. This will prevent an adversary 175 from successfully replaying an old token and having it be accepted 176 as a new one. If a token with a bad timestamp is received, the 177 recipient of the token MUST reject the token. 179 2.1.1.1. Version 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 ! Version Length ! 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 ! Version ~ 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Version Length (4 bytes, unsigned integer) - Length in bytes of the 190 "Version" field. 192 Version (variable length, ASCII character) - This indicates the 193 version number of this token. The format for the version 1.1 token 194 is "V1.1". Note: the quotes are not included. 196 2.1.1.2. Time Issued 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 ! Time Length ! 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 ! Time Issued ~ 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Time Length (4 bytes, unsigned integer) - Length in bytes of the "Time 207 Issued" field. 209 Time Issued (variable length, ASCII character) - This indicates the 210 time the token was created in the format "Thu Jan 3 10:01:11 2002". 211 Note: the quotes are not included. 213 2.1.1.3. Protocol ID 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 ! ID Length ! 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 ! Protocol ID ~ 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 ID Length (4 bytes, unsigned integer) - Length in bytes of the 224 "Protocol ID" field. 226 Protocol ID (variable length, ASCII character) - This indicates 227 the version of the GSAKMP protocol this token is designed to work with. 228 To identify protocol ID 1, the format would be "P1.0". Note: the quote 229 s are not included. 231 2.1.1.4. Group ID 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 ! Group Serial Number ! 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 ! IP Type ! IP Length ~ 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 ~ ! IP Value ~ 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Group Serial Number (4 bytes, unsigned integer) - Integer chosen to 244 uniquely identify this group on the particular IP address. 246 IP Type (1 byte, unsigned integer) - Indicates the type of IP Address 247 that will be used for the following field. See Table 1 249 Table 1: IP Types 251 IP Type Value 252 _______________________ 253 IPv4 0 254 IPv6 1 255 Reserved 2-255 257 IP Length (4 bytes, unsigned integer) - Length in bytes of the "IP 258 Value" field. 260 IP Value (variable length, ASCII character) - This indicates the IP 261 address that will be used to identify this group. The format for IPv4 262 is "224.100.100.100". Note: the quotes are not included and that 263 digits are their character representations. 265 2.2. Authorizations 267 The Authorization Field allows group members to ensure that security 268 relevant actions are being performed by authorized group entities. This 269 ensures that a rogue group member does not mislead other group members 270 into an insecure action. 272 The Authorization Field identifies those who are authorized to act in 273 the special roles of Group Owner, Group Controller and Rekey Controller. 274 This identification may be done explicitly, where the fields contain 275 actual identifiers, or implicitly, using sets of rules to define the 276 policy allowing one to assume the roles listed. For example, a policy 277 rule might state that anyone in a particular domain is authorized to 278 act as a Key Server. Such a rule might be stated as 279 "{/o=acme/ou=responsible}." 281 Authorization Fields will fulfill various needs during the lifetime of 282 a group. Both new and current members will need to make use of the 283 authorization field to maintain the level of security of the 284 communications group. 286 For new or potential members, this field of the group's token MUST be 287 used as input into the decision for joining a particular group and for 288 the acceptance of keying material. Specifically, the rules MUST be 289 examined to determine whether they are stringent enough for the 290 potential member's security needs, and the member trusts the entities 291 that will be assuming the roles. Furthermore, upon acceptance of the 292 invitation to join the group, the member will receive the group 293 communication keys. At that point, the member MUST verify that the 294 Key Server sending the keys fit the profile indicated by the 295 Authorization Field. The integrity of keys received from someone not 296 entitled to act as Key Server MUST be rejected. 298 The most common use of this field will be by current group members. 299 Current group members use the Authorization Field upon receipt of key 300 management or administrative messages. Before acting upon these 301 messages, it must be determined that the sender did indeed have the 302 necessary permissions to initiate a given action. For example, an 303 unauthorized rekey message might have the result of placing a member 304 on an incorrect key, thereby denying them access to the group's 305 communications. If the sender did not have the necessary permissions, 306 the recipient MUST reject the key. 308 The authorizations section is made up of an Owner Name, Rekey 309 Controller Name, Owner PKI, Rekey Controller PKI and one or more Key 310 Server identifiers. The Key Server identifier is made up of a Rule and 311 a Rule PKI. 313 2.2.1. Owner Name 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 ! Serial Number ! 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 ! Owner Name Length ! 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 ! Owner Name ~ 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Serial Number (4 bytes, unsigned integer) - Integer representing the 326 X509V3 signature certificate serial number from the certificate 327 representing the Group Owner. 329 Owner Name Length (4 bytes, unsigned integer) - Length in bytes of the 330 "Owner Name" field. 332 Owner Name (variable length, ASCII character) - This field represents 333 the X509V3 Subject data in the format "/C=US/ST=MD/L=Columbia/O=SPARTA, 334 Inc./OU=ISSO/CN=loughp/Email=loughp@sparta.com". Note: the quotes 335 are not included. 337 2.2.2. Rekey Controller Name 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 ! Serial Number ! 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 ! Rekey Controller Name Length ! 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 ! Rekey Controller Name ~ 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Serial Number (4 bytes, unsigned integer) - Integer representing the 350 X509V3 signature certificate serial number from the certificate 351 representing the Rekey Controller member. 353 Rekey Controller Name Length (4 bytes, unsigned integer) - Length in 354 bytes of the "Rekey Controller. Name" field. 356 Rekey Controller Name (variable length, ASCII character) - This field 357 represents the X509V3 Subject data in the format "/C=US/ST=MD/L=Columbia 358 /O=SPARTA, Inc./OU=ISSO/CN=loughp/Email=loughp@sparta.com". Note: the 359 quotes are not included. 361 2.2.3. Owner Name PKI 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 ! PKI Type ! Pub Key Length ~ 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 ~ ! Serial Number ~ 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 ~ ! Owner Name PKI Length ~ 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 ~ ! Owner Name PKI ~ 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 PKI Type (1 byte, unsigned integer) - Indicates the type of certificate 376 being used to identify the issuer Public Key Infrastructure (PKI) used 377 to validate the Owner Name. See Table 2. 379 Table 2: PKI Type 381 PKI Certificate Type Value 382 __________________________________________ 383 None 0 384 PKCS #7 wrapped X.509 certificate 1 385 PGP Certificate 2 386 DNS Signed Key 3 387 X.509 Certificate -- Signature 4 388 X.509 Certificate - Key Exchange 5 389 Kerberos Tokens 6 390 Certificate Revocation List (CRL) 7 391 Authority Revocation List (ARL) 8 392 SPKI Certificate 9 393 X.509 Certificate - Attribute 10 394 Reserved 11 - 255 396 Public Key Length (4 bytes, unsigned integer) - Length in bits of the 397 public key used for this PKI. 399 Serial Number (4 bytes, unsigned integer) - Integer representing the 400 X509 certificate serial number from the Owner issuer certificate. 402 Owner Name PKI Length (4 bytes, unsigned integer) - Length in bytes of 403 the "Owner Name PKI" field. 405 Owner Name PKI (variable length, ASCII character) - This field 406 represents the X509 Subject data of the issuer certificate of the Owner Name 407 certificate (Section 2.2.1.) in the format "/C=US/ST=MD/L=Columbia/O= 408 SPARTA, Inc./CN=RootCA/Email=RootCA@sparta.com". Note: the quotes are 409 not included. 411 2.2.4. Rekey Controller Name PKI 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 ! PKI Type ! Pub Key Length ~ 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 ~ ! Serial Number ~ 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 ~ ! Rekey Controller Name PKI Length ~ 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 ~ ! Rekey Controller Name PKI ~ 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 PKI Type (1 byte, unsigned integer) - Indicates the type of certificate 426 being used to identify the issuer PKI used to validate the Rekey 427 Controller Name. See Table 2. 429 Public Key Length (4 bytes, unsigned integer) - Length in bits of the 430 public key used for this PKI. 432 Serial Number (4 bytes, unsigned integer) - Integer representing the 433 X509 certificate serial number from the Rekey Controller issuer 434 certificate. 436 Rekey Controller Name PKI Length (4 bytes, unsigned integer) - Length in 437 bytes of the "Rekey Controller Name PKI" field. 439 Rekey Controller Name PKI (variable length, ASCII character) - This 440 field represents the X509 Subject data of the issuer certificate of 441 the Rekey Controller Name certificate (Section 2.2.2) in the format 442 "/C=US/ST=MD/L=Columbia/O=SPARTA, Inc./CN=RootCA/Email=RootCA@sparta.com". 443 Note: the quotes are not included. 445 2.2.5. Number of Key Server Authorizations 447 Because multiple Key Server Authorizations are possible, this field is 448 included to indicate the number of authorizations that follow to allow 449 them to be more easily parsed. 451 0 1 452 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 ! Num KS Auths ! 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Number Key Server Authorizations (2 bytes, unsigned integer) - Number of 458 Key Server Authorizations that will follow. 460 2.2.6. Key Server Authorization 462 This section describes the rule used to determine an authorized Key 463 Server in the token. This field may be repeated as many times as 464 necessary and indicated in Section 2.2.5. Number of Key Server 465 Authorizations. 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 ! Rule Length ! 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 ! Rule ~ 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 ! PKI Type ! Pub Key Length ~ 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 ~ ! Serial Number ~ 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 ~ ! Issuer PKI Length ~ 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 ~ ! Issuer PKI ~ 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Rule Length (4 bytes, unsigned integer) - Length in bytes of the "Rule" 484 field. 486 Rule (variable length, ASCII character) - Textual representation of the 487 specific identifier to be used in determining Key Server Authorization. 488 To allow anyone with an X509V3 certificate with an Organization of 489 "SPARTA, Inc." the format would be "/O=SPARTA, Inc./". 490 Additionally, a single individual's certificate could be specified by 491 using the Common Name field such as "/CN=Joe User/". Note: the quotes 492 are not included. 494 PKI Type (1 byte, unsigned integer) - Indicates the type of certificate 495 being used to identify the issuer PKI used to validate the Rule. See 496 Table 2. 498 Public Key Length (4 bytes, unsigned integer) - Length in bits of the 499 public key used for this PKI. 501 Serial Number (4 bytes, unsigned integer) - Integer representing the 502 X509 certificate serial number for this issuer certificate. 504 Issuer PKI Length (4 bytes, unsigned integer) - Length in bytes of the 505 "Issuer PKI" field. 507 Issuer PKI (variable length, ASCII character) - This field represents 508 the X509 Subject data of the issuer certificate in the format 509 "/C=US/ST=MD/L=Columbia/O=SPARTA, Inc./CN=RootCA/Email=RootCA@sparta.com". 510 Note: the quotes are not included. 512 2.3. Access Controls 514 Access Controls are used to strictly define who can and cannot be a 515 member of this group and the mechanisms used to validate those rules. 516 Access Controls are made up of inclusionary and exclusionary rules. All 517 rules are cumulative; however, if a member passes both an inclusionary 518 and exclusionary rule, the exclusions MUST take precedence. For new or 519 potential members, this field of the group's token should be used as 520 input into the decision for joining a particular group and for the 521 acceptance of keying material. Specifically, the rules should be 522 examined to determine whether they are stringent enough for the 523 potential member's security needs, and the member trusts the entities 524 that will be assuming the roles. Access Controls each have a Permission, 525 one or more Name Rules and one or more IP Rules. The Permissions are 526 hierarchical in the traditional military sense where access at a higher 527 level encompasses all the access of the lower levels plus new ones, and 528 dominance rules apply. The Access List can also restrict access to 529 those in a particular knowledge group or groups. 531 2.3.1. Inclusionary 533 Inclusionary rules specify members, or groups of members, that are 534 allowed access to the group. 536 2.3.1.1. Permission 538 In the current SPARTA implementation of the GSAKMP Token, the Permission 539 field is used in conjunction with the Netscape Comment field available 540 in an X509V3 certificate. The Permissions are hierarchical in the 541 traditional military sense where access at a higher level encompasses 542 all the access of the lower levels plus new ones, and dominance rules 543 apply. If the token specifies a permission of 5 all certificates with 544 a Netscape Comment field of 5 OR HIGHER will pass this control. 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 ! Permission ! 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 Permission (4 bytes, unsigned integer) - Integer representing the 553 minimum necessary permission level indicated by the X509V3 Netscape 554 Comment field. Note: Valid values are between 0 and 10. 11 and above 555 are reserved for future use. 557 2.3.1.2. Number of Name Rules 559 0 1 560 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 ! Num Name Rules ! 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Number of Name Rules (2 bytes, unsigned integer) - Number of Name Rules 566 that will follow. 568 2.3.1.3. Name Rule 570 This section describes the rule used to determine who is authorized to 571 be a member based on the X509 Subject field. This field may be repeated 572 as many times as necessary and indicated in Section 2.3.1.2. Number of 573 Name Rules. 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 ! Rule Length ! 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 ! Rule ~ 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 ! PKI Type ! Pub Key Length ~ 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 ~ ! Serial Number ~ 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 ~ ! Issuer PKI Length ~ 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 ~ ! Issuer PKI ~ 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 Rule Length (4 bytes, unsigned integer) - Length in bytes of the "Rule" 592 field. 594 Rule (variable length, ASCII character) - Textual representation of the 595 specific identifier to be used in determining membership. To allow 596 anyone with an X509V3 certificate with an Organization of "SPARTA, Inc." 597 the format would be "/O=SPARTA, Inc./". Note: the quotes are not 598 included. 600 PKI Type (1 byte, unsigned integer) - Indicates the type of certificate 601 being used to identify the issuer PKI used to validate the Rule. See 602 Table 2. 604 Public Key Length (4 bytes, unsigned integer) - Length in bits of the 605 public key used for this PKI. 607 Serial Number (4 bytes, unsigned integer) - Integer representing the 608 X509 certificate serial number for this issuer certificate. 610 Issuer PKI Length (4 bytes, unsigned integer) - Length in bytes of the 611 "Issuer PKI" field. 613 Issuer PKI (variable length, ASCII character) - This field represents 614 the X509 Subject data of the issuer certificate in the format 615 "/C=US/ST=MD/L=Columbia/O=SPARTA, Inc./CN=RootCA/Email=RootCA@sparta.com". 616 Note: the quotes are not included. 618 2.3.1.4. Number of IP Rules 620 This section is for future expansion of the policy token and MUST be set 621 to zero. IP Rules may be used in the future to restrict a group member 622 to certain IP or range of IP addresses. 624 0 1 625 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 ! Num IP Rules ! 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Number of IP Rules (2 bytes, unsigned integer) - Unused. MUST be set to 631 zero. 633 2.3.2. Exclusionary 635 Exclusionary rules specify members or groups of members that are 636 explicitly denied access to this group. This is most useful when used 637 in conjunction with an inclusionary rule. If we want to allow all of 638 SPARTA, Inc. with the exception of one employee, we make an inclusionary 639 rule for SPARTA, Inc. and an exclusionary rule for that one employee. 641 2.3.2.1. Permission 643 This field is only used to allow the format of the exclusionary rules to 644 match that of the inclusionary rules. It has no current use and MUST 645 be set to zero. 647 0 1 2 3 648 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 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 ! Permission ! 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 Permission (4 bytes, unsigned integer) - Currently unused and MuST be set 654 to zero. 656 2.3.2.2. Number of Name Rules 658 0 1 659 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 ! Num Name Rules ! 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 Number of Name Rules (2 bytes, unsigned integer) - Number of Name Rules 664 that will follow. 666 2.3.2.3. Name Rule 668 This section describes the rule used to determine who is unauthorized to 669 be a member based on the X509 Subject field. This field may be repeated 670 as many times as necessary and indicated in Section 2.3.2.2. Number of 671 Name Rules. 673 0 1 2 3 674 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 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 ! Rule Length ! 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 ! Rule ~ 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 ! PKI Type ! Pub Key Length ~ 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 ~ ! Serial Number ~ 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 ~ ! Issuer PKI Length ~ 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 ~ ! Issuer PKI ~ 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 Rule Length (4 bytes, unsigned integer) - Length in bytes of the "Rule" 690 field. 692 Rule (variable length, ASCII character) - Textual representation of the 693 specific identifier to be used in determining membership. To disallow 694 anyone with an X509V3 certificate with an Organization of "SPARTA, Inc." 695 the format would be "/O=SPARTA, Inc./". Note: the quotes are not included. 697 PKI Type (1 byte, unsigned integer) - Indicates the type of certificate 698 being used to identify the issuer PKI used to validate the Rule. See 699 Table 2. 701 Public Key Length (4 bytes, unsigned integer) - Length in bits of the 702 public key used for this PKI. 704 Serial Number (4 bytes, unsigned integer) - Integer representing the 705 X509 certificate serial number for this issuer certificate. 707 Issuer PKI Length (4 bytes, unsigned integer) - Length in bytes of the 708 "Issuer PKI" field. 710 Issuer PKI (variable length, ASCII character) - This field represents 711 the X509 Subject data of the issuer certificate in the format 712 "/C=US/ST=MD/L=Columbia/O=SPARTA, Inc./CN=RootCA/Email=RootCA@sparta.com". 713 Note: the quotes are not included. 715 2.3.2.4. Number of IP Rules 717 This section is for future expansion of the policy token and MUST be set to 718 zero. IP Rules may be used in the future to restrict a group member to 719 certain IP or range of IP addresses. 721 0 1 722 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 ! Num IP Rules ! 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 Number of IP Rules (2 bytes, unsigned integer) - MUST be set to zero. 729 2.4. Mechanisms 731 The security services and related mechanisms used must be consistent 732 to maintain uniform data protection. For example, if the confidentiality 733 of data is protected by the Advanced Encryption Standard (AES) at one point 734 and by the Data Encryption Standard (DES) at another, the overall 735 protection afforded the data is only the strength offered by the weakest 736 mechanism. 738 The data mechanisms used to protect the various phases of the group 739 communications are specified in the Mechanisms Field of the GSAKMP Policy 740 Token. This field should be used as input into the decision for joining 741 a particular group. Specifically, the rules should be examined to determine 742 whether they are stringent enough for the potential member's security needs. 743 The actual Group Application Secure Association (SA), Unicast SA and Key 744 Management SAs are specified here. The mechanisms field will ensure that 745 the policy protecting communications is sufficient and consistent throughout 746 the group. 748 2.4.1. Application SA 750 The Application SA (Category-3 SA[2]) describes the protection afforded 751 Group Communications. The actual format of this field is largely determined 752 by the choice of security protocol for the protection of data. To this end, 753 section 2.4.1.3 defines Group Specific Data that is passed through to the 754 application. Allowing information to be passed through via the token ensures 755 both the authentication and group-wide distribution of the data. Mechanism 756 and mode choices for confidentiality and authentication, key determination, 757 key length and rekey must all be considered. Furthermore, agreed upon key 758 validity intervals (cryptoperiods) and possible data source authentication 759 MUST be specified. 761 2.4.1.1. Encryption 763 0 1 2 3 764 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 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 ! Algorithm ! Mode ! Key Length ! 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 ! Key Lifespan ! 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 ! Key Type ! Key CM ! 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 Algorithm (1 byte, unsigned integer) - Encryption algorithm to be used 774 for Group communication. See Table 3. 776 Table 3: Algorithm Type 778 Algorithm Value 779 _____________________________ 780 None 0 781 DES 1 782 3DES 2 783 RC2 3 784 RC4 4 785 Reserved 5-255 787 Mode (1 byte, unsigned integer) - Mode for the given algorithm. See 788 Table 4. 790 Table 4: Encryption Mode 792 Mode Value 793 __________________________ 794 None 0 795 CBC64 1 796 CFB64 2 797 CFB8 3 798 ECB 4 799 Reserved 5-255 801 Key Length (2 bytes, unsigned integer) - Length in bits of the GTEK. 803 Key Lifespan (4 bytes, unsigned integer) - Time in seconds the key is 804 to be valid. 806 Key Type (1 byte, unsigned integer) - Intended use for Encryption key. 807 See Table 5. 809 Table 5: Key Type 811 Key Type Value 812 __________________________ 813 None 0 814 GTEK 1 815 GKEK 2 816 CR 3 817 Reserved 4-255 819 Key Creation Methodology (1 byte, unsigned integer) - Indicates if the 820 key was generated by cooperative pair wise methodology or self generated. 821 See Table 6. 823 Table 6: Key Creation Methodology 825 Methodology Value 826 ___________________________ 827 None 0 828 Self 1 829 Pair 2 830 Reserved 3-255 832 2.4.1.2. Rekey Information 834 This section will describe the frequency and rollover information for 835 the Group key. The frequency indicates how often a rekey event should 836 occur for this key. It is set up similar to a Unix Cron job. Fields 837 exist for minute, hour, day, month, day of week and day interval. 838 A -1 in a field indicates that field is not used. The rollover section 839 describes the method to use during a key rollover and the number of 840 seconds that methodology should be used. 842 2.4.1.2.1. Frequency 844 0 1 2 3 845 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 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 ! Minutes ! 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 ! Hours ! 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 ! Day of Month ! 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 ! Month ! 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 ! Day of Week ! 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 ! Day Interval ! 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 Minutes (4 bytes, signed integer) - Time in seconds of Rekey. 862 Hours (4 bytes, signed integer) - Time in hours of Rekey. 864 Day of Month (4 bytes, signed integer) - Day of month of Rekey. 866 Month (4 bytes, signed integer) - Month of Rekey. 868 Day of Week (4 bytes, signed integer) - Day of Week of Rekey. 870 Day Interval (4 bytes, signed integer) - Day Interval of Rekey. 872 2.4.1.2.2. Rollover 874 The rollover section indicates what needs to be done on replacement of 875 key material. The time field will indicate how long the key being 876 replaced will be allowed to be used in conjunction with the new key 877 material. 879 0 1 2 3 880 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 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 ! Type ! Time ~ 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 ~ ! 885 +-+-+-+-+-+-+-+-+ 887 Type (1 byte, unsigned integer) - Type of Rollover mechanism to use. 888 See Table 7. 890 Table 7: Rollover Type 892 Type Value 893 ______________________ 894 Send New 0 895 Reserved 1-255 896 Time (4 bytes, unsigned integer) - Time in seconds to enforce Rollover 897 mechanism. 899 2.4.1.3. Group Specific Data 901 This section allows additional application specific data to be carried 902 by the token. The next section specifies the use with IPSec. Other 903 applications can be similarly specified. If no additional group specific 904 data is used, Type is zero, length is zero and there is no data section. 906 0 1 2 3 907 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 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 ! Type ! Length ~ 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 ~ ! Group Specific Data ~ 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 Type (1 byte, unsigned integer) - Type of Group Specific Data. See 915 Table 8. 917 Table 8: Group Specific Type 919 Type Value 920 ______________________ 921 None 0 922 IPSec 1 923 Reserved 2-255 925 Length (4 bytes, unsigned integer) - Length of Group Specific Data field. 926 Zero if none. 928 Data (variable, Group specific encoding) - Group Specific Data. 930 2.4.1.3.1 IPSec Application Specific Data 932 This section describes the Group Specific Data format for use with 933 IPSec implementations. Further discussion of the IPSec databases 934 populated by this information can be found in Appendix A. The Type 935 for Section 2.4.1.3. must be one (1) for this IPSec token implementation. 937 2.4.1.3.1.1. Number of Secure Associations 939 0 940 0 1 2 3 4 5 6 7 941 +-+-+-+-+-+-+-+-+ 942 ! Num SAs ! 943 +-+-+-+-+-+-+-+-+ 945 Number of Secure Associations (1 byte, unsigned integer) - Number of 946 Secure Associations that make up this set of IPSec rules. 948 2.4.1.3.1.2. Secure Associations 950 This is the data that will populate the SAD and SPD. This section will 951 be repeated the number of times indicated by Section 2.4.1.3.1.1. 953 0 1 2 3 954 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 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 ! SPI ! 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 ! Sec Protocol ! Direction ! ESP Algor ! Auth ! 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 ! Encap ! SA LifeType ! SA Lifetime ~ 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 ~ ! Source Address Length ~ 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 ~ ! Source Address ~ 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 ~ ~ Destination Address Length ~ 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 ~ ~ Destination Address ~ 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 ~ ~Trans Protocol ! Key Creation ! 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 SPI (4 bytes, unsigned integer) - Random number unique to this host for 974 this multicast address 976 Security Protocol (1 byte, unsigned integer) - Defines type of Security 977 Protocol. See Table 9. 979 Table 9. Security Protocol 981 Type Data 982 ______________________ 983 None 0 984 ESP 1 985 AH 2 986 Reserved 3-255 988 Direction (1 byte, unsigned integer) - Processing direction for this 989 rule. See Table 10. 991 Table 10. Direction 993 Type Data 994 _____________________ 995 Bypass 0 996 Incoming 1 997 Outgoing 2 998 Reserved 3-255 1000 ESP Algorithm (1 byte, unsigned integer) - Algorithm to be used if ESP 1001 mode is selected. See Table 11. 1003 Table 11. ESP Algorithm 1005 Type Data 1006 _____________________ 1007 None 0 1008 ESP-DES 1 1009 Reserved 2-255 1011 Authentication (1 byte, unsigned integer) - Algorithm to be used for 1012 authentication in AH only mode or for ESP authentication. See Table 12. 1014 Table 12. ESP Authentication 1016 Type Data 1017 _____________________ 1018 None 0 1019 HMAC-SHA 1 1020 HMAC-MD5 2 1021 Reserved 3-255 1023 Encapsulation Mode (1 byte, unsigned integer) - Encapsulation Mode used 1024 for this IPSec rule. See Table 13. 1026 Table 13. Encapsulation Mode 1028 Type Data 1029 _____________________ 1030 None 0 1031 Tunnel 1 1032 Reserved 2-255 1034 SA Lifetype (1 byte, unsigned integer) - Describes the way we will 1035 calculate the lifetime for this SA. Used in conjunction with SA 1036 Lifetime. See Table 14. 1038 Table 14. SA Lifetype 1040 Type Data 1041 _____________________ 1042 None 0 1043 Bytes 1 1044 Kilobytes 2 1045 Megabytes 3 1046 Packets 4 1047 Reserved 5-255 1049 SA Lifetime (4 bytes, unsigned integer) - Valid integer to be used in 1050 conjunction with the type found in SA Lifetype. 1052 Source Address Length (4 bytes, unsigned integer) - Length in bytes of 1053 the Source Address field. 1055 Source Address (variable length, ASCII character) - ASCII dotted decimal 1056 representation of source IP Address (for IPv4). 1058 Destination Address Length (4 bytes, unsigned integer) - Length in bytes 1059 of the Source Address field. 1061 Destination Address (variable length, ASCII character) - ASCII dotted 1062 decimal representation of destination IP Address (for IPv4). 1064 Transport Protocol (1 byte, unsigned integer) - Indicates the type of 1065 transport protocol used by this SA. See Table 15. 1067 Table 15. Transport Protocol 1069 Type Data 1070 _____________________ 1071 None 0 1072 TCP 1 1073 UDP 2 1074 Reserved 3-255 1076 Key Creation (1 byte, unsigned integer) - Indicates the key creation 1077 methodology for this SA. See Table 16. 1079 Table 16. Key Creation 1081 Type Data 1082 _____________________ 1083 Preplaced Key 0 1084 Reserved 1 - 255 1085 2.4.2. Unicast SA 1087 The Unicast SA defines the mechanisms that will be used any time two 1088 group members perform peer-to-peer communication. Mainly used during 1089 the GSAKMP "handshake" when a member attempts to join the group. This 1090 section will define the protocol to be used, the p and g values (if 1091 appropriate) and the encryption algorithm the resultant key will utilize. 1092 Rekey mechanisms will also be covered. The PKI defined for Unicast 1093 communication is also defined as well as necessary signature information. 1094 This section will be broken down into the Creation and Encryption, 1095 Rekey, PKI and Signature Info sections. 1097 2.4.2.1. Creation and Encryption 1099 0 1 2 3 1100 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 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 ! Protocol ! Group Est Type! p Length ~ 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 ~ ! p ~ 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 ! g ! 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 ! Algorithm ! Mode ! Key Length ! 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 ! Key Lifespan ! 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 ! Key Type ! Key CM ! 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 Protocol (1 byte, unsigned integer) - Represents the type of Secure 1116 Association being relied upon during unicast transactions. See Table 17. 1118 Table 17: Unicast Protocol 1120 Protocol Value 1121 ________________________ 1122 None 0 1123 IPSEC 1 1124 SSL 2 1125 SMIME 3 1126 ISAKMP 4 1127 Reserved 5-255 1129 Group Establishment Type (1 byte, unsigned integer) - Represents the 1130 type of GSAKMP (Full or Lite) group this token is created to establish. 1131 See Table 18. 1133 Table 18: Group Establishment Type 1135 Type Value 1136 _____________________ 1137 Full 0 1138 Lite 1 1139 Reserved 2-255 1141 p Length (4 bytes, unsigned integer) - Length in bytes of p. 1143 p (variable length, Hexadecimal data) - Hex representation of p value 1144 defined for this SA. 1146 g (4 bytes, unsigned integer) - g value defined for this SA. 1148 Algorithm (1 byte, unsigned integer) - Encryption algorithm to be used 1149 for Unicast communication. See Table 3. 1151 Mode (1 byte, unsigned integer) - Mode for the given algorithm. See 1152 Table 4. 1154 Key Length (2 bytes, unsigned integer) - Length in bits of the key. 1156 Key Lifespan (4 bytes, unsigned integer) - Time in seconds the key is to 1157 be valid. 1159 Key Type (1 byte, unsigned integer) - Intended use for Encryption key. 1160 See Table 5. 1162 Key Creation Methodology (1 byte, unsigned integer) - Indicates if the 1163 key was generated by cooperative pair wise methodology or self generated. 1164 See Table 6. 1166 2.4.2.2. Rekey 1168 This section will describe the frequency and rollover information for 1169 the Unicast key. The frequency indicates how often a rekey event should 1170 occur for this key. It is set up similar to a Unix Cron job. Fields 1171 exist for minute, hour, day, month, day of week and day interval. 1172 A -1 in a field indicates that field is not used. The rollover section 1173 describes the method to use during a key rollover and the number of 1174 seconds that methodology should be used. 1176 2.4.2.2.1. Frequency 1178 0 1 2 3 1179 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 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 ! Minutes ! 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 ! Hours ! 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 ! Day of Month ! 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 ! Month ! 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 ! Day of Week ! 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 ! Day Interval ! 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 Minutes (4 bytes, signed integer) - Time in seconds of Rekey. 1196 Hours (4 bytes, signed integer) - Time in hours of Rekey. 1198 Day of Month (4 bytes, signed integer) - Day of month of Rekey. 1200 Month (4 bytes, signed integer) - Month of Rekey. 1202 Day of Week (4 bytes, signed integer) - Day of Week of Rekey. 1204 Day Interval (4 bytes, signed integer) - Day Interval of Rekey. 1206 2.4.2.2.2. Rollover 1208 The rollover section indicates what needs to be done on replacement of 1209 key material. The time field will indicate how long the key being 1210 replaced will be allowed to be used in conjunction with the new key 1211 material. 1213 0 1 2 3 1214 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 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 ! Type ! Time ~ 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 ~ ! 1219 +-+-+-+-+-+-+-+-+ 1221 Type (1 byte, unsigned integer) - Type of Rollover mechanism to use. 1222 See Table 7. 1224 Time (4 bytes, unsigned integer) - Time in seconds to enforce Rollover 1225 mechanism. 1227 2.4.2.3. PKI 1229 This section describes the PKI that will be used to validate the 1230 certificates used in signing Unicast messages. 1232 0 1 2 3 1233 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 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 ! PKI Type ! Pub Key Length ~ 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 ~ ! Serial Number ~ 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 ~ ! Issuer PKI Length ~ 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 ~ ! Issuer PKI ~ 1242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 PKI Type (1 byte, unsigned integer) - Indicates the type of certificate 1245 being used to identify the issuer PKI used to validate certificates used 1246 in signing the unicast messages. See Table 2. 1248 Public Key Length (4 bytes, unsigned integer) - Length in bits of the 1249 public key used for this PKI. 1251 Serial Number (4 bytes, unsigned integer) - Integer representing the 1252 X509 certificate serial number for this issuer certificate. 1254 Issuer PKI Length (4 bytes, unsigned integer) - Length in bytes of the 1255 "Issuer PKI" field. 1257 Issuer PKI (variable length, ASCII character) - This field represents 1258 the X509 Subject data of the issuer certificate in the format 1259 "/C=US/ST=MD/L=Columbia/O=SPARTA, Inc./CN=RootCA/Email=RootCA@sparta.com". 1260 Note: the quotes are not included. 1262 2.4.2.4. Signature 1264 This section describes the algorithm and hash functions that will be 1265 used when signing unicast messages. 1267 0 1 1268 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 ! Algorithm ! Hash ! 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 Algorithm (1 byte, unsigned integer) - Encryption algorithm to be used 1274 for Unicast signatures. See Table 3. 1276 Hash (1 byte, unsigned integer) - Hash to be used for Unicast signatures. 1277 See Table 19. 1279 Table 19: Hash Algorithm 1281 Hash Value 1282 _______________________ 1283 SHA1 0 1284 MD5 1 1285 MD2 2 1286 Reserved 3-255 1288 2.4.3. Key Management SA 1290 Finally, the last portion of the Mechanisms Field corresponds to the 1291 protection afforded GSAKMP key management messages, including the 1292 possibility of issuing an amended token. This subfield is actually 1293 broken down into further fields: Rekey and KEK. The Rekey SA 1294 identifies the security mechanisms set up for key management messages. 1295 For cases in which Unicast messages may not be sufficiently protected, 1296 the KEK SA will allow further protection. Both of these correspond to 1297 the Category-2 SA of the GKMBB draft[2]. 1299 2.4.3.1. Signature 1301 This section describes the algorithm and hash functions that will be used 1302 when signing Key Management messages. 1304 0 1 1305 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 ! Algorithm ! Hash ! 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 Algorithm (1 byte, unsigned integer) - Encryption algorithm to be used 1311 for Key Management signatures. See Table 3. 1313 Hash (1 byte, unsigned integer) - Hash to be used for Key Management 1314 signatures. See Table 19. 1316 2.4.3.2. PKI 1318 This section describes the PKI that will be used to validate the 1319 certificates used in signing Key Management messages. 1321 0 1 2 3 1322 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 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 ! PKI Type ! Pub Key Length ~ 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 ~ ! Serial Number ~ 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 ~ ! Issuer PKI Length ~ 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 ~ ! Issuer PKI ~ 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 PKI Type (1 byte, unsigned integer) - Indicates the type of certificate 1334 being used to identify the issuer PKI used to validate certificates used 1335 in signing the Key Management messages. See Table 2. 1337 Public Key Length (4 bytes, unsigned integer) - Length in bits of the 1338 public key used for this PKI. 1340 Serial Number (4 bytes, unsigned integer) - Integer representing the 1341 X509 certificate serial number for this issuer certificate. 1343 Issuer PKI Length (4 bytes, unsigned integer) - Length in bytes of the 1344 "Issuer PKI" field. 1346 Issuer PKI (variable length, ASCII character) - This field represents 1347 the X509 Subject data of the issuer certificate in the format 1348 "/C=US/ST=MD/L=Columbia/O=SPARTA, Inc./CN=RootCA/Email=RootCA@sparta.com". 1349 Note: the quotes are not included. 1351 2.4.3.3. Rekey SA 1353 The Rekey SA describes the mechanisms used when sending Rekey messages. 1354 It is made up of Protocol and Encryption information and Rekey information. 1356 2.4.3.3.1. Protocol and Encryption 1358 0 1 2 3 1359 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 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 ! Protocol ! Algorithm ! Mode ! Key Length ~ 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 ~ ! Key Lifespan ~ 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 ~ ! Key Type ! Key CM ! 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 Protocol (1 byte, unsigned integer) - Protocol being used for Rekey. 1369 See Table 20. 1371 Table 20: Rekey Protocol 1373 Protocol Value 1374 ___________________________ 1375 None 0 1376 LKH 1 1377 OFT 2 1378 Reserved 3-255 1380 Algorithm (1 byte, unsigned integer) - Encryption algorithm to be used 1381 for Rekey communication. See Table 3. 1383 Mode (1 byte, unsigned integer) - Mode for the given algorithm. 1384 See Table 4. 1386 Key Length (2 bytes, unsigned integer) - Length in bits of the key. 1388 Key Lifespan (4 bytes, unsigned integer) - Time in seconds the key is 1389 to be valid. 1391 Key Type (1 byte, unsigned integer) - Intended use for Encryption key. 1392 See Table 5. 1394 Key Creation Methodology (1 byte, unsigned integer) - Indicates if the 1395 key was generated by cooperative pair wise methodology or self generated. 1396 See Table 6. 1398 2.4.3.3.2. Rekey 1400 This section will describe the frequency and rollover information for 1401 the Rekey key. The frequency indicates how often a rekey event should 1402 occur for this key. It is set up similar to a Unix Cron job. Fields 1403 exist for minute, hour, day, month, day of week and day interval. 1404 A -1 in a field indicates that field is not used. The rollover section 1405 describes the method to use during a key rollover and the number of 1406 seconds that methodology should be used. 1408 2.4.3.3.2.1. Frequency 1410 0 1 2 3 1411 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 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 ! Minutes ! 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 ! Hours ! 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 ! Day of Month ! 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 ! Month ! 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 ! Day of Week ! 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 ! Day Interval ! 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 Minutes (4 bytes, signed integer) - Time in seconds of Rekey. 1428 Hours (4 bytes, signed integer) - Time in hours of Rekey. 1430 Day of Month (4 bytes, signed integer) - Day of month of Rekey. 1432 Month (4 bytes, signed integer) - Month of Rekey. 1434 Day of Week (4 bytes, signed integer) - Day of Week of Rekey. 1436 Day Interval (4 bytes, signed integer) - Day Interval of Rekey. 1438 2.4.3.3.2.2. Rollover 1440 The rollover section indicates what needs to be done on replacement of 1441 key material. The time field will indicate how long the key being 1442 replaced will be allowed to be used in conjunction with the new key 1443 material. 1445 0 1 2 3 1446 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 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 ! Type ! Time ~ 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 ~ ! 1451 +-+-+-+-+-+-+-+-+ 1453 Type (1 byte, unsigned integer) - Type of Rollover mechanism to use. 1454 See Table 7. 1456 Time (4 bytes, unsigned integer) - Time in seconds to enforce Rollover 1457 mechanism. 1459 2.4.3.4. KEK SA 1461 This section will discuss the encryption mechanisms to be used when 1462 there is no underlying SA to rely upon for protection of the key 1463 material, or when the underlying SA is not considered strong enough 1464 for the purpose. This section will define the p and g values, the 1465 encryption information and the rekey information necessary to generate 1466 a cooperatively generated key. 1468 2.4.3.4.1. p & g and Encryption 1470 0 1 2 3 1471 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 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 ! Length ! 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 ! p ~ 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 ! g ! 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 ! Algorithm ! Mode ! Key Length ! 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 ! Key Lifespan ! 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 ! Key Type ! Key CM ! 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 Length (4 bytes, unsigned integer) - Length in bytes of p. 1488 p (variable length, Hexadecimal data) - Hex representation of p value 1489 defined for this SA. 1491 g (4 bytes, unsigned integer) - g value defined for this SA. 1493 Algorithm (1 byte, unsigned integer) - Encryption algorithm to be used 1494 for KEK communication. See Table 3. 1496 Mode (1 byte, unsigned integer) - Mode for the given algorithm. 1497 See Table 4. 1499 Key Length (2 bytes, unsigned integer) - Length in bits of the key. 1501 Key Lifespan (4 bytes, unsigned integer) - Time in seconds the key is 1502 to be valid. 1504 Key Type (1 byte, unsigned integer) - Intended use for Encryption key. 1505 See Table 5. 1507 Key Creation Methodology (1 byte, unsigned integer) - Indicates if the 1508 key was generated by cooperative pair wise methodology or self generated. 1509 See Table 6. 1511 2.4.3.4.2. Rekey 1513 This section will describe the frequency and rollover information for 1514 the KEK. The frequency indicates how often a rekey event should occur 1515 for this key. It is set up similar to a Unix Cron job. Fields exist 1516 for minute, hour, day, month, day of week and day interval. 1517 A -1 in a field indicates that field is not used. The rollover section 1518 describes the method to use during a key rollover and the number of 1519 seconds that methodology should be used. 1521 2.4.3.4.2.1. Frequency 1523 0 1 2 3 1524 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 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 ! Minutes ! 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 ! Hours ! 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 ! Day of Month ! 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 ! Month ! 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 ! Day of Week ! 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 ! Day Interval ! 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 Minutes (4 bytes, signed integer) - Time in seconds of Rekey. 1541 Hours (4 bytes, signed integer) - Time in hours of Rekey. 1543 Day of Month (4 bytes, signed integer) - Day of month of Rekey. 1545 Month (4 bytes, signed integer) - Month of Rekey. 1547 Day of Week (4 bytes, signed integer) - Day of Week of Rekey. 1549 Day Interval (4 bytes, signed integer) - Day Interval of Rekey. 1551 2.4.3.4.2.2. Rollover 1553 The rollover section indicates what needs to be done on replacement of 1554 key material. The time field will indicate how long the key being 1555 replaced will be allowed to be used in conjunction with the new key 1556 material. 1558 0 1 2 3 1559 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 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 ! Type ! Time ~ 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 ~ ! 1564 +-+-+-+-+-+-+-+-+ 1566 Type (1 byte, unsigned integer) - Type of Rollover mechanism to use. 1567 See Table 7. 1569 Time (4 bytes, unsigned integer) - Time in seconds to enforce Rollover 1570 mechanism. 1572 2.5. Signature 1574 The signature block field contains the information that verifies the 1575 authenticity of the policy token. It clearly identifies the signer of 1576 the token -- the Group Owner, the PKI information needed to establish 1577 what is the proper certificate to use for the signature verification, 1578 and the signature data. The signature covers all of the fields of the 1579 GSAKMP Policy Token including portions of the Signature Block Field 1580 itself. Because of this, any unauthorized change in the policy token 1581 will invalidate the signature. 1583 2.5.1. Name 1585 0 1 2 3 1586 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 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 ! Serial Number ! 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 ! Owner Name Length ! 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 ! Owner Name ~ 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 Serial Number (4 bytes, unsigned integer) - Integer representing the 1596 X509V3 signature certificate serial number from the certificate 1597 representing the Group Owner. 1599 Owner Name Length (4 bytes, unsigned integer) - Length in bytes of the 1600 "Owner Name" field. 1602 Owner Name (variable length, ASCII character) -This field represents 1603 the X509V3 Subject data in the format "/C=US/ST=MD/L=Columbia/O=SPARTA, 1604 Inc./OU=ISSO/CN=loughp/Email=loughp@sparta.com". Note: the quotes are 1605 not included. 1607 2.5.2. PKI 1609 0 1 2 3 1610 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 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 ! PKI Type ! Pub Key Length ~ 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 ~ ! Serial Number ~ 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 ~ ! Issuer PKI Length ~ 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 ~ ! Issuer PKI ~ 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 PKI Type (1 byte, unsigned integer) - Indicates the type of certificate 1622 being used to identify the issuer PKI used to validate certificates used 1623 in signing the token. See Table 2. 1625 Public Key Length (4 bytes, unsigned integer) - Length in bits of the 1626 public key used for this PKI. 1628 Serial Number (4 bytes, unsigned integer) - Integer representing the 1629 X509 certificate serial number for this issuer certificate. 1631 Issuer PKI Length (4 bytes, unsigned integer) - Length in bytes of the 1632 "Issuer PKI" field. 1634 Issuer PKI (variable length, ASCII character) - This field represents 1635 the X509 Subject data of the issuer certificate in the format 1636 "/C=US/ST=MD/L=Columbia/O=SPARTA, Inc./CN=RootCA/Email=RootCA@sparta.com". 1637 Note: the quotes are not included. 1639 2.5.3. Signature Data 1641 This is the only section of the token that the signature does not sign 1642 over. All fields up to this point are put through the signature 1643 algorithm and the resultant signature is appended in the format covered 1644 in this section. 1646 0 1 2 3 1647 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 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 ! Length of Signature Data ! 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 ! Signature Data ~ 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 Length of Signature Data (4 bytes, unsigned integer) - Total length in 1655 bytes of "Signature Data" field. 1657 Signature Data (variable length, Hexadecimal data) - Hexadecimal 1658 representation of signature data output by algorithm. 1660 Acknowledgements: 1662 The authors of this document would like to thank the following people 1663 for their contribution to this specification: 1665 Greg Bergren 1666 Mark Houchens 1667 Andy McFarland 1669 References: 1671 [1] H. Harney, A. Colegrove, E. Harder, U. Meth, R. Fleischer Group 1672 Secure Association Key Management Protocol, draft-ietf-msec-gsakmp-sec- 1673 00.txt, March 2001, Work in Progress. 1675 [2] H. Harney, M. Baugher, T. Hardjono, GKM Building Block: Group 1676 Security Association (GSA) Definition, September 2000, Work in Progress. 1678 [3] D. Piper, The Internet IP Security Domain of Interpretation for 1679 ISAKMP, RFC 2407, November 1998. 1681 [4] S. Kent, R. Atkinson, Security Architecture for the Internet 1682 Protocol, RFC 2401, November 1998. 1684 [5] H. Harney, C. Muckenhirn, Group Key Management Protocol (GKMP) 1685 Specification, RFC 2093, July 1997. 1687 [6] H. Harney, C. Muckenhirn, Group Key Management Protocol (GKMP) 1688 Architecture, RFC 2094, July 1997. 1690 Authors Addresses: 1692 Hugh Harney 1693 SPARTA, Inc. 1694 7075 Samuel Morse Drive 1695 Columbia, MD 21046 1696 (410) 872-1515 x203 1697 hh@sparta.com 1699 Andrea Colegrove 1700 SPARTA, Inc. 1701 7075 Samuel Morse Drive 1702 Columbia, MD 21046 1703 (410) 872-1515 x232 1705 Peter Lough 1706 SPARTA, Inc. 1707 7075 Samuel Morse Drive 1708 Columbia, MD 21046 1709 (410) 872-1515 x234 1711 Uri Meth 1712 SPARTA, Inc. 1713 7075 Samuel Morse Drive 1714 Columbia, MD 21046 1715 (410) 872-1515 x233 1716 Appendix A. 1718 The following section further describes the architecture for GSAKMP 1719 using IPsec [3] to provide Security Associations (SAs) for unicast 1720 communications and multicast group application communications. The 1721 authenticated GSAKMP policy token that was described in the previous 1722 section can clearly specify in its mechanisms field how the secure 1723 group can translate its needs to the IPsec specific database policies 1724 utilizing the following application specific information. 1726 GSAKMP creates an association between multiple entities connected by 1727 the Internet. The intent of the protocol is to use secure existing 1728 protocol services that are standardized for the Internet to facilitate 1729 setting up these secure groups. IPsec is one of the standard secure 1730 services that GSAKMP can use. The GSAKMP Policy Token defines the 1731 policy for protecting the multicast group traffic. IPsec can be used 1732 to protect communications between these group members. 1734 GSAKMP is an application layer protocol that exists above the IPsec 1735 network layer encryption engine. Configuration of GSAKMP must include 1736 configuration of the appropriate databases controlling IPsec. GSAKMP 1737 must ensure that IPsec processes its messages appropriately. To 1738 configure IPsec, GSAKMP will have to interact with the Security Policy 1739 Database (SPD) and the Security Association Database (SAD). 1741 Each group can have unique IPsec processing requirements for the unicast 1742 and multicast messages pertaining to that particular group. These 1743 group unique configurations must be conveyed to the IPsec controlling 1744 databases in a way that will allow correct IPsec processing for each 1745 groups' message. Special attention must be paid to the IPsec selector 1746 fields. The standard source and destination pair selectors are not 1747 adequate for multicast groups where multiple groups share the same 1748 destination address. 1750 A.1. IPsec Architecture 1752 The IPsec architecture document [4] identifies two databases used by 1753 IPsec - Security Policy Database (SPD) and Secure Association Database 1754 (SAD). The former specifies the policies that determine the disposition 1755 of all IP traffic (inbound or outbound) from a host, security gateway, 1756 or BITS or BITW IPsec implementation. The latter database contains 1757 parameters that are associated with each (active) security association. 1758 The information in these databases allows the IPsec protocol to process 1759 incoming and outgoing packets. 1761 A.1.1 SPD Inputs 1763 Purpose of the SPD (copied from RFC 2401) 1765 A security association is a management construct used to enforce a 1766 security policy in the IPsec environment. Thus an essential element of 1767 SA processing is an underlying Security Policy Database (SPD) that 1768 specifies what services are to be offered to IP datagrams and in what 1769 fashion. The form of the database and its interface are outside the 1770 scope of this specification. However, this section does specify certain 1771 minimum management functionality that must be provided, to allow a user 1772 or system administrator to control how IPsec is applied to traffic 1773 transmitted or received by a host or transiting a security gateway. 1775 The SPD must be consulted during the processing of all traffic 1776 (INBOUND and OUTBOUND), including non-IPsec traffic. In order to support 1777 this, the SPD requires distinct entries for inbound and outbound traffic 1778 . One can think of this as separate SPDs (inbound vs. outbound). In 1779 addition, a nominally separate SPD must be provided for each 1780 IPsec-enabled interface. 1782 An SPD must discriminate among traffic that is afforded IPsec protection 1783 and traffic that is allowed to bypass IPsec. This applies to the IPsec 1784 protection to be applied by a sender and to the IPsec protection that 1785 must be present at the receiver. For any outbound or inbound datagram, 1786 three processing choices are possible: discard, bypass IPsec, or apply 1787 IPsec. The first choice refers to traffic that is not allowed to exit 1788 the host, traverse the security gateway, or be delivered to an 1789 application at all. The second choice refers to traffic that is allowed 1790 to pass without additional IPsec protection. The third choice refers 1791 to traffic that is afforded IPsec protection, and for such traffic the 1792 SPD must specify the security services to be provided, protocols to be 1793 employed, algorithms to be used, etc. 1795 The critical elements of the SPD are: 1797 * Destination IP Address 1798 * Source IP Address 1799 * Name 1800 * Data sensitivity level 1801 * Transport Layer Protocol 1802 * Source and Destination (e.g., TCP/UDP) Ports 1803 * Specific IPsec processing 1804 * Specific IPsec Algorithms (spi, service, algorithm, mode) 1805 A.1.2 SAD Inputs 1807 Purpose of the SAD (copied from RFC 2401) 1809 In each IPsec implementation there is a nominal Security Association 1810 Database, in which each entry defines the parameters associated with one 1811 SA. Each SA has an entry in the SAD. For outbound processing, entries 1812 are pointed to by entries in the SPD. Note that if an SPD entry does not 1813 currently point to an SA that is appropriate for the packet, the 1814 implementation creates an appropriate SA (or SA Bundle) and links the 1815 SPD entry to the SAD entry (see Section 5.1.1). For inbound processing, 1816 each entry in the SAD is indexed by a destination IP address, IPsec 1817 protocol type, and SPI. The following parameters are associated with 1818 each entry in the SAD. This description does not purport to be a MIB, 1819 but only a specification of the minimal data items required to support 1820 an SA in an IPsec implementation. 1822 The critical elements of the SAD are: 1824 * SAD index 1825 * Outer Header's Destination IP address 1826 * IPsec Protocol 1827 * SPI 1828 * Sequence Number Counter 1829 * Sequence Counter Overflow [only outbound] 1830 * Anti-Replay Window: [only for inbound.] 1831 * AH Authentication algorithm, keys, etc. [REQUIRED for AH 1832 implementations] 1833 * ESP Encryption algorithm, keys, IV mode, IV, etc. [REQUIRED for 1834 ESP implementations] 1835 * ESP authentication algorithm, keys, etc [REQUIRED for ESP 1836 implementations] 1837 * Lifetime of this Security Association: Required 1838 * IPsec protocol mode: tunnel, transport or wildcard 1839 * Path MTU: [REQUIRED for all implementations but used only for 1840 outbound traffic]