idnits 2.17.1 draft-housley-gigabeam-radio-link-encrypt-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 630. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 601. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 614. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 2006) is 6522 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) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2407 (ref. 'IPDOI') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2313 (ref. 'PKCS1') (Obsoleted by RFC 2437) -- Obsolete informational reference (is this intentional?): RFC 3280 (ref. 'PKIX1') (Obsoleted by RFC 5280) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT R. Housley (Vigil Security) 3 Informational A. Corry (GigaBeam) 4 Expires December 2006 June 2006 6 GigaBeam High-Speed Radio Link Encryption 7 9 Status of this Memo 11 Internet-Drafts are working documents of the Internet Engineering 12 Task Force (IETF), its areas, and its working groups. Note that 13 other groups may also distribute working documents as Internet- 14 Drafts. 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 This document may not be modified, and derivative works of it may not 22 be created, except to publish it as an RFC and to translate it into 23 languages other than English. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Abstract 38 This document describes the encryption and key management used by 39 GigaBeam as part of the WiFiber(tm) family of radio link products. 40 The security solution is documented in the hope that other wireless 41 product development efforts will include comparable capabilities. 43 1. Introduction 45 The GigaBeam WiFiber(tm) product family provides a high-speed point- 46 to-point radio link. Data rates exceed 1 gigabit/second at a 47 distance of about a mile. The transmission beam width is less than 48 one degree, which means that attempts to intercept the signal are 49 most successful when the attacker is either between the transmitter 50 and receiver or the attacker is directly behind the receiver. Since 51 interception is possible, some customers require confidentiality and 52 integrity protection for the data on the radio link. This document 53 describes the security solution designed and deployed by GigaBeam to 54 provide these security services. 56 The GigaBeam security solution employs: 58 o AES-GCM [GCM] with a custom security protocol specified 59 in this document to provide confidentiality and integrity 60 protection of subscriber traffic on the radio link; 62 o AES-CBC [CBC] and HMAC-SHA-1 [HMAC] with IPsec ESP [ESP] to 63 provide confidentiality and integrity protection of management 64 traffic between the radio control modules; 66 o AES-CBC [CBC] and HMAC-SHA-1 [HMAC] with IKE [IKE] to provide 67 confidentiality and integrity protection of key management 68 traffic between the radio control modules; and 70 o OAKLEY key agreement [OAKLEY] and RSA digital signatures [PKCS1] 71 are used with IKE to establish keying material and to provide 72 authentication. 74 AES-GCM is used with the custom security protocol in a manner that is 75 very similar to its use in ESP [ESP-GCM]. 77 2. GigaBeam High-Speed Radio Link Overview 79 The GigaBeam high-speed radio link appears to be a fiber interface 80 between two network devices. Figure 1 illustrates the connection of 81 two devices that normally communicate using Gigabit Ethernet over a 82 fiber optic cable. 84 +---------+ +----------+ +----------+ +---------+ 85 | | | +----/ | | | | 86 | Network | | GigaBeam | / | GigaBeam | | Network | 87 | Device +=====+ Radio | /---- + Radio +=====+ Device | 88 | | | | | | | | 89 +---------+ ^ +----------+ ^ +----------+ ^ +---------+ 90 | | | 91 | | | 92 Gigabit Ethernet | Gigabit Ethernet 93 GigaBeam Radio Link 95 Figure 1. GigaBeam Radio Link Example. 97 Gigabit Ethernet traffic is encoded in 8B/10B format. The GigaBeam 98 Radio Control Module (RCM) removes this coding to recover the 8-bit 99 characters plus an indication of whether the character is a control 100 code. The radio link frame is constructed from 224 10-bit input 101 words, and a 4-way interleaved (56,50,10) Reed Solomon Forward Error 102 Correction block is employed. Conversion of the Gigabit Ethernet 103 data from 8B/10B format creates 224-bits of additional capacity in 104 each frame, and another 196 bits is gained by recoding the 9-bit data 105 using 64B/65B block codes. This additional 420 bits of capacity is 106 used for the framing overhead required for FEC and link control. 108 2.1. GigaBeam Radio Link Frame Format 110 The GigaBeam radio link frame fields are summarized in Figure 2, 111 which also provides the length of each field in bits. 113 Field Length Description 114 ----- ------ ----------- 115 SYNC 11 Frame Synchronization Pattern ('10110111000'b) 116 KEYSEL 1 Indicates which AES key was used for this frame 117 PN 40 AES-GCM Packet Number 118 FLAGS 28 Control bits, one bit for each 64B/65B data block 119 DCC 8 Data Communications Channel 120 DATA 1792 Data (28 encrypted 64B/65B code blocks) 121 TAG 96 Authentication Tag 122 SPARE 24 Reserved for alternative FEC algorithms 123 CHECK 240 Reed-Solomon Check Words for 4 10-bit 124 symbol (56,50) code 126 Figure 2. GigaBeam Radio Link Frame Structure. 128 Each of the fields in the GigaBeam 2240-bit radio link frame is 129 described below. 131 SYNC Synchronization field, an 11-bit Barker code. Always set 132 to '10110111000'b. 134 KEYSEL Key Selector -- select the appropriate key register for 135 this frame. Two key registers are maintained to allow 136 seamless rollover between encryption keys. 138 PN Packet Number -- needed by AES-GCM; it carries the unique 139 counter value for this frame. The value is incremented 140 for each frame. 142 FLAGS Control bits, one for each 64B/65B data block carried in 143 the DATA field. If the bit is set, then the 144 corresponding 64B/65B block in the DATA field contains a 145 control code. This field is integrity protected by 146 AES-GCM. 148 DCC Data Communications Channel -- each frame carries one 149 octet of the point-to-point data communications channel 150 between the two radio control modules. See Section 2.2 151 for more information in the DCC. 153 DATA Subscriber data carried as 28 64B/65B code blocks. This 154 field is encrypted and integrity protected by AES-GCM. 156 TAG The authentication tag generated by AES-GCM, truncated to 157 96 bits. 159 SPARE 24 bits, set to zero. 161 CHECK Forward error correction check value -- 24 check symbols 162 are generated by a 4-way interleaved Reed-Solomon 163 (56,50,10) algorithm. FEC is always active, but 164 correction can be selectively enabled. For each frame, 165 FEC processing also returns the number of bit errors, the 166 number of symbols in error, and whether the FEC 167 processing failed for the frame. This information allows 168 an estimation of the bit error rate for the link. 170 2.2. Data Communications Channel 172 The Data Communications Channel (DCC) field reserves eight bits in 173 each 2240-bit radio link frame for use in constructing a dedicated 174 point-to-point link between the two RCMs. The DCC content is 175 connected to a Universal Asynchronous Receiver/Transmitter (UART) 176 controller that processes the DCC bit stream to provide an 177 asynchronous serial channel that is visible to the RCM operating 178 system. The Point-to-Point Protocol (PPP) [PPP] is used on the 179 serial channel to create a simple two-node Internet Protocol (IP) 180 network. Each IP datagram is spread over a large number of radio 181 link frames. This two-node IP network carries management protocols 182 between the GigaBeam RCMs. 184 IKE [IKE] runs on this two-node IP network to manage all 185 cryptographic keying material. IPsec ESP [ESP] is used in the usual 186 fashion to protect all non-IKE traffic on the data control channel. 187 IPsec ESP employs AES-CBC as described in [ESP-CBC] and HMAC-SHA1 as 188 described in [ESP-HMAC]. 190 3. Radio Link Processing 192 The fiber interface constantly provides a stream of data encoded in 193 8B/10B format. A radio link frame is constructed from 224 10-bit 194 input words. Conversion of the data from 8B/10B format creates 195 224-bits of additional capacity in each frame, and then recoding 196 using 64B/65B block codes creates another 196 bits of additional 197 capacity. After encryption, the 64B/65B blocks are carried in the 198 DATA field, and the control code indicator bits are carried in the 199 FLAGS field. The additional capacity is used for the framing 200 overhead. 202 Processing proceeds as follows: 204 o encryption and integrity protection as described in section 3.1; 206 o forward error correction (FEC) processing as described in 207 section 3.2; 209 o scrambling as described in section 3.3; and 211 o differential encoding as described in section 3.4. 213 3.1. Encryption and Integrity Protection 215 The GigaBeam RCM contains two key registers. The single-bit KEYSEL 216 field indicates which of the two registers was used for the frame. 218 AES-GCM [GCM] employs counter mode for encryption. Therefore, a 219 unique value for each frame is needed to construct the counter. The 220 counter includes a 32-bit salt value provided by IKE and a 40-bit 221 packet number from PN field in the radio link frame. The same 222 counter value must not be used for more than one frame encrypted with 223 the same key. The 128-bit counter block is constructed as shown in 224 Figure 3. The first 96 bits of the AES counter block are called the 225 Nonce in the AES-GCM algorithm description. Note that AES-GCM uses 226 BLOCK values of zero and one for its own use. The values beginning 227 with two are used for encrypting the radio link frame payload. 229 Field Length Description 230 ----- ------ ----------- 231 SALT 32 Salt value generated during the IKE exchange 232 MBZ1 24 These bits must be zero 233 PN 40 AES-GCM Packet Number carried in PN field 234 MBZ2 28 These bits must be zero 235 BLOCK 4 Block counter used in AES-GCM 237 Figure 3. AES Counter Block Construction. 239 AES-GCM is used to protect the FLAGS and DATA fields. The FLAGS 240 field is treated as authenticated header data, and it is integrity 241 protected, but it is not encrypted. The DATA field is encrypted and 242 authenticated. The TAG field contains the authentication tag 243 generated by AES-GCM, truncated to 96 bits. 245 Reception processing performs decryption and integrity checking. If 246 the integrity checks fail, to maintain a continuous stream of 247 traffic, the frame is replaced with K30.7 control characters. These 248 control characters are normally used to mark errors in the data 249 stream. Without encryption and integrity checking these control 250 characters usually indicate 8B/10B running disparity or code errors. 252 3.2. Forward Error Correction (FEC) 254 The 224 10-bit data symbols that make up each radio link frame are 255 grouped into 4 subframes each consisting of 56 symbols. The 256 subframes are formed by symbol interleaving. A Reed Solomon Code, 257 RS(56,50), designed for 10-bit symbols is applied to each subframe. 259 This Reed Solomon Code detects 6 errors and corrects 3 errors within 260 each subframe. The FEC function is always active; however, it is 261 possible to disable correction of the received data to support 262 debugging. 264 3.3. Scrambler 266 The scrambler ensures that long series of one bits and long series of 267 zero bits do not occur. When encryption is enabled, long series of 268 common bit values is very unlikely; however, during the initial IKE 269 exchange, the radio link frame payload is all zero bits. 271 The scrambling polynomial is (1 + x^14 + x^15). All words of a frame 272 except the SYNC pattern are scrambled prior to transmission using 273 this linear feedback shift register (LFSR). The LFSR is initialized 274 to all ones at the start of each frame, prior to the first processed 275 bit. Each processed input bit is added modulo 2 (i.e., an XOR) to 276 the output of the x15 tap to form the output bit. 278 On reception, an identical process is performed after frame 279 synchronization and prior to subsequent processing to recover the 280 original bit pattern. 282 3.4. Differential Encoding 284 The data stream is differentially encoded to avoid symbol ambiguity 285 at the receiver. Since the demodulator could produce true or 286 inverted data depending on the details of the RF and IF processing 287 chains, differential encoding is used to ensure proper reception of 288 the intended bit value. A zero bit is encoded as no change from the 289 previous output bit, and a one bit is encoded as a change from the 290 previous output bit. Thus, an output bit is the result of XORing the 291 unencoded bit with the previously transmitted encoded bit. 293 On reception, a complementary operation will be performed to produce 294 the decoded datastream. The bitstream is formed by XORing the 295 received encoded bit and the previously received encoded bit. 297 4. Key Management 299 The Internet Key Exchange (IKE) is used for key management [IKE]. 300 IKE has two phases. In Phase 1, two ISAKMP peers establish a secure, 301 authenticated channel with which to communicate. This is called the 302 ISAKMP Security Association (SA). In the GigaBeam environment, the 303 Phase 1 exchange is IKE Aggressive Mode with signatures and 304 certificates. The RSA signature algorithm is used. 306 Phase 2 negotiates the Security Associations for the GigaBeam custom 307 security protocol that protects subscriber traffic and IPsec ESP that 308 protects management traffic between the GigaBeam RCMs. In the 309 GigaBeam environment, the Phase 2 exchange is IKE Quick Mode, without 310 perfect forward secrecy (PFS). The information exchanged along with 311 Quick Mode is be protected by the ISAKMP SA. That is, all payloads 312 except the ISAKMP header are encrypted. A detailed description of 313 Quick Mode can be found in Section 5.5 of [IKE]. 315 When the Security Association is no longer needed, the ISAKMP Delete 316 Payload is used to tell the peer GigaBeam device that it is being 317 discarded. 319 4.1. Certificates 321 Each GigaBeam device generates its own public/private key pair. This 322 generation is performed at the factory, and the public key is 323 certified by a Certification Authority (CA) in the factory. The 324 certificate includes a name of the following format: 326 C=US 327 O=GigaBeam Corporation 328 OU=GigaBeam WiFiber(tm) 329 SerialNumber=/ 331 The ISAKMP Certificate Payload is used to transport certificates, and 332 in the GigaBeam environment, the "X.509 Certificate - Signature" 333 certificate encoding type (indicated by a value of 4) is always used. 335 GigaBeam devices are always installed in pairs. At installation 336 time, each one is configured with the device model identifier and 337 device serial number of its peer. The device model identifier and 338 device serial number of a backup device can also be provided. An 339 access control check is performed when certificates are exchanged. 340 The certificate subject name must match one of these configured 341 values, and the certification path must validate to a configured 342 trust anchor, such as the GigaBeam Root CA, using the validation 343 rules in [PKIX1]. 345 4.2. Oakley Groups 347 With IKE, several possible Diffie-Hellman groups are supported. 348 These groups originated with the Oakley protocol and are therefore 349 called "Oakley Groups". 351 GigaBeam devices use group 14, which is described in section 3 of 352 [MODP]. 354 4.3. Security Protocol Identifier 356 The ISAKMP proposal syntax was specifically designed to allow for the 357 simultaneous negotiation of multiple Phase 2 security protocol 358 suites. The identifiers for the IPsec Domain of Interpretation (DOI) 359 are given in [IPDOI]. 361 The GigaBeam custom security protocol has been assigned the 362 PROTO_GIGABEAM_RADIO protocol identifier, with a value of TBD. 364 The PROTO_GIGABEAM_RADIO specifies the use of the GigaBeam radio link 365 frame structure, which uses a single algorithm for both 366 confidentiality and authentication. The following table indicates 367 the algorithm values that are currently defined. 369 Transform ID Value 370 ------------ ----- 371 RESERVED 0 372 GIGABEAM_AES128_GCM 1 374 4.4. Keying Material 376 GIGABEAM_AES128_GCM requires 20 octets of keying material (called 377 KEYMAT in [IKE]). The first 16 octets are the 128-bit AES key, and 378 the remaining four octets are used as the salt value in the AES 379 counter block. 381 Presently, AES with a 128-bit key is the only encryption algorithm 382 that is supported. Others encryption algorithms could be registered 383 in the future. 385 4.5. Identification Type Values 387 The following table lists the assigned values for the Identification 388 Type field found in the ISAKMP Identification Payload. 390 ID Type Value 391 ------- ----- 392 RESERVED 0 393 ID_IPV4_ADDR 1 394 ID_FQDN 2 395 ID_USER_FQDN 3 396 ID_IPV4_ADDR_SUBNET 4 397 ID_IPV6_ADDR 5 398 ID_IPV6_ADDR_SUBNET 6 399 ID_IPV4_ADDR_RANGE 7 400 ID_IPV6_ADDR_RANGE 8 401 ID_DER_ASN1_DN 9 402 ID_DER_ASN1_GN 10 403 ID_KEY_ID 11 405 The ID_DER_ASN1_DN will be used when negotiating security 406 associations for use with the GigaBeam custom security protocol. The 407 provided distinguished name must match the peer's subject name 408 provided in the X.509 certificate. 410 4.6. Security Parameter Index 412 The least significant bit of the Security Parameter Index (SPI) is 413 used in the GigaBeam custom security protocol. When two GigaBeam 414 custom security protocol security associations are active at the same 415 time for communications in the same direction, the least significant 416 bit of the SPI must be different to ensure that these active security 417 associations can be distinguished by the single bit in the GigaBeam 418 custom security protocol. 420 4.7. Key Management Latency 422 The IKE exchange over the DCC must complete before subscriber data 423 can be exchanged in the GigaBeam radio link frame payload. Since 424 each radio link frame carries a small portion of an IP datagram, many 425 empty and radio link frames must be sent and received to complete the 426 IKE exchange. 428 Once the initial keying material is in place, the IKE exchanges to 429 establish subsequent keying material can be performed concurrent with 430 the transfer of subscriber data in the radio link frame payload. The 431 KEYSEL field in the radio link frame is used to indicate which keying 432 material is being used. 434 The PN field in radio link frame provides a continuous indication of 435 the number of frames that have been encrypted with a particular key. 436 Once a threshold is exceeded, the IKE exchanges begin to establish 437 the replacement keying material. Currently, the exchanges begin when 438 half of the packet numbers have been used, but any threshold can be 439 employed, as long as the replacement keying material is available 440 before the packet counters are exhausted. 442 5. Security Considerations 444 The security consideration in [IKE], [OAKLEY], [PKCS1], and [ESP] 445 apply to the security system defined in this document. 447 Confidentiality and integrity are provided by the use of negotiated 448 algorithms. AES-GCM [GCM] is used with the GigaBeam custom security 449 protocol to provide confidentiality and integrity protection of 450 subscriber traffic on the radio link. AES-CBC [CBC] and HMAC-SHA-1 451 [HMAC] are used with IPsec ESP [ESP] to provide confidentiality and 452 integrity protection of management traffic between the radio control 453 modules. 455 AES-GCM makes use of AES Counter mode to provide confidentiality. 456 Unfortunately, it is very easy to misuse counter mode. If counter 457 block values are ever used for more that one frame with the same key, 458 then the same key stream will be used to encrypt both frames, and the 459 confidentiality guarantees are voided. Using AES Counter mode with 460 the same counter values to encrypt two plaintexts under the same key 461 leaks the plaintext. The automated key management described here is 462 intended to prevent this from ever happening. 464 Since AES has a 128-bit block size, regardless of the mode employed, 465 the ciphertext generated by AES encryption becomes distinguishable 466 from random values after 2^64 blocks are encrypted with a single key. 467 Since the GigaBeam radio link frame allows for up to 2^40 fixed- 468 length frames in a single security association, there is no 469 possibility for more than 2^64 blocks to be encrypted with one key. 471 The lifetime of a particular key AES key can be shorter that 2^40 472 frames. A smaller threshold can be used as a trigger to transition 473 to the next key. This capability allows straightforward 474 implementation of policies that require the key to be changed after a 475 particular volume of traffic or a particular amount of time. 477 There are fairly generic precomputation attacks against all block 478 cipher modes that allow a meet-in-the-middle attack against the key. 479 These attacks require the creation and searching of huge tables of 480 ciphertext associated with known plaintext and known keys. Assuming 481 that the memory and processor resources are available for a 482 precomputation attack, then the theoretical strength of AES Counter 483 mode (and any other block cipher mode) is limited to 2^(n/2) bits, 484 where n is the number of bits in the key. The use of long keys is 485 the best countermeasure to precomputation attacks. The unpredictable 486 nonce value in the counter block significantly increases the size of 487 the table that the attacker must compute to mount a successful 488 precomputation attack. 490 Rekeying with Quick Mode results in new keys to protect GigaBeam 491 radio link frames; however, these keys are generated from the same 492 Diffie-Hellman shared secret. In order to limit the amount of data 493 that would be exposed by the disclosure of this Diffie-Hellman shared 494 secret or the associated Difffie-Hellman private key, implementations 495 should periodically rekey using a new Phase 1 exchange. 497 Diffie-Hellman exponents used in IKE Phase 1 should be erased from 498 memory immediately after use. Likewise, AES and HMAC-SHA-1 keying 499 material should be erased from memory when it is no longer needed. 501 This security solution makes use of IKEv1 [IKE]. IKEv1 was selected 502 over IKEv2 [IKEv2] primarily due to the availability of an 503 implementation for the processing environment. The use of IKEv2 504 would provide some useful capabilities, such as Diffie-Hellman group 505 negotiation. These additional capabilities are would not 506 significantly improve the security of the overall key management 507 solution that runs on the two-node IP network. 509 6. Informative References 511 [CBC] Dworkin, M., "Recommendation for Block Cipher Modes of 512 Operation: Methods and Techniques," NIST Special 513 Publication 800-38A, December 2001. 515 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating 516 Security Payload (ESP)", RFC 2406, November 1998. 518 [ESP-CBC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC 519 Cipher Algorithm and Its Use with IPsec", RFC 3602, 520 September 2003. 522 [ESP-GCM] J. Viega, J., and D. McGrew, "The Use of 523 Galois/Counter Mode (GCM) in IPsec Encapsulating 524 Security Payload (ESP)", RFC 4106, June 2005. 526 [ESP-HMAC] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 527 within ESP and AH", RFC 2404, November 1998. 529 [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of 530 Operation (GCM)", Submission to NIST. http:// 531 csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/ 532 gcm-spec.pdf, January 2004. 533 [ Soon: NIST SP 800-38D. ] 535 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: 536 Keyed-Hashing for Message Authentication", RFC 2104, 537 February 1997. 539 [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange 540 (IKE)", RFC 2409, November 1998. 542 [IKEv2] Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", 543 RFC 2306, December 2005. 545 [IPDOI] Piper, D., "The Internet IP Security Domain of 546 Interpretation for ISAKMP", RFC 2407, November 1998. 548 [MODP] Kivinen, T., and M. Kojo. "More Modular Exponential (MODP) 549 Diffie-Hellman groups for Internet Key Exchange (IKE)", 550 RFC 3526, May 2003. 552 [OAKLEY] Orman, H., "The Oakley Key Determination Protocol", 553 RFC 2412, November 1998. 555 [PKCS1] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", 556 RFC 2313, March 1998. 558 [PKIX1] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 559 X.509 Public Key Infrastructure Certificate and 560 Certificate Revocation List (CRL) Profile", RFC 3280, 561 April 2002. 563 [PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", 564 RFC 1661, July 1994. 566 7. IANA Considerations 568 IANA has assigned one IPsec Security Protocol Identifier in 569 http://www.iana.org/assignments/isakmp-registry for 570 PROTO_GIGABEAM_RADIO. It was assigned the value TBD. 572 8. Acknowledgements 574 The authors thank Bob Sutherland and Dave Marcellas for their 575 contributions and review. 577 Authors' Addresses 579 Russell Housley 580 Vigil Security, LLC 581 918 Spring Knoll Drive 582 Herndon, VA 20170 583 USA 584 EMail: housley vigilsec com 586 Alan Corry 587 GigaBeam Corporation 588 470 Springpark Place, Suite 900 589 Herndon, VA 20170 590 EMail: acorry gigabeam com 592 Intellectual Property Rights Statement 594 The IETF takes no position regarding the validity or scope of any 595 Intellectual Property Rights or other rights that might be claimed to 596 pertain to the implementation or use of the technology described in 597 this document or the extent to which any license under such rights 598 might or might not be available; nor does it represent that it has 599 made any independent effort to identify any such rights. Information 600 on the procedures with respect to rights in RFC documents can be 601 found in BCP 78 and BCP 79. 603 Copies of IPR disclosures made to the IETF Secretariat and any 604 assurances of licenses to be made available, or the result of an 605 attempt made to obtain a general license or permission for the use of 606 such proprietary rights by implementers or users of this 607 specification can be obtained from the IETF on-line IPR repository at 608 http://www.ietf.org/ipr. 610 The IETF invites any interested party to bring to its attention any 611 copyrights, patents or patent applications, or other proprietary 612 rights that may cover technology that may be required to implement 613 this standard. Please address the information to the IETF at 614 ietf-ipr@ietf.org. 616 Copyright Statement 618 Copyright (C) The Internet Society (2006). 620 This document is subject to the rights, licenses and restrictions 621 contained in BCP 78, and except as set forth therein, the authors 622 retain all their rights. 624 This document and the information contained herein are provided on an 625 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 626 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 627 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 628 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 629 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 630 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.