RFC 2523
Photuris: Extended Schemes and Attributes
RFC 2523: Photuris: Extended Schemes and Attributes ✨🎀
okay bestie, this is part 1 of 4 of RFC 2523, so don't close the tab yet 💖
Here's the title block, all in one place:
- RFC number: 2523 🦋
- Series: Network Working Group
- Title: Photuris: Extended Schemes and Attributes
- Authors: P. Karn (Qualcomm) and W. Simpson (DayDreamer) 👑
- Category: Experimental 🧪
- Date: March 1999 📅
- Obsoletes / Updates: the title block I was given doesn't list anything this RFC obsoletes or updates, so I'm not making any up 🙈
Status of this Memo 🌸
okay so this one is giving "experiment, not law." It defines an Experimental Protocol for the Internet community, and it is NOT an Internet standard of any kind 🙅♀️ The authors are literally asking for discussion and suggestions for improvement, so bring your ideas 💅 Distribution of this memo is unlimited, so share it with everyone who needs it 💜
Copyright Notice 💖
the legal bit, but make it cute: Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn and William Allen Simpson (1994-1999). All Rights Reserved 🌈 The authors kept their rights, the Internet Society has its own copyright, and nobody gets to act like they wrote it 🙃
Abstract ✨
Photuris is a session-key management protocol 🔐 The main slay here is the Extensible Exchange-Schemes, which let implementations change in the future without affecting the basic protocol 🧚 That's the whole point: you can upgrade the bits around it without breaking the core.
The abstract also adds extra authentication attributes for use with the IP Authentication Header (AH) or the IP Encapsulating Security Protocol (ESP) 🛡️ And it adds extra confidentiality attributes for use with ESP 🤫 It's giving security upgrades with zero drama.
Table of Contents 📚
1. Additional Exchange-Schemes ........................... 1
2. Additional Key-Generation-Function .................... 5
2.1 SHA1 Hash ....................................... 5
3. Additional Privacy-Methods ............................ 5
3.1 DES-CBC over Mask ............................... 5
3.2 DES-EDE3-CBC over Mask .......................... 6
4. Additional Validity-Method ............................ 6
4.1 SHA1-IPMAC Check ................................ 6
5. Additional Attributes ................................. 7
5.1 SHA1-IPMAC ...................................... 7
5.1.1 Symmetric Identification ........................ 8
5.1.2 Authentication .................................. 9
5.2 RIPEMD-160-IPMAC ................................ 9
5.2.1 Symmetric Identification ........................ 10
5.2.2 Authentication .................................. 11
5.3 DES-CBC ......................................... 11
5.4 Invert (Decryption/Encryption) .................. 12
5.5 XOR Whitening ................................... 13
APPENDICES ................................................... 15
A. Exchange-Scheme Selection ............................. 15
A.1 Responder ....................................... 15
A.2 Initiator ....................................... 15
SECURITY CONSIDERATIONS ...................................... 16
ACKNOWLEDGEMENTS ............................................. 16
REFERENCES ................................................... 17
CONTACTS ..................................................... 18
COPYRIGHT .................................................... 19the TOC is the map for the rest of the doc, so keep it handy 🗺️ parts 2 through 4 will cover the sections above, so stay tuned 💅🫶
1. Additional Exchange-Schemes ✨
okay so Photuris already has the packet format and the basic facilities sorted [RFC-2522] 💅 That means this part is just adding extra Exchange-Schemes on top, and they're all optional 🦋 Nobody's expected to implement every single one, so don't stress 🫶
This doc defines the following values:
(3) Implementation Optional. Any modulus (p) with a recommended generator (g) of 3. When the Exchange-Scheme Size is non-zero, the modulus lives in the Exchange-Scheme Value field in the list of Offered-Schemes 🌸
An Exchange-Scheme Size of zero is invalid 💀
Key-Generation-Function "MD5 Hash"
Privacy-Method "Simple Masking"
Validity-Method "MD5-IPMAC Check"This combo needs a modulus with at least 64-bits of cryptographic strength. Lowkey weak by today's standards, but it's what the scheme asks for 🙈
(4) Implementation Optional. Any modulus (p) with a recommended generator (g) of 2. When the Exchange-Scheme Size is non-zero, the modulus is in the Exchange-Scheme Value field in the list of Offered-Schemes 🍓
When the Exchange-Scheme Size field is zero, it includes by reference all of the moduli listed in the list of Offered-Schemes for Scheme #2. So it borrows them, no cap 🧚
Key-Generation-Function "MD5 Hash"
Privacy-Method "DES-CBC over Mask"
Validity-Method "MD5-IPMAC Check"Again, 64-bits of cryptographic strength is what this combo needs 🎀
(5) Implementation Optional. Any modulus (p) with a recommended generator (g) of 5. When the Exchange-Scheme Size is non-zero, the modulus is in the Exchange-Scheme Value field in the list of Offered-Schemes ✨
An Exchange-Scheme Size of zero is invalid 💀
Key-Generation-Function "MD5 Hash"
Privacy-Method "Simple Masking"
Validity-Method "MD5-IPMAC Check"This combo needs a modulus with at least 64-bits of cryptographic strength 🌈
(6) Implementation Optional. Any modulus (p) with a recommended generator (g) of 3. When the Exchange-Scheme Size is non-zero, the modulus is in the Exchange-Scheme Value field in the list of Offered-Schemes 🦋
When the Exchange-Scheme Size field is zero, it includes by reference all of the moduli listed in the list of Offered-Schemes for Scheme #3. Borrowing energy again 🫶
Key-Generation-Function "MD5 Hash"
Privacy-Method "DES-CBC over Mask"
Validity-Method "MD5-IPMAC Check"64-bits of cryptographic strength, same as always 💜
(7) Implementation Optional. Any modulus (p) with a variable generator (g). When the Exchange-Scheme Size is non-zero, the pair [g,p] lives in the Exchange-Scheme Value field in the list of Offered-Schemes. Each one gets encoded in its own Variable Precision Integer (VPI). The generator VPI is followed by (concatenated to) the modulus VPI, and that whole result nests inside the Exchange-Scheme Value field 🧚
An Exchange-Scheme Size of zero is invalid 💀
Key-Generation-Function "MD5 Hash"
Privacy-Method "Simple Masking"
Validity-Method "MD5-IPMAC Check"This combo needs a modulus with at least 64-bits of cryptographic strength 👑
When more than one modulus is specified for a given kind of Scheme, the Size of the modulus MUST be unique, independent of the Size of the generator. This one's a hard rule, bestie, no exceptions 🔥
(8) Implementation Optional. Any modulus (p) with a recommended generator (g) of 2. When the Exchange-Scheme Size is non-zero, the modulus is in the Exchange-Scheme Value field in the list of Offered-Schemes ✨
When the Exchange-Scheme Size field is zero, it includes by reference all of the moduli listed in the list of Offered-Schemes for Schemes #2 and #4 🌸
Key-Generation-Function "SHA1 Hash"
Privacy-Method "DES-EDE3-CBC over Mask"
Validity-Method "SHA1-IPMAC Check"This combo needs a modulus with at least 112-bits of cryptographic strength. Now we're talking 😤🍓
(10) Implementation Optional. Any modulus (p) with a recommended generator (g) of 5. When the Exchange-Scheme Size is non-zero, the modulus is in the Exchange-Scheme Value field in the list of Offered-Schemes 💅
When the Exchange-Scheme Size field is zero, it includes by reference all of the moduli listed in the list of Offered-Schemes for Scheme #5 🧚
Key-Generation-Function "MD5 Hash"
Privacy-Method "DES-CBC over Mask"
Validity-Method "MD5-IPMAC Check"64-bits of cryptographic strength 🎀
(12) Implementation Optional. Any modulus (p) with a recommended generator (g) of 3. When the Exchange-Scheme Size is non-zero, the modulus is in the Exchange-Scheme Value field in the list of Offered-Schemes 🦋
When the Exchange-Scheme Size field is zero, it includes by reference all of the moduli listed in the list of Offered-Schemes for Schemes #3 and #6 💜
Key-Generation-Function "SHA1 Hash"
Privacy-Method "DES-EDE3-CBC over Mask"
Validity-Method "SHA1-IPMAC Check"112-bits of cryptographic strength, bestie 👑
(14) Implementation Optional. Any modulus (p) with a variable generator (g). When the Exchange-Scheme Size is non-zero, the pair [g,p] is in the Exchange-Scheme Value field in the list of Offered-Schemes. Each one is encoded in a separate Variable Precision Integer (VPI). The generator VPI is followed by (concatenated to) the modulus VPI, and the result nests inside the Exchange-Scheme Value field 🌈
When the Exchange-Scheme Size field is zero, it includes by reference all of the moduli listed in the list of Offered-Schemes for Scheme #7 ✨
Key-Generation-Function "MD5 Hash"
Privacy-Method "DES-CBC over Mask"
Validity-Method "MD5-IPMAC Check"64-bits of cryptographic strength 🫶
When more than one modulus is specified for a given kind of Scheme, the Size of the modulus MUST be unique, independent of the Size of the generator. Same rule again, periodt 💅
(20) Implementation Optional. Any modulus (p) with a recommended generator (g) of 5. When the Exchange-Scheme Size is non-zero, the modulus is in the Exchange-Scheme Value field in the list of Offered-Schemes 🍓
When the Exchange-Scheme Size field is zero, it includes by reference all of the moduli listed in the list of Offered-Schemes for Schemes #5 and #10 🌸
Key-Generation-Function "SHA1 Hash"
Privacy-Method "DES-EDE3-CBC over Mask"
Validity-Method "SHA1-IPMAC Check"112-bits of cryptographic strength 🔥
(28) Implementation Optional. Any modulus (p) with a variable generator (g). When the Exchange-Scheme Size is non-zero, the pair [g,p] is in the Exchange-Scheme Value field in the list of Offered-Schemes. Each one is encoded in a separate Variable Precision Integer (VPI). The generator VPI is followed by (concatenated to) the modulus VPI, and the result nests inside the Exchange-Scheme Value field 🦋
When the Exchange-Scheme Size field is zero, it includes by reference all of the moduli listed in the list of Offered-Schemes for Schemes #7 and #14 🧚
Key-Generation-Function "SHA1 Hash"
Privacy-Method "DES-EDE3-CBC over Mask"
Validity-Method "SHA1-IPMAC Check"112-bits of cryptographic strength, obsessed 😭
When more than one modulus is specified for a given kind of Scheme, the Size of the modulus MUST be unique, independent of the Size of the generator. Yep, still the rule 🙈
2. Additional Key-Generation-Function ✨
2.1. SHA1 Hash
SHA1 [FIPS-180-1] is used as a pseudo-random-function for generating the key(s). The key(s) begin with the most significant bits of the hash. SHA1 is iterated as needed to generate the requisite length of key material 🔑
When an individual key does not use all 160-bits of the last hash, any remaining unused (least significant) bits of the last hash are discarded. When combined with other uses of key generation for the same purpose, the next key begins with a new hash iteration 🌸
3. Additional Privacy-Methods 🎀
3.1. DES-CBC over Mask
As described in [RFC-2522] "Privacy-Key Computation", enough privacy-key material is generated to match the message length. It begins with the next field after the SPI and includes the Padding. The message is masked by XOR with the privacy-key 💜
Then the Key-Generation-Function is iterated to generate a DES key. The most significant 64-bits (8 bytes) of the generated hash are used for the privacy-key, and the remainder is discarded. Although extremely rare, the 64 weak, semi-weak, and possibly weak keys [Schneier95, pages 280-282] are discarded. The Key-Generation-Function is iterated until a valid key is obtained 🧚
The least significant bit of each key byte is ignored (or set to parity when the implementation requires) 🦋
The 64-bit CBC IV is zero. Message encryption begins with the next field after the SPI, and continues to the end of the data indicated by the UDP Length 🫶
3.2. DES-EDE3-CBC over Mask
This is "Triple DES" outer-CBC EDE encryption (and DED decryption) with three 56-bit keys [KR96]. Yes, the spec really says "DED" 🙈
As described in [RFC-2522] "Privacy-Key Computation", enough privacy-key material is generated to match the message length. It begins with the next field after the SPI and includes the Padding. The message is masked by XOR with the privacy-key 🌈
Then the Key-Generation-Function is iterated (at least) three times to generate the three DES keys. The most significant 64-bits (8 bytes) of each generated hash are used for each successive privacy-key, and the remainder is discarded. Each key is examined sequentially, in the order used for encryption. A key that is identical to a previous key MUST be discarded. Although extremely rare, the 64 weak, semi-weak, and possibly weak keys [Schneier95, pages 280-282] MUST be discarded. The Key-Generation-Function is iterated until a valid key is obtained before generating the next key ✨
In all three keys, the least significant bit of each key byte is ignored (or set to parity when the implementation requires) 💅
The 64-bit CBC IV is zero. Message encryption begins with the next field after the SPI, and continues to the end of the data indicated by the UDP Length 👑
4. Additional Validity-Method 🔥
4.1. SHA1-IPMAC Check ✨
okay so bestie, as described in [RFC-2522] "Validity Verification", the Verification field value is the SHA1 [FIPS-180-1] hash over the concatenation of 💅
SHA1( key, keyfill, data, datafill, key, mdfill )where the key is the computed verification-key.
The keyfill and datafill use the same pad-with-length technique defined for mdfill. This padding and length is implicit, so it doesn't show up in the datagram 🙈
The resulting Verification field is a 160-bit Variable Precision Integer (22 bytes including Size). When it's used in calculations, the Verification data includes both the Size and Value fields. the little details are everything 🎀
5. Additional Attributes 🦋
The attribute format and basic facilities are already defined for Photuris [RFC-2522]. Lowkey the whole vibe is "already handled" ✨
These optional attributes are specified separately, and no single implementation is expected to support all of them. Nobody is doing all of them, and that's giving realistic 😭
This document defines the following values:
Use Type
AEI 6 SHA1-IPMAC
AEI 7 RIPEMD-160-IPMAC
E 8 DES-CBC
E 9 Invert (Decryption/Encryption)
E 10 XOR
A AH Attribute-Choice
E ESP Attribute-Choice
I Identity-Choice
X dependent on list location5.1. SHA1-IPMAC 🔥
The attribute layout is a simple bit-by-bit thing:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 6
Length 05.1.1. Symmetric Identification 🔑
When this is selected as an Identity-Choice, the immediately following Identification field contains an unstructured Variable Precision Integer. The valid Identifications and symmetric secret-keys are preconfigured by the parties, so nobody's guessing ✨
There is no required format or content for the Identification value. It can be a number or a string of any kind, literally whatever. See [RFC-2522] "Use of Identification and Secrets" for details.
The symmetric secret-key (as specified) is selected based on the contents of the Identification field. All implementations MUST support at least 62 bytes. The selected symmetric secret-key SHOULD provide at least 80-bits of cryptographic strength. these are the non-negotiables, bestie 💀
As described in [RFC-2522] "Identity Verification", the Verification field value is the SHA1 [FIPS-180-1] hash over the concatenation of:
SHA1( key, keyfill, data, datafill, key, mdfill )where the key is the computed verification-key.
The keyfill and datafill use the same pad-with-length technique defined for mdfill. This padding and length is implicit, so it doesn't appear in the datagram 🌸
The resulting Verification field is a 160-bit Variable Precision Integer (22 bytes including Size). When it's used in calculations, the Verification data includes both the Size and Value fields.
For both [RFC-2522] "Identity Verification" and "Validity Verification", the verification-key is the SHA1 [FIPS-180-1] hash of the following concatenated values:
- the symmetric secret-key,
- the computed shared-secret.
For [RFC-2522] "Session-Key Computation", the symmetric secret-key is used directly as the generation-key. Main character energy 👑
The symmetric secret-key is used in calculations in the same fashion as [RFC-2522] "MD5-IPMAC Symmetric Identification".
5.1.2. Authentication 🧚
May be selected as an AH or ESP Attribute-Choice, pursuant to [RFC-1852] et sequitur. The selected Exchange-Scheme SHOULD provide at least 80-bits of cryptographic strength.
As described in [RFC-2522] "Session-Key Computation", the most significant 384-bits (48 bytes) of the Key-Generation-Function iterations are used for the key.
Profile:
When negotiated with Photuris, the transform differs slightly from [RFC-1852]. It's a tiny tweak, but it matters 🙈
The form of the authenticated message is:
SHA1( key, keyfill, datagram, datafill, key, mdfill )where the key is the SPI session-key.
The additional datafill protects against the attack described in [PO96]. The keyfill and datafill use the same pad-with-length technique defined for mdfill. This padding and length is implicit, and does not appear in the datagram.
5.2. RIPEMD-160-IPMAC 🌈
Same layout, different algorithm:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 7
Length 05.2.1. Symmetric Identification 🔑
When selected as an Identity-Choice, the immediately following Identification field contains an unstructured Variable Precision Integer. Valid Identifications and symmetric secret-keys are preconfigured by the parties.
There is no required format or content for the Identification value. The value may be a number or string of any kind. See [RFC-2522] "Use of Identification and Secrets" for details.
The symmetric secret-key (as specified) is selected based on the contents of the Identification field. All implementations MUST support at least 62 bytes. The selected symmetric secret-key SHOULD provide at least 80-bits of cryptographic strength.
As described in [RFC-2522] "Identity Verification", the Verification field value is the RIPEMD-160 [DBP96] hash over the concatenation of:
RIPEMD160( key, keyfill, data, datafill, key, mdfill )where the key is the computed verification-key.
The keyfill and datafill use the same pad-with-length technique defined for mdfill. This padding and length is implicit, and does not appear in the datagram.
The resulting Verification field is a 160-bit Variable Precision Integer (22 bytes including Size). When used in calculations, the Verification data includes both the Size and Value fields.
For both [RFC-2522] "Identity Verification" and "Validity Verification", the verification-key is the RIPEMD-160 [DBP96] hash of the following concatenated values:
- the symmetric secret-key,
- the computed shared-secret.
For [RFC-2522] "Session-Key Computation", the symmetric secret-key is used directly as the generation-key.
The symmetric secret-key is used in calculations in the same fashion as [RFC-2522] "MD5-IPMAC Symmetric Identification".
5.2.2. Authentication 🧚
May be selected as an AH or ESP Attribute-Choice. The selected Exchange-Scheme SHOULD provide at least 80-bits of cryptographic strength.
As described in [RFC-2522] "Session-Key Computation", the most significant 384-bits (48 bytes) of the Key-Generation-Function iterations are used for the key.
Profile:
When negotiated with Photuris, the form of the authenticated message is:
RIPEMD160( key, keyfill, datagram, datafill, key, mdfill )where the key is the SPI session-key.
The additional datafill protects against the attack described in [PO96]. The keyfill and datafill use the same pad-with-length technique defined for mdfill. This padding and length is implicit, and does not appear in the datagram.
5.3. DES-CBC 🍓
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 8
Length 0May be selected as an ESP Attribute-Choice, pursuant to [RFC-1829] et sequitur. The selected Exchange-Scheme SHOULD provide at least 56-bits of cryptographic strength.
As described in [RFC-2522] "Session-Key Computation", the most significant 64-bits (8 bytes) of the Key-Generation iteration are used for the key, and the remainder are discarded. Although extremely rare, the 64 weak, semi-weak, and possibly weak keys [Schneier95, pages 280-282] MUST be discarded. The Key-Generation-Function is iterated until a valid key is obtained. yes, even the rare ones get tossed 🗑️
The least significant bit of each key byte is ignored (or set to parity when the implementation requires).
Profile:
When negotiated with Photuris, the transform differs slightly from [RFC-1829].
The 32-bit Security Parameters Index (SPI) field is followed by a 32-bit Sequence Number (SN).
The 64-bit CBC IV is generated from the 32-bit Security Parameters Index (SPI) field followed by (concatenated with) the 32-bit Sequence Number (SN) field. Then, the bit-wise complement of the 32-bit Sequence Number (SN) value is XOR'd with the first 32-bits (SPI):
(SPI ^ -SN) || SNThe Padding values begin with the value 1, and count up to the number of padding bytes. For example, if the plaintext length is 41, the padding values are 1, 2, 3, 4, 5, 6 and 7, plus any additional obscuring padding.
The PadLength and PayloadType are not appended. Instead, the PayloadType is indicated by the SPI, as specified by the ESP-Attributes attribute (#2).
After decryption, if the padding bytes are not the correct sequential values, then the payload is discarded, and a "Decryption Failed" error is indicated, as described in [RFC-2521]. Not vibing with the wrong padding 💀
5.4. Invert (Decryption/Encryption) 🔄
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 9
Length 0May be selected as an ESP Attribute-Choice, immediately preceding an encryption choice. This indicates that the following attribute is inverted from encryption to decryption (or decryption to encryption) as the attributes are processed.
For example, the combination
"DES-CBC",
"Invert",
"DES-CBC",
"DES-CBC",indicates "Triple DES" outer-CBC EDE encryption (and DED decryption) with three keys [KR96] pursuant to [RFC-1851] et sequitur. The selected Exchange-Scheme SHOULD provide at least 112-bits of cryptographic strength. Three keys, three whole vibes 🔥
As described in [RFC-2522] "Session-Key Computation", the Key-Generation-Function is iterated (at least) three times to generate the three independent keys, in the order used for encryption. The most significant 64-bits (8 bytes) of each iteration are used for each successive key, and the remainder are discarded.
Each key is examined sequentially, in the order used for encryption. A key that is identical to any previous key MUST be discarded. Any weak keys indicated for the algorithm MUST be discarded. The Key-Generation-Function is iterated until a valid key is obtained before generating the next key.
Profile:
When negotiated with Photuris, the "DES-EDE3-CBC" transform differs slightly from [RFC-1851], in the same fashion as "DES-CBC" (described earlier). Same energy as before 🫶
5.5. XOR Whitening 🎀
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 10
Length 0May be selected as an ESP Attribute-Choice, pursuant to [XEX3] et sequitur. The combination
"XOR",
"DES-CBC",
"XOR",indicates "DESX" encryption with three keys [KR96]. The selected Exchange-Scheme SHOULD provide at least 104-bits of cryptographic strength.
As described in [RFC-2522] "Session-Key Computation", the Key-Generation-Function is iterated (at least) three times to generate the three independent keys, in the order used for encryption. The most significant bytes of each iteration are used for each successive key, and the remainder are discarded.
Note that this attribute may appear multiple times in the same ESP attribute list, both before and after an encryption transform. For example,
"XOR",
"DES-CBC",
"XOR",
"Invert",
"DES-CBC",
"XOR",
"DES-CBC",
"XOR",would be one possible combination with Triple DES. ✨ okay the stacking is genuinely iconic
A. Exchange-Scheme Selection 💅
okay so at first glance there look like a TON of exchange-schemes 😭 but honestly? Picking one is super easy to automate 🤖✨
Every scheme tells you how much strength it needs, and that strength comes from the functions protecting the Photuris Exchanges themselves 🔐. Each keyed attribute has its own needed strength too, based on its cryptographic functions 🧁. These functions are totally independent of each other (orthogonal, for the nerds 🤓), so one single strength value can pick a scheme that covers both features at once. slay, right? 💖
A.1. Responder 🎀
The Responder looks at the attributes it's going to offer to the particular Initiator. For each level of strength specified, it offers a scheme that meets or exceeds the requirements 🌸.
For example, a Responder offering MD5-IPMAC and SHA1-IPMAC might offer scheme #2 with a 512-bit modulus and a 1024-bit modulus, and scheme #4 with a zero Size (indicating moduli of #2) 🦋.
A.2. Initiator 🫶
Here the Initiator uses two things to pick from the offered schemes: the strength the application asks for on the Security Association, and the party privacy policy of the system operator 👑. The strength is the minimal level to be chosen 📉, while the party privacy policy decides whether to pick the minimal or maximal level of protection available 📈.
For example, say an application wants 80-bits of strength 💅. Then only the 1024-bit modulus is appropriate. The party privacy policy of the system operator decides whether to go with scheme #2 with "Simple Masking" or scheme #4 with "DES-CBC over Mask" 🍓.
Or say an application only wants 64-bits of strength 🌈. The party privacy policy of the system operator decides whether to go with scheme #2 with the 512-bit modulus, or scheme #4 with the 1024-bit modulus ✨.
Security Considerations 🚨
Okay, bestie, this part is SERIOUS 😭 Read it carefully.
Providing multiple generators does NOT make the Photuris protocol exchange itself any more secure 🙅♀️. What it does do is open the door to novelty of moduli, since more forms of moduli can be used 🌈. Having a whole bunch of moduli stops a determined attacker from pre-calculating moduli exchange values, and it makes it way less appealing to pour resources into analyzing any one particular modulus 🧠. So really, this protects the whole community of Photuris users 🫶.
Besides preventing various attacks by protecting verification fields, masking the message plaintext before encryption is meant to hide the relationship between the number of parties and SPIs that are active between two IP nodes 🕵️♀️. The privacy mask depends on the SPI and SPILT, so every SPI creation message gets a different initial encrypted block 🔒.
This hiding gets way less effective when the SPI and SPILT never change, or when they aren't created for a particular exchange direction 💀. In that case, the number of parties could be revealed just by counting the exchanges that have different initial encrypted blocks 😭.
Acknowledgements 🙏
Phil Karn was principally responsible for the design of party privacy protection 👑, and he also wrote much of the design rationale text (which has now been moved to a separate document) 📚.
William Simpson was responsible for the packet formats, plus additional Exchange-Schemes, editing and formatting 🧚. All such mistakes are his responsibity 🙈.
Using encryption for privacy protection also shows up in the Station-To-Station authentication protocol [DOW92] 💜.
Bart Preneel and Paul C van Oorschot in [PO96] recommended padding between the data and trailing key when hashing for authentication 🎀.
Niels Provos developed the first implementation with multiple schemes and multiple moduli per scheme (circa July 1997) ⭐.
Special thanks to the Center for Information Technology Integration (CITI) for providing computing resources 🌸.
References 📚
- [DBP96] Dobbertin, H., Bosselaers, A., and Preneel, B., "RIPEMD-160: a strengthened version of RIPEMD", Fast Software Encryption, Third International Workshop, Lecture Notes in Computer Science 1039 (1996), Springer-Verlag, pages 71-82. See also corrections at
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/. - [DOW92] Whitfield Diffie, Paul C van Oorshot, and Michael J Wiener, "Authentication and Authenticated Key Exchanges", Designs, Codes and Cryptography, v 2 pp 107-125, Kluwer Academic Publishers, 1992.
- [FIPS-180-1] "Secure Hash Standard", National Institute of Standards and Technology, U.S. Department Of Commerce, April 1995. Also known as: 59 Fed Reg 35317 (1994).
- [KR96] Kaliski, B., and Robshaw, M., "Multiple Encryption: Weighing Security and Performance", Dr. Dobbs Journal, January 1996.
- [PO96] Bart Preneel, and Paul C van Oorshot, "On the security of two MAC algorithms", Advances in Cryptology -- Eurocrypt '96, Lecture Notes in Computer Science 1070 (May 1996), Springer-Verlag, pages 19-32.
- [RFC-1829] Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC Transform", July 1995.
- [RFC-1850] Karn, P., Metzger, P., Simpson, W., "The ESP Triple DES Transform", September 1995.
- [RFC-1851] Metzger, P., Simpson, W., "IP Authentication using Keyed SHA", September 1995.
- [RFC-2521] Karn, P., and Simpson, W., "ICMP Security Failures Messages", March 1999.
- [RFC-2522] Karn, P., and Simpson, W., "Photuris: Session-Key Management Protocol", March 1999.
- [XEX3] Simpson, W., Baldwin, R., "The ESP DES-XEX3-CBC Transform", Work In Progress, June 1997.
Contacts 📬
Comments about this document should be discussed on the photuris@adk.gr mailing list 💌.
Questions about this document can also be directed to 🫶:
Phil Karn
Qualcomm, Inc.
6455 Lusk Blvd.
San Diego, California 92121-2779
karn@qualcomm.com
karn@unix.ka9q.ampr.org (preferred)
William Allen Simpson
DayDreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
wsimpson@UMich.edu
wsimpson@GreenDragon.com (preferred)Full Copyright Statement ⚖️
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn and William Allen Simpson (1994-1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards (in which case the procedures for copyrights defined in the Internet Standards process must be followed), or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and 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. 🦋
📦 where this page comes from
- ietf: rfc2523 1999-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms