RFC 4705

GigaBeam High-Speed Radio Link Encryption

📅 published October 2006, from ietf

Okay bestie, this is RFC 4705 💖 It came out from the Network Working Group in October 2006, and the authors are R. Housley (Vigil Security) and A. Corry (GigaBeam). It's Informational, which means it's sharing info, not setting a standard 🧚 Its header has no Obsoletes or Updates line, so it doesn't replace or update anything listed there.

Status of This Memo

This memo gives info to the Internet community ✨ It doesn't specify an Internet standard of any kind, and you're free to share it because distribution is unlimited 🌈

Copyright (C) The Internet Society (2006). 💅

Abstract

This doc explains the encryption and key management GigaBeam uses in its WiFiber(tm) family of radio link products 📡 They wrote it all down in the hope that other wireless product teams will build in comparable capabilities 🫶

1. Introduction ✨

The GigaBeam WiFiber(tm) product family gives you a super fast point-to-point radio link 🚀 Data rates go past 1 gigabit/second at a distance of about a mile, and the beam is less than one degree wide. That narrow beam is iconic, but it also means someone trying to intercept the signal has the best luck if they're between the transmitter and receiver, or sitting directly behind the receiver 👀 Since interception is possible, some customers need confidentiality and integrity protection for the data on the radio link 🔒 This document describes the security solution GigaBeam designed and deployed to provide those services.

The GigaBeam security solution uses:

  • AES-GCM [GCM] with a custom security protocol specified in this document to provide confidentiality and integrity protection of subscriber traffic on the radio link 💜
  • AES-CBC [CBC] and HMAC-SHA-1 [HMAC] with IPsec ESP [ESP] to provide confidentiality and integrity protection of management traffic between the radio control modules 🌸
  • AES-CBC [CBC] and HMAC-SHA-1 [HMAC] with the IKE protocol [IKE] to provide confidentiality and integrity protection of key management traffic between the radio control modules 🍓
  • OAKLEY key agreement [OAKLEY] and RSA digital signatures [PKCS1] are used with IKE to establish keying material and to provide authentication 🔑

AES-GCM is used with the custom security protocol in a manner that is very similar to its use in ESP [ESP-GCM] 💖

The GigaBeam high-speed radio link looks like a fiber interface between two network devices ⭐ Figure 1 shows two devices that normally talk over Gigabit Ethernet on a fiber optic cable 🦋

  +---------+     +----------+        +----------+     +---------+
  |         |     |          +----/   |          |     |         |
  | Network |     | GigaBeam |   /    | GigaBeam |     | Network |
  | Device  +=====+  Radio   |  /---- +  Radio   +=====+ Device  |
  |         |     |          |        |          |     |         |
  +---------+  ^  +----------+   ^    +----------+  ^  +---------+
               |                 |                  |
               |                 |                  |
       Gigabit Ethernet          |          Gigabit Ethernet
                        GigaBeam Radio Link

Figure 1. GigaBeam Radio Link Example.

Gigabit Ethernet traffic is encoded in 8B/10B format 🧩 The GigaBeam Radio Control Module (RCM) strips that coding off to recover the 8-bit characters, plus an indicator of whether each character is a control code. The radio link frame is built from 224 10-bit input words, and a 4-way interleaved (56,50,10) Reed-Solomon Forward Error Correction (FEC) block is used 🛡️ Converting the Gigabit Ethernet data out of 8B/10B format creates 224 bits of extra capacity in each frame, and another 196 bits come from recoding the 9-bit data using 64B/65B block codes 🙈 That's 420 bits of extra capacity in total, and it's used for the framing overhead needed for FEC and link control ✨

The GigaBeam radio link frame fields are summarized in Figure 2, which also gives the length of each field in bits 📋

   Field   Length   Description
   -----   ------   -----------
   SYNC       11    Frame Synchronization Pattern ('10110111000'b)
   KEYSEL      1    Indicates which AES key was used for this frame
   PN         40    AES-GCM Packet Number
   FLAGS      28    Control bits, one bit for each 64B/65B data block
   DCC         8    Data Communications Channel
   DATA     1792    Data (28 encrypted 64B/65B code blocks)
   TAG        96    Authentication Tag
   SPARE      24    Reserved for alternative FEC algorithms
   CHECK     240    Reed-Solomon Check Words for 4 10-bit
                    symbol (56,50) code

Figure 2. GigaBeam Radio Link Frame Structure.

Each field in the GigaBeam 2240-bit radio link frame is described below 🌈

  • SYNC: Synchronization field, an 11-bit Barker code. It's always set to '10110111000'b 🎯
  • KEYSEL: Key Selector. It picks the right key register for this frame. Two key registers are kept around so the encryption keys can roll over seamlessly 🔁
  • PN: Packet Number. AES-GCM needs it, and it carries the unique counter value for this frame. The value goes up by one for each frame 🔢
  • FLAGS: Control bits, one for each 64B/65B data block carried in the DATA field. If a bit is set, the matching 64B/65B block in the DATA field has a control code in it. This field is integrity protected by AES-GCM 🛡️
  • DCC: Data Communications Channel. Each frame carries one octet of the point-to-point data communications channel between the two radio control modules. See Section 2.2 for more on the DCC 💬
  • DATA: Subscriber data carried as 28 64B/65B code blocks. This field is encrypted and integrity protected by AES-GCM 🔐
  • TAG: The authentication tag generated by AES-GCM, truncated to 96 bits 🏷️
  • SPARE: 24 bits, set to zero 🫧
  • CHECK: Forward error correction check value. 24 check symbols are generated by a 4-way interleaved Reed-Solomon (56,50,10) algorithm. FEC is always active, but correction can be turned on selectively. For each frame, FEC processing also returns the number of bit errors, the number of symbols in error, and whether FEC processing failed for that frame. This info lets you estimate the bit error rate for the link 📊

2.2. Data Communications Channel

The Data Communications Channel (DCC) field reserves eight bits in each 2240-bit radio link frame so you can build a dedicated point-to-point link between the two RCMs 🤝 The DCC content feeds a Universal Asynchronous Receiver/Transmitter (UART) controller, which processes the DCC bit stream into an asynchronous serial channel that the RCM operating system can see 👀 The Point-to-Point Protocol (PPP) [PPP] runs on that serial channel to create a simple two-node Internet Protocol (IP) network 🌐 Each IP datagram gets spread over a large number of radio link frames. This two-node IP network carries the management protocols between the GigaBeam RCMs 💜

IKE [IKE] runs on this two-node IP network and manages all the cryptographic keying material 🗝️ IPsec ESP [ESP] is used in the usual way to protect all non-IKE traffic on the data control channel. IPsec ESP uses AES-CBC as described in [ESP-CBC] and HMAC-SHA-1 as described in [ESP-HMAC] 💅

The fiber interface constantly provides a stream of data encoded in 8B/10B format 🌊 A radio link frame is built from 224 10-bit input words. Converting the data out of 8B/10B format creates 224 bits of extra capacity in each frame, then recoding with 64B/65B block codes creates another 196 bits 🙌 After encryption, the 64B/65B blocks go in the DATA field, and the control code indicator bits go in the FLAGS field. The extra capacity is used for framing overhead ✨

Processing goes like this 👑

  • encryption and integrity protection as described in Section 3.1;
  • forward error correction (FEC) processing as described in Section 3.2;
  • scrambling as described in Section 3.3; and
  • differential encoding as described in Section 3.4.

3.1. Encryption and Integrity Protection

The GigaBeam RCM has two key registers, and the single-bit KEYSEL field tells you which of the two was used for the frame 🗝️

AES-GCM [GCM] uses counter mode for encryption, so every frame needs a unique value to build the counter from 🔢 The counter includes a 32-bit salt value provided by IKE and a 40-bit packet number from the PN field in the radio link frame. The same counter value must not be used for more than one frame encrypted with the same key 🚫 The 128-bit counter block is built as shown in Figure 3. The first 96 bits of the AES counter block are called the Nonce in the AES-GCM algorithm description. AES-GCM uses BLOCK values of zero and one for its own use, and the values starting with two are used for encrypting the radio link frame payload 🧁

   Field   Length   Description
   -----   ------   -----------
   SALT       32    Salt value generated during the IKE exchange
   MBZ1       24    These bits must be zero
   PN         40    AES-GCM Packet Number carried in PN field
   MBZ2       28    These bits must be zero
   BLOCK       4    Block counter used in AES-GCM

Figure 3. AES Counter Block Construction.

AES-GCM protects the FLAGS and DATA fields. The FLAGS field is treated as authenticated header data, so it's integrity protected but not encrypted. The DATA field is both encrypted and authenticated. The TAG field holds the authentication tag generated by AES-GCM, truncated to 96 bits 🏷️

Reception processing does decryption and integrity checking. If the integrity checks fail, the frame gets replaced with K30.7 control characters so the stream of traffic stays continuous 🌸 These control characters are normally used to mark errors in the data stream. Without encryption and integrity checking, they usually show up as 8B/10B running disparity or code errors 🙈

3.2. Forward Error Correction (FEC)

The 224 10-bit data symbols in each radio link frame are grouped into 4 subframes, each made of 56 symbols 🧩 The subframes are formed by symbol interleaving. A Reed-Solomon Code, RS(56,50), designed for 10-bit symbols is applied to each subframe 💖

This Reed Solomon Code detects 6 errors and corrects 3 errors within each subframe 🛡️ FEC is always active. It is possible, though, to disable correction of the received data to support debugging 🔧

3.3. Scrambler 🌀

okay so the scrambler is basically making sure you never get super long streaks of all ones or all zeros, because that's just not it 💅 when encryption is turned on, long runs of the same bit value are very unlikely 🙈 BUT during the initial IKE exchange the radio link frame payload is all zero bits, so yeah, the scrambler has to keep doing its thing there too ✨

the scrambling polynomial is (1 + x^14 + x^15) 🎀 every word in a frame gets scrambled before transmission EXCEPT the SYNC pattern (the SYNC pattern is giving "do not touch" energy 🫶). it does this with a linear feedback shift register (LFSR). the LFSR gets set to all ones at the start of each frame, right before the first processed bit. then each processed input bit is added modulo 2 (aka an XOR) to the output of the x15 tap, and that's your output bit 🦋

on reception, the receiver runs an identical process after frame synchronization and before the rest of the processing, and that's how it recovers the original bit pattern. iconic reversibility 👑

3.4. Differential Encoding 🧚

the data stream gets differentially encoded so the receiver doesn't get confused about which symbol is which 🫠 here's the tea: the demodulator could hand you true data OR inverted data, depending on the details of the RF and IF processing chains. so differential encoding makes sure the intended bit value still comes through properly 🌸

the rule is: a zero bit is encoded as no change from the previous output bit, and a one bit is encoded as a change from the previous output bit. so an output bit is the result of XORing the unencoded bit with the previously transmitted encoded bit. main character energy in one sentence 💜

on reception, a complementary operation gets performed to produce the decoded datastream. the bitstream is formed by XORing the received encoded bit with the previously received encoded bit. it's literally the undo button 🔁

4. Key Management 🔑

okay the Internet Key Exchange (IKE) is what handles key management here [IKE] 🎀 IKE has two phases, and phase 1 is where two Internet Security Association and Key Management Protocol (ISAKMP) peers set up a secure, authenticated channel so they can talk to each other. that channel is called the ISAKMP Security Association (SA). in the GigaBeam environment, the phase 1 exchange is IKE Aggressive Mode with signatures and certificates, and the RSA signature algorithm is used 💖

phase 2 negotiates the Security Associations for two things: the GigaBeam custom security protocol, which protects subscriber traffic, and IPsec ESP, which protects management traffic between the GigaBeam RCMs 🧚 in the GigaBeam environment, phase 2 is IKE Quick Mode, WITHOUT perfect forward secrecy (PFS). the info exchanged along with Quick Mode is protected by the ISAKMP SA, which means all payloads except the ISAKMP header are encrypted 🔒 if you want the full breakdown of Quick Mode, it's in Section 5.5 of [IKE] ✨

and when a Security Association isn't needed anymore, the ISAKMP Delete Payload gets used to tell the peer GigaBeam device that it's being discarded 🗑️ bye bye, no thanks 💅

4.1. Certificates 📜

each GigaBeam device makes its own public/private key pair 🌈 this happens at the factory, and the public key is certified by a Certification Authority (CA) in the factory too. the certificate includes a name in this format:

C=US O=GigaBeam Corporation OU=GigaBeam WiFiber(tm)
SerialNumber=<device-model-identifier>/<device-serial-number>

