idnits 2.17.1 draft-ietf-msec-gsakmp-light-sec-01.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 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.) ** There are 265 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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 1069: '...ificate payloads SHOULD be included in...' RFC 2119 keyword, line 1071: '...ertificate payload MUST be accepted at...' RFC 2119 keyword, line 1130: '... Request payload MUST be accepted at a...' RFC 2119 keyword, line 1131: '...tificate Request payload MUST send its...' RFC 2119 keyword, line 1134: '...Request payloads SHOULD be transmitted...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- 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 (December 31, 2002) is 7786 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? 'HCHMF01' on line 1536 looks like a reference -- Missing reference section? 'RFC2543' on line 1590 looks like a reference -- Missing reference section? 'RFC2974' on line 1593 looks like a reference -- Missing reference section? 'HHMCD01' on line 1540 looks like a reference -- Missing reference section? 'WHA98' on line 1554 looks like a reference -- Missing reference section? 'RFC 2401' on line 1571 looks like a reference -- Missing reference section? 'MSST98' on line 1544 looks like a reference -- Missing reference section? 'FIPS 196' on line 1548 looks like a reference -- Missing reference section? 'DH77' on line 1551 looks like a reference -- Missing reference section? 'CertM' on line 479 looks like a reference -- Missing reference section? 'Certificate' on line 584 looks like a reference -- Missing reference section? 'CertC' on line 582 looks like a reference -- Missing reference section? 'Vendor ID' on line 584 looks like a reference -- Missing reference section? 'DNSSEC' on line 1129 looks like a reference -- Missing reference section? 'BMS' on line 1558 looks like a reference -- Missing reference section? 'RFC 2093' on line 1562 looks like a reference -- Missing reference section? 'RFC 2094' on line 1565 looks like a reference -- Missing reference section? 'RFC 2104' on line 1568 looks like a reference -- Missing reference section? 'RFC 2402' on line 1574 looks like a reference -- Missing reference section? 'RFC 2406' on line 1577 looks like a reference -- Missing reference section? 'RFC 2408' on line 1580 looks like a reference -- Missing reference section? 'RFC 2409' on line 1584 looks like a reference -- Missing reference section? 'RFC 2412' on line 1587 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 26 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPARTA, Inc. H Harney (SPARTA) 3 INTERNET-DRAFT A Schuett (NSA) 4 A Colegrove (SPARTA) 5 SPARTA, Inc., National Security Agency 6 draft-ietf-msec-gsakmp-light-sec-01.txt July 2002 8 GSAKMP Light 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. Internet-Drafts are working documents 14 of the Internet Engineering Task Force (IETF), its areas, and its working 15 groups. Note that other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months and 19 may be updated, replaced, or obsoleted by other documents at any time. It 20 is inappropriate to use Internet-Drafts as reference material or to cite 21 them other than as ``work in progress''. 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Document expiration: December 31, 2002 31 Abstract 33 A protocol specification must balance two often conflicting goals: 34 to produce as general a protocol as possible, and to produce a 35 simple protocol. The Group Secure Association Key Management 36 Protocol (GSAKMP) is a general protocol for creating and managing 37 cryptographic groups on a network. This document describes 38 the GSAKMP-Light (GL) profile, a way to shorten the number of 39 messages exchanged during secure group establishment. The GSAKMP 40 protocol assumed that group members joining a secure group had 41 no information about the specific security mechanisms used by the 42 group (for example, the key length, encryption protocol, etc). 43 GSAKMP-Light provides a profile for the case where group members 44 have been previously notified of these security mechanisms, used 45 for joining a group, during the group announcement or invitation. 46 This simplification removes 2 messages from the group establishment 47 portion of the GSAKMP protocol, eliminates the need for initiating 48 a unicast security association, and removes the need for many 49 of the optional fields of individual messages. The profile 50 does not sacrifice any of the security properties of the full 51 protocol. To facilitate the transmission of security mechanism 52 settings during session invitation or announcement, this document 53 also describes a useful default set of security algorithms and 54 configurations, Security Suite 1. Full specification of this suite 55 allows an entire set of algorithms and settings to be described 56 to prospective group members in a concise manner. Future security 57 suites can be defined as needed. 59 Copyright Notice 61 Copyright (c) The Internet Society (2002). All Rights Reserved. 63 Contents 65 1 Introduction 6 67 2 GSAKMP Light (GL) 7 68 2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3 Basis of security 9 71 4 Sequence of events 10 72 5 Security Policy 11 74 6 Security Suite 1 (SS1) 11 75 6.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 6.2 Definition Suite 1 . . . . . . . . . . . . . . . . . . . . . . . . 11 78 7 Message Structure 12 79 7.1 Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 7.2 Light Request to Join . . . . . . . . . . . . . . . . . . . . . . . 13 81 7.3 Light Key Download . . . . . . . . . . . . . . . . . . . . . . . . 13 82 7.4 Light Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 83 7.5 Group Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 7.5.1Member Joins/Leaves . . . . . . . . . . . . . . . . . . . . . . 14 85 7.5.2Rekey Events . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 7.5.3Group Removal/Destruction . . . . . . . . . . . . . . . . . . . 15 87 8 GSAKMP Payload Structure 15 88 8.1 GSAKMP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 8.2 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . . 18 90 8.3 Data Attributes Payload . . . . . . . . . . . . . . . . . . . . . . 18 91 8.4 Policy Token Payload . . . . . . . . . . . . . . . . . . . . . . . 19 92 8.5 Key Download Payload . . . . . . . . . . . . . . . . . . . . . . . 20 93 8.5.1GTEK Key Packet . . . . . . . . . . . . . . . . . . . . . . . . 21 94 8.5.2Rekey Key Packet . . . . . . . . . . . . . . . . . . . . . . . . 22 95 8.6 Rekey Event Payload . . . . . . . . . . . . . . . . . . . . . . . . 23 96 8.7 Identification Payload . . . . . . . . . . . . . . . . . . . . . . 24 97 8.8 Authorization Payload . . . . . . . . . . . . . . . . . . . . . . . 25 98 8.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . . . . . 26 99 8.10Certificate Request Payload . . . . . . . . . . . . . . . . . . . . 27 100 8.11Signature Payload . . . . . . . . . . . . . . . . . . . . . . . . . 28 101 8.12Notification Payload . . . . . . . . . . . . . . . . . . . . . . . 30 102 8.12.1Notification Data - Acknowledgement (ACK) Message Type . . . . . 32 103 8.13Vendor ID Payload . . . . . . . . . . . . . . . . . . . . . . . . . 33 104 8.14Key Creation Payload . . . . . . . . . . . . . . . . . . . . . . . 34 105 8.15Nonce Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 107 9 References and authors addesses 36 108 9.1 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 109 9.2 Authors Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 38 111 List of Figures 113 1 GSAKMP Light Ladder Diagram . . . . . . . . . . . . . . . . . . . . 12 114 2 GSAKMP Header Format . . . . . . . . . . . . . . . . . . . . . . . 16 115 3 Generic Payload Header . . . . . . . . . . . . . . . . . . . . . . 18 116 4 Data Attributes Payload . . . . . . . . . . . . . . . . . . . . . . 19 117 5 Policy Token Payload Format . . . . . . . . . . . . . . . . . . . . 19 118 6 Key Download Payload Format . . . . . . . . . . . . . . . . . . . . 20 119 7 Rekey Event Payload Format . . . . . . . . . . . . . . . . . . . . 23 120 8 Identification Payload Format . . . . . . . . . . . . . . . . . . . 24 121 9 Authorization Payload Format . . . . . . . . . . . . . . . . . . . 25 122 10 Certificate Payload Format . . . . . . . . . . . . . . . . . . . . 26 123 11 Certificate Request Payload Format . . . . . . . . . . . . . . . . 28 124 12 Signature Payload Format . . . . . . . . . . . . . . . . . . . . . 29 125 13 Notification Payload Format . . . . . . . . . . . . . . . . . . . . 30 126 14 Notification Data - Acknowledge Message Type Format . . . . . . . . 32 127 15 Vendor ID Payload Format . . . . . . . . . . . . . . . . . . . . . 34 128 16 Key Creation Payload Format . . . . . . . . . . . . . . . . . . . . 34 129 17 Nonce Payload Format . . . . . . . . . . . . . . . . . . . . . . . 35 131 List of Tables 133 1 Light Request to Join Message Definition . . . . . . . . . . . . . 13 134 2 Light Key Download Message Definition . . . . . . . . . . . . . . . 13 135 3 Light Acknowledgment Message Definition . . . . . . . . . . . . . . 14 136 4 Rekey Event Message Definition . . . . . . . . . . . . . . . . . . 15 137 5 Group Removal/Destruction Message Definition . . . . . . . . . . . 15 138 6 Group Identification Types . . . . . . . . . . . . . . . . . . . . 16 139 7 Payload Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 140 8 Exchange Types . . . . . . . . . . . . . . . . . . . . . . . . . . 17 141 9 Policy Token Types . . . . . . . . . . . . . . . . . . . . . . . . 20 142 10 Key Download Data Types . . . . . . . . . . . . . . . . . . . . . . 21 143 11 Rekey Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 23 144 12 Identification Types . . . . . . . . . . . . . . . . . . . . . . . 25 145 13 Authorization Types . . . . . . . . . . . . . . . . . . . . . . . . 26 146 14 Certificate Payload Types . . . . . . . . . . . . . . . . . . . . . 27 147 15 Signature Types . . . . . . . . . . . . . . . . . . . . . . . . . . 29 148 16 Notify Messages Types . . . . . . . . . . . . . . . . . . . . . . . 31 149 17 Notify Messages -- Status Types . . . . . . . . . . . . . . . . . . 32 150 18 Acknowledgement Types . . . . . . . . . . . . . . . . . . . . . . . 33 151 19 Types Of Key Creation Information . . . . . . . . . . . . . . . . . 35 152 20 Nonce Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 154 1 Introduction 156 The Group Secure Association Key Management Protocol (GSAKMP)[HCHMF01] 157 is a general protocol for creating and managing cryptographic groups on 158 a network. A cryptographic group is a logical association of users or 159 hosts that support a common security policy using shared cryptographic 160 keying material. The GSAKMP-Light (GL) profile of GSAKMP is a three 161 message version of GSAKMP that does not require an underlying secure unicast 162 security association. GL achieves this simplification by assuming that the 163 group creation process includes the transmission to prospective members of 164 an acceptable security suite for group establishment. 166 While GSAKMP provides mechanisms for cryptographic group creation, 167 other protocols may be used in conjunction with GSAKMP to allow various 168 applications to create groups according to their application-specific 169 requirements. For example, in a small-scale video conference the organizer 170 might use a session invitation protocol like SIP [RFC2543] to transmit 171 information about the time of the conference, the address of the session, 172 and the formats to be used. For a large-scale video transmission, the 173 organizer might use a multicast announcement protocol like SAP [RFC2974]. 174 In both of these cases, non-sensitive information about the security 175 mechanisms to be used in the cryptographic group establishment could 176 easily be transmitted to the prospective group members. As we will show, 177 including this information allows 2 messages to be removed from the group 178 establishment portion of GSAKMP, producing the GSAKMP-Light (GL) profile. 179 GSAKMP-Light provides a profile for the group establishment case where group 180 members have been previously notified of a set of security mechanisms during 181 the group announcement or invitation. 183 The GSAKMP protocol includes mechanisms for group policy dissemination, 184 group key dissemination, and group rekey operation. The GL profile shortens 185 the policy and key dissemination steps, but does not limit or decrease 186 the security of either of these operations. This profile of GSAKMP still 187 contains the necessary mechanisms to facilitate policy enforcement and 188 key management. Key management must be paired with policy enforcement 189 to produce a viable secure association. As in GSAKMP, GL uses the policy 190 definition stated in Internet Draft [HHMCD01] as the policy input to the 191 enforcement process. 193 While the GL profile does move some security profile information outside 194 of the protocol, the entire policy token is still transmitted within the 195 protocol. The transmission of a fully specified policy token to all joining 196 group members is what allows GSAKMP to support distributed architectures 197 and multiple data sources within a single cryptographic group. Distributed 198 architectures are supported because the policy token allows rule-based 199 allocation of Group Security Association actions to network resources. 200 Multiple data sources are supported because the inclusion of a policy token 201 and policy payloads allow group members to review the group access control 202 and authorization parameters. This member review process gives each member 203 and each potential source of data the ability to determine if the group 204 provides adequate protection for member data. 206 The GL profile uses the same rekey operation as GSAKMP. This document 207 repeats the specification for the rekey operation and GSAKMP payloads. This 208 is to avoid having two draft documents getting out of synchronization. 209 Like GSAKMP, the GL profile is provably secure, supports distributed 210 architectures, allows multiple data sources within a single cryptographic 211 group, and provides group management mechanisms. 213 To facilitate the transmission of security mechanism settings during session 214 invitation/announcement, this document also describes a useful default 215 set of security algorithms and configurations, Security Suite 1. Full 216 specification of this suite allows an entire set of algorithms and settings 217 to be described to prospective group members in a concise manner. Future 218 security suites can be defined as needed. 220 2 GSAKMP Light (GL) 222 2.1 Definitions 224 Group Member: A group member (GM) is any entity with access to the group 225 keys. Regardless of how a member becomes a part of the group or how the 226 group is structured, GMs will perform the following actions: 228 1. Validate the authorizations for security relevant actions; 230 2. Accept group keys from the GC; 232 3. Request group keys from the GC; 234 4. Maintain local Certificate Revocation Lists (CRLs); 236 5. Enforce the cooperative group policies as stated in the group policy 237 token; 239 6. Perform peer review of key management actions; and 241 7. Manage their local key. 243 Group Secure Association (GSA): A cryptographic group is a logical 244 association of users or hosts that share cryptographic key(s). This 245 group may be established to support associations between applications or 246 communication protocols. 248 Group Policy: The group policy completely describes the protection 249 mechanisms and security relevant behaviors of the group. This policy 250 must be commonly understood and enforced by the group for coherent secure 251 operations. 253 Policy Token/Certificate: The policy token is a data structure used to 254 disseminate group policy and the mechanisms to enforce it. The policy token 255 is issued and signed by an authorized source. Each member of the group must 256 verify the token, meet the group join policy, and enforce the policy of the 257 group. The group policy data element will contain a variety of information 258 including: 260 1. GSAKMP protocol format, 262 2. Key creation method, 264 3. Key dissemination policy, 266 4. Access control policy, 268 5. Group authorization policy, and 270 6. Compromise recovery policy. 272 The policy token layout will be fully presented in the Group Policy Token 273 Specification document. 275 Group Controller: The Group Controller (GC) is a group member with 276 authority to perform any critical protocol actions including: 278 1. Creating and distributing keys; 280 2. Maintain the Rekey infrastructure; and 282 3. Building and maintaining the Rekey arrays. 284 As the group evolves, it may become desirable to have multiple controllers 285 perform these functions (e.g., Rekey Controller and Group Key Controller). 287 Subordinate Group Controller (SGC): Any group member, as defined in 288 the group policy, and having the appropriate processing and trust 289 characteristics, has the potential to act as a Subordinate Group Controller 290 (SGC) thus allowing the group processing and communication requirements to 291 be distributed equitably throughout the network. If the group is structured 292 in such a way, the delegated group members would be identified via the 293 policy token. The SGCs may perform actions delegated to them by the GC 294 including: 296 1. Dissemination of the group key and 298 2. Management of the status of the local group. 300 The ease of managing a very large group may also be improved by delegating 301 the creation of subordinate LKH arrays Ref [WHA98] to the SGCs. The SGCs 302 would have the authority and mechanisms necessary to create and disseminate 303 the LKH arrays for the members under their control. A more detailed 304 discussion of LKH arrays may be found in the Logical Key Hierarchy (LKH) 305 Protocol document. 307 Peer-to-Peer SA: Peer-to-Peer SA keys can be created by using any number 308 of key generation protocols including the Internet Secure Association Key 309 Management Protocol (ISAKMP)/IPSec [RFC 2401] and HS/SSL. These protocols 310 rely on cooperative key generation algorithms and on peer review of 311 permissions. Modern SA protocols are specifically developed to support this 312 task. Once the peer-to-peer SA is established, the group protocol can use 313 that SA mechanism for secure confidential peer communications throughout the 314 life of the group. 316 GSA Keys: GSA keys can be created using strong randomization key generation 317 protocols. These protocols rely on a cooperatively conferred policy. 318 Once the group keys are created and disseminated to the group members, 319 the group protocol can use that SA mechanism for secure confidential group 320 communications throughout the life of the group. 322 Group Traffic Encryption Key (GTEK): The key or keys created for encrypting 323 the group data. 325 Logical Key Hierarchy (LKH) array: The group of keys created to facilitate 326 the LKH compromise recovery methodology. 328 Compromise Recovery: The act of recovering a secure operating state after 329 detecting that a group member cannot be trusted. 331 3 Basis of security 333 GSAKMP Light is based upon several existing protocols: ISAKMP [MSST98], 334 GSAKMP, FIPS Pub 196 [FIPS 196], and Diffie-Hellman key exchange [DH77]. 335 ISAKMP provided a flexible structure of chained payloads in support of 336 authenticated key exchange and security association management for diverse 337 pairwise communications. GSAKMP expanded upon these features to provide 338 policy enforcement features in support of diverse group communications, 339 and tunneling over existing security protocols. FIPS Pub 196 provides a 340 mutual authentication protocol. Finally, Diffie-Hellman provides dynamic 341 key exchange. 343 Using the GSAKMP payloads, GSAKMP Light provides an authenticated security 344 management protocol. Its message structure greatly parallels that of the 345 FIPS Pub 196 mutual authentication exchange. Two points of departure: 346 the first message of GSAKMP Light is signed and in the second and third 347 messages, a nonce and combined nonce (hash of the two) is provided. The 348 signature on the first message allows authenticated Diffie-Hellman, thereby 349 preventing man-in-the-middle attacks. The digested combined nonce is a 350 construct, which if a longer exchange were present would allow for only one 351 value to be used after the third message. 353 4 Sequence of events 355 The sequence of events for GL is straightforward. The sequence is: 357 1. Security suite definition is transmitted outside the protocol. 359 2. Light Request to Join (L-RTJ) 361 3. Light Key Download (L-KD) 363 4. Light Acknowledgement (L-ACK) 365 5. Group SA up and running 367 6. Group management 369 The announcement will contain at a minimum the security suite for GL. 370 Security Suite 1 is defined below. 372 The member will initiate the following series of 3 messages for group 373 establishment. 375 - Light Request to Join initiates the GL group establishment portion 376 of the protocol. L-RTJ contains a key creation field for use in group 377 establishment. 378 - Light Key Download contains a key creation field and encrypted Policy 379 Token and Key Download payloads. 380 - The Light Acknowledgement message completes the authentication of the 381 GCKS for the member. 383 Once a member has joined the group the GSA is considered up. 385 Group management messages are multicast in nature and include rekey, policy 386 changes, and group deletion. 388 5 Security Policy 390 GL recognizes that the distribution of a key is only relevant to the 391 security of a system in so far as it represents a valid enforcement of 392 security policy. 394 6 Security Suite 1 (SS1) 396 GL is designed to support architectures with a capability to announce or 397 otherwise prepublish the group establishment parameters. These group 398 establishment parameters must contain enough information for a group member 399 to configure GL. The SS1 defines the mandatory supported definition of 400 Category one exchanges for GL. 402 6.1 Assumptions 404 Assumption: There is a mechanism to either announce the Category 1 SA 405 mechanisms to potential group members, post the Cat 1 policy, or inform 406 group members of Cat 1 policy. 408 In the case of an announced Category 1 policy it is desirable to have 409 concise definitions of entire suites of algorithms and settings. To this 410 end the authors define the GSAKMP Light Suite 1. 412 6.2 Definition Suite 1 414 GSAKMP Light implementations must support the following suite of algorithms 415 and configurations. The following definition of Suite 1 borrows heavily 416 from IKE's Oakley group 2 definition and Oakley itself. 418 The GSAKMP Light suite 1 definition defines all the algorithm and 419 cryptographic definitions required to process the default mode of GSAKMP 420 Light. It is important to note that GSAKMP Light does not negotiate 421 these cryptographic modes. This definition is set by the Group Owner 422 via the Policy Token (passed during the GSAKMP Light exchange for member 423 verification purposes). 425 The GSAKMP Light Suite definition is: 427 Key download encryption algorithm definition: 428 Algorithm: 3DES 429 Mode: CBC64 430 Key Length: 192 bits 432 Policy Token encryption algorithm definition: 433 Algorithm: 3DES 434 Mode: CBC64 435 Key Length: 192 bits 437 The Key Creation definition is: 438 Algorithm type is Diffie Hellman 439 MODP group definition 440 g: 2 441 p: "FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1" 442 "29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD" 443 "EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245" 444 "E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED" 445 "EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381" 446 "FFFFFFFF FFFFFFFF" 448 NOTE: The p {\&} g values comes from rfc 2409, IKE, section 6.2 Second 449 Oakley Group, and p is 1024 bits long. 451 The digital signature algorithm is: 452 DSS-ASN1-DER 453 Hash algorithm is: 454 SHA-1 456 7 Message Structure 458 7.1 Flow Diagram 460 The Light Group Establishment Flow Diagram is shown in Figure 1: 462 CONTROLLER MESSAGE MEMBER 464 !<------------Request to Join-------------! 465 ! ! 466 !-------------Key Download--------------->! 467 ! ! 468 !<------------Acknowledgment--------------! 470 Figure 1: GSAKMP Light Ladder Diagram 472 7.2 Light Request to Join 474 The components of a Light Request to Join Message are shown in Table 1: 476 Table 1: Light Request to Join Message Definition 478 Message Name : L-RTJ 479 Dissection : {HDR, GrpID, Key Creation, Nonce_I} SigM, [CertM] 480 Payload Types : GSAKMP Header, Key Creation, Nonce, Signature, 481 [Certificate] 482 SigM : Signature of Group Member 483 CertM : Certificate of Group Member 484 {}SigX :Indicates minimum fields used in Signature 485 [] : Indicate an optional data item 487 7.3 Light Key Download 489 The components of a Light Key Download Message are shown in Table 2: 491 Table 2: Light Key Download Message Definition 493 Message Name : L-KD 494 Dissection : {HDR, GrpID, Member ID, Nonce_R, Nonce_C, Key 495 Creation, (Policy Token)*, (Key Download)*} SigC, 496 [CertC] 497 Payload Types : GSAKMP Header, Identification, Nonce, Key 498 Creation, Policy Token, Key Download, Signature, 499 [Certificate] 501 SigC : Signature of Group Controller 502 CertC : Certificate of Group Controller 503 {}SigX :Indicates minimum fields used in Signature 504 [] : Indicate an optional data item 505 (data)* : Indicates encrypted information 507 7.4 Light Acknowledgement 509 The components of a Light Acknowledgement Message are shown in Table 3: 511 7.5 Group Maintenance 513 The Group Maintenance phase includes member joins and leaves, group rekey 514 activities, and the management of Rekey events. These activities are 515 Table 3: Light Acknowledgment Message Definition 517 Message Name : Acknowledgment 518 Dissection : {HDR, GrpID, Nonce_C, ACK}SigM 519 Payload Types : GSAKMP Header, Nonce, Notification, Signature 521 SigM : Signature of Group Member 522 CertM : Certificate of Group Member 523 {}SigX :Indicates minimum fields used in Signature 525 presented in the following sections. 527 7.5.1 Member Joins/Leaves 529 The addition of group members to a previously established group will closely 530 follow the processing presented in Sections 7.1 through 7.4. With the 531 exception of the pure group establishment tasks (e.g., creation of policy 532 token, GTEK, and Rekey array), an entity becomes a GM using the same message 533 exchanges described in Sections 7.1 through 7.4. 535 A member who elects to voluntarily leave the group will be responsible for 536 destroying his key. Any further action for a voluntary leave should be 537 specifically addressed in the group's security policy. 539 7.5.2 Rekey Events 541 A Rekey event is any action, including compromises, that involves the 542 creation and dissemination of a new group key and/or Rekey information. 544 Once it has been identified, using the group's security policy, that a Rekey 545 event has occurred, the GC must create and send a signed message containing 546 the GTEK and Rekey array to the group. 548 Each GM who receives this message must verify the signature on the message 549 to ensure its authenticity. If the message signature does not verify, the 550 processing is terminated. GSAKMP sends a properly authenticated message 551 with a Notification Payload of type NACK to indicate termination. Upon 552 verification the GM will find the appropriate Rekey download packet and 553 decrypt the information with a stored Rekey key. 555 The components of a Rekey Event message are shown in Table 4: 557 Table 4: Rekey Event Message Definition 559 Message Name : Rekey Event 560 Dissection : {HDR, GrpID, [Policy Token], Rekey Array}SigC, 561 [CertC] 562 Payload Types : GSAKMP Header, [Policy Token], Rekey Event, 563 Signature, [Certificate], [Vendor ID] 565 SigC : Signature of Group Controller 566 CertC : Certificate of Group Controller 567 {}SigX :Indicates minimum fields used in Signature 568 [] : Indicate an optional data item 570 7.5.3 Group Removal/Destruction 572 At this point in the group's life-cycle, there has been a decision to 573 destroy the group and the notification is broadcast on a key management 574 channel or through a directory service. 576 The components of a Group Removal/Destruction message are shown in 5: 578 Table 5: Group Removal/Destruction Message Definition 580 Message Name : Group Removal/Destruction 581 Dissection : {HDR, GrpID, [Policy Token], Destruct}SigC, 582 [CertC] 583 Payload Types : GSAKMP Header, [Policy Token], Notification, 584 Signature, [Certificate], [Vendor ID] 586 SigC : Signature of Group Controller 587 CertC : Certificate of Group Controller 588 {}SigX :Indicates minimum fields used in Signature 589 [] : Indicate an optional data item 591 8 GSAKMP Payload Structure 593 8.1 GSAKMP Header 595 The GSAKMP Header fields are defined in Figure 2: 597 Group Identification Type (1 octet) - Table 6 presents the group 598 identification types. 600 Group Identification Value (8 octets) - Indicates the name/title of the 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 604 !Group ID Type ! Group ID Value ~ 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 606 ~ ~ 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 608 ~ ! Next Payload ! Version ! Exchange Type ! 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 610 ! Sequence ID ! 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 612 ! Length ! 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 615 Figure 2: GSAKMP Header Format 617 Table 6: Group Identification Types 619 Grp ID Type Value 620 _____________________ 622 IPSec IPv4 0 623 IPSec IPv6 1 624 TLS 2 625 SMIME 3 626 Other 4-255 628 group. 630 Next Payload (1 octet) - Indicates the type of the first payload in the 631 message. The format for each payload is defined in the following 632 sections. Table 7 presents the payload types. 634 Version (1 octet) - Indicates the version of the GSAKMP protocol in use. 636 Exchange Type (1 octet) - Indicates the type of exchange (also known as 637 the message type). Table 8 presents the exchange type values. 639 Sequence ID (4 octets) - Group Management replay protection field. 640 Sequence ID for group management messages. If not a group management 641 message, this value is set to zero (0). 643 Length (4 octets) - Length of total message (header + payloads) in octets. 644 Encryption can expand the size of a GSAKMP message. 646 Table 7: Payload Types 648 Next_Payload_Type Value 649 ___________________________________ 651 None 0 652 Policy Token 1 653 Key Download Packet 2 654 Rekey event 3 655 Identification 4 656 Authorization 5 657 Certificate 6 658 Certificate Request 7 659 Signature 9 660 Notification 10 661 Vendor ID 11 662 Key Creation 12 663 Nonce 13 664 Reserved 14 - 127 665 Private Use 128 -- 255 667 Table 8: Exchange Types 669 Exchange_Type Value 670 ____________________________________ 672 Request to Join 0 673 Invitation 1 674 Invitation Response 2 675 Key Download 3 676 Acknowledgement 4 677 Rekey Event 5 678 Group Removal/Destruction 6 679 No Message 7 680 Light Request to Join 8 681 Light Key Download 9 682 Other 10-255 684 8.2 Generic Payload Header 686 Each GSAKMP payload defined in the following sections begins with a generic 687 header, shown in Figure 3, which provides a payload ``chaining`` capability 688 and clearly defines the boundaries of a payload. The Generic Payload Header 689 fields are defined as follows: 691 0 1 2 3 692 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 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 694 ! Next Payload ! RESERVED ! Payload Length ! 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 697 Figure 3: Generic Payload Header 699 Next Payload (1 octet) - Identifier for the payload type of the next 700 payload in the message. If the current payload is the last in 701 the message, then this field will be 0. This field provides the 702 ``chaining`` capability. 704 RESERVED (1 octet) - Unused, set to 0. 706 Payload Length (2 octets) - Length in octets of the current payload, 707 including the generic payload header. 709 8.3 Data Attributes Payload 711 There are instances within GSAKMP where it is necessary to represent 712 Data Attributes. These Data Attributes are not a GSAKMP payload, but 713 are contained within GSAKMP payloads. The format of the Data Attributes 714 provides the flexibility for representation of many different types of 715 information. There can be multiple Data Attributes within a payload. 716 The length of the Data Attributes will either be 4 octets or defined by 717 the Attribute Length field. This is done using the Attribute Format bit 718 described in Figure 4. 720 The Data Attributes fields are defined as follows: 722 Attribute Type (2 octets) - Unique identifier for each type of attribute. 723 The most significant bit, or Attribute Format (AF), indicates whether 724 the data attributes follow the Type/Length/Value (TLV) format or a 725 shortened Type/Value (TV) format. If the AF bit is a zero (0), then the 726 Data Attributes are of the Type/Length/Value (TLV) form. If the AF bit 727 is a one (1), then the Data Attributes are of the Type/Value form. 729 0 1 2 3 730 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 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 732 ! Attribute Type ! AF=0 Attribute Length ! 733 ! ! AF=1 Attribute Value ! 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 735 ! AF=0 Attribute Value ~ 736 ! AF=1 Not Transmitted ~ 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 739 Figure 4: Data Attributes Payload 741 Attribute Length (2 octets) - Length in octets of the Attribute Value. 742 When the AF bit is a one (1), the Attribute Value is only 2 octets and 743 the Attribute Length field is not present. 745 Attribute Value (variable length) - Value of the attribute associated with 746 the GSAKMP-specific Attribute Type. If the AF bit is a zero (0), this 747 field has a variable length defined by the Attribute Length field. If 748 the AF bit is a one (1), the Attribute Value has a length of 2 octets. 750 8.4 Policy Token Payload 752 The Policy Token Payload contains group specific information that describes 753 the group security relevant behaviors, access control parameters, and 754 security mechanisms. This information may contain a digital signature(s) to 755 prove authority and integrity of the information. Figure 5 shows the format 756 of the payload. 758 0 1 2 3 759 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 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 761 ! Next Payload ! RESERVED ! Payload Length ! 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 763 ! ID Type ! Policy Token Data ~ 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 766 Figure 5: Policy Token Payload Format 768 The Policy Token Payload fields are defined as follows: 770 Next Payload (1 octet) - Identifier for the payload type of the next 771 payload in the message. If the current payload is the last in the 772 message, then this field will be 0. 774 0 1 2 3 775 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 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 777 ! Next Payload ! RESERVED ! Payload Length ! 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 779 ! Key Download Data ~ 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 782 Figure 6: Key Download Payload Format 784 RESERVED (1 octet) - Unused, set to 0. 786 Payload Length (2 octets) - Length in octets of the current payload, 787 including the generic payload header. 789 ID Type (1 octet) - Specifies the type of Policy Token being used. 790 Table 9 identifies the types of policy tokens. 792 Table 9: Policy Token Types 794 ID_Type Value 796 ______________________ 797 Group 0 798 Auxiliary 1 799 Reserved 2-63 800 Unassigned 64-255 802 Policy Token Data (variable length) - Contains Policy Token information. 803 The values for this field are group specific and the format is specified 804 by the ID Type field. 806 The payload type for the Policy Token Payload is one (1). 808 8.5 Key Download Payload 810 The Key Download Payload contains group keys. These key download payloads 811 can have several security attributes applied to them based upon the security 812 policy of the group. Figure 6 shows the format of the payload. 814 If the security policy of the group dictates, the key download payload may 815 be encrypted with a key exchange key (KEK). The type of encryption used is 816 specified in the Policy Token. The group members may create the KEK using 817 the key creation method identified in the Key Creation Payload. 819 The Key Download Payload fields are defined as follows: 821 Next Payload (1 octet) - Identifier for the payload type of the next 822 payload in the message. If the current payload is the last in the 823 message, then this field will be 0. 825 RESERVED (1 octet) - Unused, set to 0. 827 Payload Length (2 octets) - Length in octets of the current payload, 828 including the generic payload header. 830 Key Download Data (variable length) - Contains Key Download information. 832 Number of Key Packets (2 octets) -- Contains the total number of both 833 GTEK and Rekey arrays being passed in this data block. 835 For each Key Packet, the data format is as follows: 837 Key Download Data (KDD) Type (1 octet) -- Identifier for the Key 838 Data field of this Key Packet. See Table 10 for the possible 839 values of this field. 841 Table 10: Key Download Data Types 843 Key Download Data Type Value 844 ________________________________ 846 GTEK 0 847 Rekey 1 848 Unassigned 2-255 850 Key Download Length (2 octets) -- Length in octets of the Key 851 Packet data following this field. 853 Key Packet Data (variable length) -- Contains Key information. 854 The format of this field is specific depending on the value of 855 the Key Download Data field. 857 8.5.1 GTEK Key Packet 859 For a Key Download Data value of GTEK, the Key Packet Data field is 860 formatted as follows: 862 Key Type (1 octet) -- This is the encryption algorithm for which this key 863 data is to be used. This value is specified in the Policy Token. 865 Key Creation Date (4 octets) -- This is the time value of when this key 866 data was originally generated. 868 Key Expiration Date (4 octets) -- This is the time value of when this key 869 is no longer valid for use. 871 Key Handle (4 octets) -- This is the randomly generated value to uniquely 872 identify a key. 874 Key Data (variable length) -- This is the actual encryption key data, 875 which is dependent on the Key Type algorithm for its format. 877 8.5.2 Rekey Key Packet 879 GSAKMP currently uses the Logical Key Hierarchy (LKH) protocol for Rekey 880 operations. This Key Packet Data is assumed to contain LKH Array data of 881 the following format: 883 LKH Version (1 octet) -- Contains the version of the LKH protocol which 884 the data is formatted in. 886 Leaf ID (2 octets) -- This is the Leaf Node ID of the LKH sequence 887 contained in this Key Packet Data block. 889 Number of LKH Keys (2 octets) -- This value is the number of distinct LKH 890 keys in this sequence. 892 For each LKH key in the sequence, the data format is as follows: 894 LKH ID (2 octets) -- This is the position of this key in the binary 895 tree structure used by LKH. 897 Key Type (1 octet) -- This is the encryption algorithm for which this 898 key data is to be used. This value is specified in the Policy 899 Token. 901 Key Creation Date (4 octets) -- This is the time value of when this 902 key data was originally generated. 904 Key Expiration Date (4 octets) -- This is the time value of when this 905 key is no longer valid for use. 907 Key Handle (4 octets) -- This is the randomly generated value to 908 uniquely identify a key. 910 Key Data (variable length) -- This is the actual encryption key data, 911 which is dependent on the Key Type algorithm for its format. 913 The payload type for the Key Download Packet is two (2). 915 8.6 Rekey Event Payload 917 The Rekey Event Payload contains multiple keys encrypted in Rekey keys. 918 These Rekey Event payloads can have several security attributes applied to 919 them based upon the security policy of the group. Figure 7 shows the format 920 of the payload. 921 0 1 2 3 922 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 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 924 ! Next Payload ! RESERVED ! Payload Length ! 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 926 ! ID Type ! Rekey Event Data ~ 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 929 Figure 7: Rekey Event Payload Format 931 The Rekey Event Payload fields are defined as follows: 933 Next Payload (1 octet) - Identifier for the payload type of the next 934 payload in the message. If the current payload is the last in the 935 message, then this field will be 0. 937 RESERVED (1 octet) - Unused, set to 0. 939 Payload Length (2 octets) - Length in octets of the current payload, 940 including the generic payload header. 942 ID Type (1 octet) - Specifies the type of Rekey Event being used. 943 Table 11 presents the types of Rekey events. 945 Table 11: Rekey Event Types 947 ID_Type Value 948 ______________________________ 950 None 0 951 Group Recovery 1 952 Individual Recovery 2 953 Maintenance 3 954 Delete Group Key 4 955 Unassigned 5-255 957 Rekey Event Data (variable length) - Contains Rekey Event information. 959 The values for this field are group specific and the format is specified 960 by the ID Type field. The format for the LKH type of Rekey Event Data 961 is located in the appendix section. 963 The Rekey Event payload type is three (3). 965 8.7 Identification Payload 967 The Identification Payload contains entity-specific data used to 968 exchange identification information. This information is used for 969 determining the identities of negotiating members and may be used for 970 determining authenticity of information. Figure 8 shows the format of the 971 Identification Payload. 973 0 1 2 3 974 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 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 976 ! Next Payload ! RESERVED ! Payload Length ! 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 978 ! ID Type ! Identification Data ~ 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 981 Figure 8: Identification Payload Format 983 The Identification Payload fields are defined as follows: 985 Next Payload (1 octet) - Identifier for the payload type of the next 986 payload in the message. If the current payload is the last in the 987 message, then this field will be 0. 989 RESERVED (1 octet) - Unused, set to 0. 991 Payload Length (2 octets) - Length in octets of the current payload, 992 including the generic payload header. 994 ID Type (1 octet) - Specifies the type of Identification being used. 995 Table 12 identifies the types of identities. 997 Identification Data (variable length) - Contains identity information. 998 The values for this field are group-specific and the format is specified 999 by the ID Type field. 1001 The payload type for the Identification Payload is four (4). 1003 Table 12: Identification Types 1005 ID_Type Value 1006 _____________________________________________ 1008 Sender Distinguished Name 0 1009 Receiver Distinguished Name 1 1010 Hash of Sender Distinguished Name 2 1011 Hash of Receiver Distinguished Name 3 1012 Unassigned 4-255 1014 8.8 Authorization Payload 1016 The Authorization Payload contains group-specific data used to exchange role 1017 authorization information. This information is used for determining the 1018 authorization of entities within a group. Figure 9 shows the format of the 1019 Authorization Payload. 1021 0 1 2 3 1022 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 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1024 ! Next Payload ! RESERVED ! Payload Length ! 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1026 ! Auth Type ! Authorization Data ~ 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1029 Figure 9: Authorization Payload Format 1031 The Authorization Payload fields are defined as follows: 1033 Next Payload (1 octet) - Identifier for the payload type of the next 1034 payload in the message. If the current payload is the last in the 1035 message, then this field will be 0. 1037 RESERVED (1 octet) - Unused, set to 0. 1039 Payload Length (2 octets) - Length in octets of the current payload, 1040 including the generic payload header. 1042 Authorization Type (1 octet) - Specifies the type of role authorization 1043 being used. Table 13 identifies the types of roles. 1045 Authorization Data (variable length) - Contains authorization information. 1046 The values for this field are group-specific and the format is specified 1047 by the Authorization Type field. 1049 Table 13: Authorization Types 1051 Auth_Type Value 1052 ________________________________________________ 1054 Group Controller 0 1055 Group and Rekey Controller 1 1056 Rekey Controller 2 1057 Subordinate Group Controller 3 1058 Subordinate Group and Rekey Controller 4 1059 Subordinate Rekey Controller 5 1060 Member ID 6 1061 Unassigned 7-255 1063 The payload type for the Authorization Payload is five (5). 1065 8.9 Certificate Payload 1067 The Certificate Payload provides a means to transport certificates or other 1068 certificate-related information via GSAKMP and can appear in any GSAKMP 1069 message. Certificate payloads SHOULD be included in an exchange whenever an 1070 appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available 1071 to distribute certificates. The Certificate payload MUST be accepted at 1072 any point during an exchange. Figure 10 shows the format of the Certificate 1073 Payload. 1075 0 1 2 3 1076 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 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1078 ! Next Payload ! RESERVED ! Payload Length ! 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1080 ! Cert Encoding ! Certificate Data ~ 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1083 Figure 10: Certificate Payload Format 1085 The Certificate Payload fields are defined as follows: 1087 Next Payload (1 octet) - Identifier for the payload type of the next 1088 payload in the message. If the current payload is the last in the 1089 message, then this field will be 0. 1091 RESERVED (1 octet) - Unused, set to 0. 1093 Payload Length (2 octets) - Length in octets of the current payload, 1094 including the generic payload header. 1096 Certificate Encoding (1 octet) - This field indicates the type of 1097 certificate or certificate-related information contained in the 1098 Certificate Data field. Table 14 presents the types of certificate 1099 payloads. 1101 Table 14: Certificate Payload Types 1103 Certificate_Type Value 1104 _______________________________________________ 1106 None 0 1107 PKCS #7 wrapped X.509 certificate 1 1108 PGP Certificate 2 1109 DNS Signed Key 3 1110 X.509 Certificate -- Signature 4 1111 X.509 Certificate - Key Exchange 5 1112 Kerberos Tokens 6 1113 Certificate Revocation List (CRL) 7 1114 Authority Revocation List (ARL) 8 1115 SPKI Certificate 9 1116 X.509 Certificate -- Attribute 10 1117 Reserved 11 -- 255 1119 Certificate Data (variable length) - Actual encoding of certificate data. 1120 The type of certificate is indicated by the Certificate Encoding field. 1122 The payload type for the Certificate Payload is six (6). 1124 8.10 Certificate Request Payload 1126 The Certificate Request Payload provides a means to request certificates 1127 via GSAKMP and can appear in any message. Certificate Request payloads 1128 SHOULD be included in an exchange whenever an appropriate directory service 1129 (e.g., Secure DNS [DNSSEC]) is not available to distribute certificates. 1130 The Certificate Request payload MUST be accepted at any point during the 1131 exchange. The responder to the Certificate Request payload MUST send its 1132 certificate, if certificates are supported, based on the values contained 1133 in the payload. If multiple certificates are required, then multiple 1134 Certificate Request payloads SHOULD be transmitted. Figure 11 shows the 1135 format of the Certificate Request Payload. 1137 The Certificate Payload fields are defined as follows: 1139 Next Payload (1 octet) - Identifier for the payload type of the next 1140 0 1 2 3 1141 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 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1143 ! Next Payload ! RESERVED ! Payload Length ! 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1145 ! Cert Type ! Certificate Authority ~ 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1148 Figure 11: Certificate Request Payload Format 1150 payload in the message. If the current payload is the last in the 1151 message, then this field will be 0. 1153 RESERVED (1 octet) - Unused, set to 0. 1155 Payload Length (2 octets) - Length in octets of the current payload, 1156 including the generic payload header. 1158 Certificate Type (1 octet) - Contains an encoding of the type of 1159 certificate requested. 1161 Certificate Authority (variable length) - Contains an encoding of an 1162 acceptable certificate authority for the type of certificate requested. 1163 As an example, for an X.509 certificate this field would contain the 1164 Distinguished Name encoding of the Issuer Name of an X.509 certificate 1165 authority acceptable to the sender of this payload. This would be 1166 included to assist the responder in determining how much of the 1167 certificate chain would need to be sent in response to this request. If 1168 there is no specific certificate authority requested, this field SHOULD 1169 NOT be included. 1171 The payload type for the Certificate Request Payload is seven (7). 1173 8.11 Signature Payload 1175 The Signature Payload contains data generated by the digital signature 1176 function. The digital signature covers the Signature Payload Span and the 1177 Signature Payload up to the Signature Data. The exception to this is if 1178 the signature algorithm used is DSS with ASN.1/DER encoding. Due to the 1179 variable length of a DER encoding, the signature span across the signature 1180 payload itself only extends up to the signature data length field, not the 1181 signature data. Figure 12 shows the format of the Signature Payload. 1183 The Signature Payload fields are defined as follows: 1185 0 1 2 3 1186 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 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1188 ! Next Payload ! RESERVED ! Payload Length ! 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1190 ! Sig Type ! Signature Payload Span ~ 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1192 ~ ! Sig ID Role ! Signature Timestamp ~ 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1194 ~ ! Signer ID Length ! 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1196 ~ Signer ID Data ~ 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1198 ! Signature Length ! Signature Data ~ 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1200 ~ ~ 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1203 Figure 12: Signature Payload Format 1205 Next Payload (1 octet) - Identifier for the payload type of the next 1206 payload in the message. If the current payload is the last in the 1207 message, then this field will be 0. 1209 RESERVED (1 octet) - Unused, set to 0. 1211 Payload Length (2 octets) - Length in octets of the current payload, 1212 including the generic payload header. 1214 Signature Type (1 octet) -- Indicates the type of signature. Table 15 1215 presents the Signature Types. 1217 Table 15: Signature Types 1219 Signature Type Value 1220 _____________________________________ 1222 DSS with ASN.1/DER encoding 0 1223 DSS without encoding 1 1224 Other 2-255 1226 Signature Payload Span (4 octets) - Identifies the information included in 1227 the signature. The first two octets define the first signature payload. 1228 The third and fourth octet define the last payload. The payloads in the 1229 message are an ordered sequence beginning at the header, with a value 1230 of 0. If the signature payload itself is not in the signature span, you 1231 must still sign over the signature payload up to the signature data. 1233 Signature ID Role (1 octet) -- Specifies the type of Authorization (Role) 1234 being used. Refer to Table 13 for the types of authorization (role). 1236 Signature Timestamp (4 octets) -- Date and time that the digital signature 1237 was applied. 1239 Signer ID Length (2 octets) - Length in octets of the Signer' ID. 1241 Signer ID (variable length) -- Data identifying the Signer's ID (e.g., 1242 DN). 1244 Signature Length (2 octets) -- Length in octets of the Signature Data. 1246 Signature Data (variable length) - Data that results from applying the 1247 digital signature function to the GSAKMP message and/or payload. 1249 The payload type for the Signature Payload is nine (9). 1251 8.12 Notification Payload 1253 The Notification Payload can contain both GSAKMP and group specific data 1254 and is used to transmit informational data, such as error conditions, to 1255 a GSAKMP peer. It is possible to send multiple Notification payloads in 1256 a single GSAKMP message. Figure 13 shows the format of the Notification 1257 Payload. 1259 0 1 2 3 1260 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 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1262 ! Next Payload ! RESERVED ! Payload Length ! 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1264 ! Notify Message Type ! STATUS TYPE ! ~ 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1266 ~ Notification Data ~ 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1269 Figure 13: Notification Payload Format 1271 The Notification Payload fields are defined as follows: 1273 Next Payload (1 octet) - Identifier for the payload type of the next 1274 payload in the message. If the current payload is the last in the 1275 message, then this field will be 0. 1277 RESERVED (1 octet) - Unused, set to 0. 1279 Payload Length (2 octets) - Length in octets of the current payload, 1280 including the generic payload header. 1282 Notify Message Type (2 octets) - Specifies the type of notification 1283 message. Table 16 presents the Notify Message Types. 1285 Table 16: Notify Messages Types 1287 Information Value 1288 _______________________________________________ 1290 None 0 1291 Invalid-Payload-Type 1 1292 Situation-Not-Supported 2 1293 Invalid-Major-Version 3 1294 Invalid-Version 4 1295 Invalid-Group-ID 5 1296 Invalid-Message-ID 6 1297 Payload-Malformed 7 1298 Invalid-Key-Information 8 1299 Invalid-ID-Information 9 1300 Invalid-Cert-Encoding 10 1301 Invalid-Certificate 11 1302 Cert-Type-Unsupported 12 1303 Invalid-Cert-Authority 13 1304 Authentication-Failed 14 1305 Invalid-Signature 15 1306 Notify-GSA-Lifetime 16 1307 Certificate-Unavailable 17 1308 Unequal-Payload-Lengths 18 1309 Unauthorized Request 19 1310 Unable To Take Requested Role 20 1311 Group Deleted 21 1312 Request To Join 22 1313 Acknowledgement 23 1314 Invitation 24 1315 Invitation-Response 25 1316 Nack 26 1317 Reserved (future use) 27 - 8191 1318 Private Use 8192 -- 16383 1320 Status Type (1 octet) - Specifies the status of group with respect to 1321 originator of notification. Notification information specifies status 1322 data and can be used by a process managing a SA database to communicate 1323 with a peer process. For example, a secure front end or security 1324 gateway may use the Notify message to synchronize SA communication. 1325 Table 17 presents the Notification Message Status Types. 1327 Notification Data (variable length) - Informational or error data 1328 transmitted in addition to the Notify Message Type. Values for this 1329 Table 17: Notify Messages -- Status Types 1331 Status Value 1332 ____________________________________ 1334 Not connected 0 1335 Establishing group 1 1336 Connected to group 2 1337 Previously member of group 3 1338 Reserved (future use) 4-255 1340 field are Domain of Interpretation (DOI)-specific. 1342 The payload type for the Notification Payload is ten (10). 1344 8.12.1 Notification Data - Acknowledgement (ACK) Message Type 1346 The data portion of the ACK payload serves either for confirmation of 1347 correct receipt of the Key Download message, or, when needed, can provide 1348 non-repudiation of receipt when included in a signed message. Figure 14 1349 shows the format of the Notification Data - Acknowledge Message Type. 1351 0 1 2 3 1352 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 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1354 ! Ack Type ! Acknowledgement Data ~ 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1357 Figure 14: Notification Data - Acknowledge Message Type Format 1359 The Notification Data - Acknowledgement Message Type data fields are defined 1360 as follows: 1362 Ack Type (1 octet) - Specifies the type of acknowledgement message. 1363 Table 18 presents the Notify Acknowledgement Message Types. 1365 Simple - Data portion null. 1367 MD5 MAC - Data portion contains output of MD5 HMAC function [RFC 1368 2104]. Input to HMAC function is the Nonce_C value appended to the 1369 decrypted portion, sans encryption padding, of the Key Download 1370 payload of the received Key Download Packet. 1372 Table 18: Acknowledgement Types 1374 ACK_Type Value 1375 ____________________ 1377 Simple 0 1378 MD5 MAC 1 1379 SHA-1 HMAC 2 1380 Unassigned 3-255 1382 SHA-1 HMAC - Data portion contains output of SHA-1 HMAC function [RFC 1383 2104]. Input to HMAC function is the Nonce_C value appended to the 1384 decrypted portion, sans encryption padding, of the Key Download 1385 payload of the received Key Download Packet. 1387 8.13 Vendor ID Payload 1389 The Vendor ID Payload contains a vendor defined constant. The constant 1390 is used by vendors to identify and recognize remote instances of their 1391 implementations. This mechanism allows a vendor to experiment with new 1392 features while maintaining backwards compatibility. This is not a general 1393 extension facility of GSAKMP. Figure 15 shows the format of the Vendor ID 1394 Payload. 1396 The Vendor ID payload is not an announcement from the sender that it 1397 will send private payload types. A vendor sending the Vendor ID MUST 1398 NOT make any assumptions about private payloads that it may send unless 1399 a Vendor ID is received as well. Multiple Vendor ID payloads MAY be 1400 sent. An implementation is NOT REQUIRED to understand any Vendor ID 1401 payloads. An implementation is NOT REQUIRED to send any Vendor ID payload 1402 at all. If a private payload was sent without prior agreement to send it, a 1403 compliant implementation may reject a proposal with a notify message of type 1404 INVALID-PAYLOAD-TYPE. 1406 The vendor defined constant MUST be unique. The choice of hash and text to 1407 hash is left to the vendor to decide. As an example, vendors could generate 1408 their vendor id by taking a plain (non-keyed) hash of a string containing 1409 the product name, and the version of the product. 1411 The Vendor ID Payload fields are defined as follows: 1413 Next Payload (1 octet) - Identifier for the payload type of the next 1414 payload in the message. If the current payload is the last in the 1415 message, then this field will be 0. 1417 RESERVED (1 octet) - Unused, set to 0. 1419 0 1 2 3 1420 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 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1422 ! Next Payload ! RESERVED ! Payload Length ! 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1424 ! Vendor ID (VID) ~ 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1427 Figure 15: Vendor ID Payload Format 1429 Payload Length (2 octets) - Length in octets of the current payload, 1430 including the generic payload header. 1432 Vendor ID (variable length) - Hash of the vendor string plus version (as 1433 described above). 1435 The payload type for the Vendor ID Payload is eleven (11). 1437 8.14 Key Creation Payload 1439 The Key Creation Payload contains information used to create key encryption 1440 keys. These key creation payloads can have security attributes applied 1441 to them based upon the security policy of the group. Figure 16 shows the 1442 format of the payload. 1444 0 1 2 3 1445 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 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1447 ! Next Payload ! RESERVED ! Payload Length ! 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1449 ! ID Type ! Key Creation Data ~ 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1452 Figure 16: Key Creation Payload Format 1454 The Key Creation Payload fields are defined as follows: 1456 Next Payload (1 octet) - Identifier for the payload type of the next 1457 payload in the message. If the current payload is the last in the 1458 message, then this field will be 0. 1460 RESERVED (1 octet) - Unused, set to 0. 1462 Payload Length (2 octets) - Length in octets of the current payload, 1463 including the generic payload header. 1465 ID Type (1 octet) - Specifies the type of Key Creation being used. 1466 Table 19 identifies the types of key download information. 1468 Table 19: Types Of Key Creation Information 1470 ID_Type Value 1471 ________________________ 1473 Reserved 0 1474 Diffie-Hellman 1 1475 other 2-255 1477 Key Creation Data (variable length) - Contains Key Creation information. 1478 The values for this field are group specific and the format is specified 1479 by the ID Type field. 1481 The payload type for the Key Creation Packet is twelve (12). 1483 8.15 Nonce Payload 1485 The Nonce Payload contains random data used to guarantee freshness during an 1486 exchange and protect against replay attacks. Figure 17 shows the format of 1487 the Nonce Payload. 1488 0 1 2 3 1489 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 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1491 ! Next Payload ! RESERVED ! Payload Length ! 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1493 ! Nonce Type ! Nonce Data ~ 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 1496 Figure 17: Nonce Payload Format 1498 The Nonce Payload fields are defined as follows: 1500 Next Payload (1 octet) - Identifier for the payload type of the next 1501 payload in the message. If the current payload is the last in the 1502 message, then this field will be 0. 1504 RESERVED (1 octet) - Unused, set to 0. 1506 Payload Length (2 octets) - Length in octets of the current payload, 1507 including the generic payload header. 1509 Nonce Type (1 octet) - Specifies the type of Nonce being used. Table 20 1510 identifies the types of nonces. 1512 Table 20: Nonce Types 1514 Nonce_Type Value Definition 1515 __________________________________________________________________________ 1517 None 0 1518 Initiator 1 1519 Responder 2 1520 Combined 3 Hash ( Append (Initiator_Value, Responder_Value) ) 1521 Unassigned 4-255 1523 Nonce Data (variable length) - Contains the nonce information. The values 1524 for this field are group-specific and the format is specified by the 1525 Nonce Type field. If no group-specific information is provided, the 1526 minimum length for this field is 4 bytes. 1528 The payload type for the Nonce Payload is thirteen (13). 1530 9 References and authors addesses 1532 The following references were used in the preparation of this document. 1534 9.1 References 1536 [HCHMF01] H. Harney, A. Colegrove, E. Harder, U. Meth, R. Fleischer, Group 1537 Secure Association Key Management Protocol, draft-ietf-msec-gsakmp-sec-00, 1538 March 2001 1540 [HHMCD01] , Thomas Hardjono, Hugh Harney, Pat McDaniel, Andrea Colgrove, 1541 Pete Dinsmore, Group Security Policy Token: Definition and Payloads', 1542 draft-ietf-msec-gspt-00.txt, Work in progress. 1544 [MSST98] Maughan, D., Schertler, M., Schneider, M., and J. Turner, 1545 ``Internet Security Association and Key Management Protocol (ISAKMP)'', RFC 1546 2408, November 1998. 1548 [FIPS 196], ``Entity Authentication Using Public Key Cryptography,'' Federal 1549 Information Processing Standards Publication 196, NIST, February 1997. 1551 [DH77], Diffie, W., and M. Hellman, ``New Directions in Cryptography'', IEEE 1552 Transactions on Information Theory, June 1977. 1554 [WHA98], Wallner, D., Harder E., and Agee R., ``Key Management for 1555 Multicast: Issues and Architectures'', Internet Draft, Informational, 1556 September 1998. 1558 [BMS], Balenson D., McGrew D., Sherman A., ``Key Management for Large 1559 Dynamic Groups: One-Way Function Trees and Amortized Initialization'', 1560 Internet Draft, February 1999. 1562 [RFC 2093] Harney H., Muckenhirn C., and Rivers T., ``Group Key, Management 1563 Protocol Specification'', RFC 2093, Experimental, July 1997. 1565 [RFC 2094] Harney H., Muckenhirn C., and Rivers T., ``Group Key Management 1566 Protocol Architecture'', RFC 2094, Experimental, July 1997. 1568 [RFC 2104] Krawczyk H., Bellare M., and Canetti R., ``HMAC: Keyed-Hashing 1569 for Message Authentication'', RFC 2104, Informational, February 1571 [RFC 2401] Kent S. and Atkinson, R., ``Security Architecture for the 1572 Internet Protocol'', RFC 2401, November 1998, Proposed Standard. 1574 [RFC 2402] Kent S. and Atkinson, R., ``IP Authentication Header'', RFC 2402, 1575 November 1998, Proposed Standard.1997. 1577 [RFC 2406] Kent S. and Atkinson, R., ``IP Encapsulating Security Payload 1578 (ESP)'', RFC 2406, November 1998, Proposed Standard. 1580 [RFC 2408] Maughan D., Schertler M., Schneider M., and Turner J., ``Internet 1581 Security Association and Key Management Protocol (ISAKMP)'', RFC 2408, 1582 Proposed Standard, November 1998. 1584 [RFC 2409] Harkins D. and Carrel D., ``The Internet Key Exchange (IKE)'', 1585 RFC 2409, Proposed Standard, November 1998. 1587 [RFC 2412] Orman H. K., ``The OAKLEY Key Determination Protocol'', RFC 2412, 1588 Informational, November 1998. 1590 [RFC2543], M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, SIP: 1591 Session Initiation Protocol, March 99 1593 [RFC2974], M. Handley, C. Perkins, E. Whelan, Session Announcement Protocol, 1594 Oct 2000. 1596 9.2 Authors Addresses 1598 Hugh Harney (point-of-contact) 1599 9861 Broken Land Parkway 1600 Suite 300 1601 Columbia, MD 21046 1602 (410) 381-9400 ext 203 1603 FAX (410) 381-5559 1604 hh@columbia.sparta.com 1606 Angela Schuett 1607 R231 NSA 1608 9800 Savage Rd 1609 Suite 6534 1610 Fort Meade, MD 20755 1611 (301) 688-0850 1612 FAX (301) 688-0255 1613 amschue@tycho.ncsc.mil 1615 Andrea Colegrove 1616 9861 Broken Land Parkway 1617 Suite 300 1618 Columbia, MD 21046 1619 (410) 381-9400 ext 232 1620 FAX (410) 381-5559 1621 acc@columbia.sparta.com 1623 Document expiration: December 31, 2002