the ISAKMP Certificate Payload is what carries certificates around, and in the GigaBeam environment the "X.509 Certificate - Signature" certificate encoding type (indicated by a value of 4) is ALWAYS used 🫶 (ok I'm yelling because it's the only option, not because it's a rule keyword 🙈)

GigaBeam devices always get installed in pairs 👯‍♀️ at install time, each one is configured with the device model identifier and device serial number of its peer. a backup device's model identifier and serial number can also be provided. when certificates get exchanged, an access control check happens 🚪 the certificate subject name has to match one of those configured values, AND the certification path has to validate to a configured trust anchor, such as the GigaBeam Root CA, using the validation rules in [PKIX1]. no random strangers allowed 🙅‍♀️

4.2. Oakley Groups 🌸

with IKE, several possible Diffie-Hellman groups are supported 💜 they originated with the Oakley protocol, which is why they're called "Oakley Groups." history lesson, bestie 📚

GigaBeam devices use group 14, which is described in Section 3 of [MODP] ✨

4.3. Security Protocol Identifier 🆔

the ISAKMP proposal syntax was specifically designed so you can negotiate multiple Phase 2 security protocol suites at the same time 🙌 the identifiers for the IPsec Domain of Interpretation (DOI) are given in [IPDOI] 🦋

the GigaBeam custom security protocol has been assigned the PROTO_GIGABEAM_RADIO protocol identifier, with a value of 5 💖

PROTO_GIGABEAM_RADIO specifies the use of the GigaBeam radio link frame structure, which uses a single algorithm for BOTH confidentiality and authentication 🔐 the algorithm values that are currently defined are in this table:

Transform ID                      Value
------------                      -----
RESERVED                            0
GIGABEAM_AES128_GCM                 1

4.4. Keying Material 🗝️

GIGABEAM_AES128_GCM requires 20 octets of keying material (called KEYMAT in [IKE]) 🎀 the first 16 octets are the 128-bit AES key, and the remaining four octets get used as the salt value in the AES counter block. 16 + 4 = 20, math is slaying 🧮

right now, AES with a 128-bit key is the ONLY encryption algorithm that's supported. other encryption algorithms could be registered in the future 🔮

4.5. Identification Type Values 🪪

the following table lists the assigned values for the Identification Type field found in the ISAKMP Identification Payload:

ID Type                           Value
-------                           -----
RESERVED                            0
ID_IPV4_ADDR                        1
ID_FQDN                             2
ID_USER_FQDN                        3
ID_IPV4_ADDR_SUBNET                 4
ID_IPV6_ADDR                        5
ID_IPV6_ADDR_SUBNET                 6
ID_IPV4_ADDR_RANGE                  7
ID_IPV6_ADDR_RANGE                  8
ID_DER_ASN1_DN                      9
ID_DER_ASN1_GN                     10
ID_KEY_ID                          11

the ID_DER_ASN1_DN is the one that gets used when negotiating security associations for the GigaBeam custom security protocol 🫧 the distinguished name you provide has to match the peer's subject name in the X.509 certificate. name matching = lowkey the whole vibe 💅

4.6. Security Parameter Index 🔢

the least significant bit of the Security Parameter Index (SPI) is used in the GigaBeam custom security protocol 🌟 when two GigaBeam custom security protocol security associations are active at the same time for communications in the same direction, the least significant bit of the SPI must be different. that way, those active security associations can be told apart by that single bit in the GigaBeam custom security protocol 🤓 two SAs, one bit, zero confusion ✨

4.7. Key Management Latency ⏳

the IKE exchange over the DCC has to complete before any subscriber data can be exchanged in the GigaBeam radio link frame payload 🐢 since each radio link frame only carries a small portion of an IP datagram, you need MANY radio link frames carrying all zero bits to be sent and received to finish the IKE exchange. patience, bestie 🧸

once the initial keying material is in place, the IKE exchanges that set up subsequent keying material can happen at the same time as subscriber data is moving through the radio link frame payload 🏃‍♀️💨 the KEYSEL field in the radio link frame indicates which keying material is in use. multitasking queen 👑

the PN field in the radio link frame gives a continuous indication of how many frames have been encrypted with a particular key 🔑 once a threshold gets exceeded, the IKE exchanges begin to establish the replacement keying material. right now the exchanges begin when half of the packet numbers have been used, but any threshold can be employed, as long as the replacement keying material is available before the packet counters run out ⏰ don't let the counters hit zero, that's the whole secret 🫶

5. Security Considerations 🔐

okay bestie, this section is the serious part 😭 but it's also where the juicy crypto drama lives 💅 The security considerations in [IKE], [OAKLEY], [PKCS1], and [ESP] all apply to this security system too, so those docs come along for the ride 🫶

Confidentiality and integrity come from the negotiated algorithms ✨ AES-GCM [GCM] is used with the GigaBeam custom security protocol to protect subscriber traffic on the radio link (confidentiality AND integrity, ate 💖). Meanwhile AES-CBC [CBC] and HMAC-SHA-1 [HMAC] are paired up with IPsec ESP [ESP] to protect management traffic between the radio control modules 🦋

AES-GCM uses AES Counter mode for confidentiality, and ngl counter mode is EASY to mess up 💀 If counter block values are ever reused for more than one frame with the same key, the same key stream encrypts both frames, and the confidentiality guarantees are voided 🙈 Using AES Counter mode with the same counter values to encrypt two plaintexts under the same key leaks the plaintext. Not me reading that and gasping 😭 The automated key management described here is meant to make sure this never happens 🎀

Since AES has a 128-bit block size, no matter which mode you use, the ciphertext AES produces becomes distinguishable from random values after 2^64 blocks are encrypted with a single key. The GigaBeam radio link frame allows for up to 2^40 fixed-length frames in a single security association, so there is no way to encrypt more than 2^64 blocks with one key. Iconic math, no cap 👑

The lifetime of a particular AES key can be shorter than 2^40 frames 🌸 A smaller threshold can be used as a trigger to move to the next key. This lets you easily build policies that require the key to change after a certain volume of traffic or after a certain amount of time ⏰

There are fairly generic precomputation attacks against all block cipher modes that allow a meet-in-the-middle attack against the key 😳 These attacks need huge tables of ciphertext tied to known plaintext and known keys. If the memory and processing power for a precomputation attack are available, then the theoretical strength of AES Counter mode (and any other block cipher mode) is limited to 2^(n/2) bits, where n is the number of bits in the key. The best countermeasure is using long keys 💜 The unpredictable nonce value in the counter block also makes the table the attacker has to compute way bigger, which is lowkey a big win 🧚

Rekeying with Quick Mode gives you new keys to protect GigaBeam radio link frames, but those keys are all generated from the SAME Diffie-Hellman shared secret 😬 To limit how much data would be exposed if that shared secret or the associated Diffie-Hellman private key got disclosed, implementations should periodically rekey using a new Phase 1 exchange 🌈

Diffie-Hellman exponents used in IKE Phase 1 should be erased from memory immediately after use. Likewise, AES and HMAC-SHA-1 keying material should be erased from memory when it is no longer needed 🧹 Clean up after yourself, bestie 💅

This security solution uses IKEv1 [IKE]. IKEv1 was picked over IKEv2 [IKEv2] mainly because there was an implementation available for the processing environment 🫠 IKEv2 would give some useful capabilities, like Diffie-Hellman group negotiation, but those extras would not significantly improve the security of the overall key management solution running on the two-node IP network. So it's not a security downgrade, it's a vibe-check decision 💖

6. IANA Considerations 🎀

IANA has assigned one IPsec Security Protocol Identifier in http://www.iana.org/assignments/isakmp-registry for PROTO_GIGABEAM_RADIO. It was assigned the value 5 🍓

7. Informative References 📚

  • [CBC] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques," NIST Special Publication 800-38A, December 2001.
  • [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
  • [ESP-CBC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
  • [ESP-GCM] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
  • [ESP-HMAC] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
  • [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of Operation (GCM)", Submission to NIST. http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/gcm-spec.pdf, January 2004. [Soon: NIST SP 800-38D.]
  • [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
  • [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
  • [IKEv2] Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", RFC 2306, December 2005.
  • [IPDOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
  • [MODP] Kivinen, T. and M. Kojo. "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
  • [OAKLEY] Orman, H., "The Oakley Key Determination Protocol", RFC 2412, November 1998.
  • [PKCS1] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 2313, March 1998.
  • [PKIX1] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
  • [PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

8. Acknowledgements 💖

The authors thank Bob Sutherland and Dave Marcellas for their contributions and review 🫶

Authors' Addresses 🖊️

Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA

EMail: housley@vigilsec.com


Alan Corry
GigaBeam Corporation
470 Springpark Place, Suite 900
Herndon, VA 20170
USA

EMail: publications@gigabeam.com

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property ⚖️

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🌷

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) ✨

That's the whole RFC, bestie! 🌈💖

📦 where this page comes from