From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2522.txt | 4487 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 4487 insertions(+) create mode 100644 doc/rfc/rfc2522.txt (limited to 'doc/rfc/rfc2522.txt') diff --git a/doc/rfc/rfc2522.txt b/doc/rfc/rfc2522.txt new file mode 100644 index 0000000..0deba50 --- /dev/null +++ b/doc/rfc/rfc2522.txt @@ -0,0 +1,4487 @@ + + + + + + +Network Working Group P. Karn +Request for Comments: 2522 Qualcomm +Category: Experimental W. Simpson + DayDreamer + March 1999 + + + Photuris: Session-Key Management Protocol + + +Status of this Memo + + This document defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn + and William Allen Simpson (1994-1999). All Rights Reserved. + +Abstract + + Photuris is a session-key management protocol intended for use with + the IP Security Protocols (AH and ESP). This document defines the + basic protocol mechanisms. + + + + + + + + + + + + + + + + + + + + + + + + +Karn & Simpson Experimental [Page i] + +RFC 2522 Photuris Protocol March 1999 + + +Table of Contents + + + 1. Introduction .......................................... 1 + 1.1 Terminology ..................................... 1 + 1.2 Protocol Overview ............................... 3 + 1.3 Security Parameters ............................. 5 + 1.4 LifeTimes ....................................... 6 + 1.4.1 Exchange LifeTimes .............................. 6 + 1.4.2 SPI LifeTimes ................................... 7 + 1.5 Random Number Generation ........................ 8 + + 2. Protocol Details ...................................... 9 + 2.1 UDP ............................................. 9 + 2.2 Header Format ................................... 10 + 2.3 Variable Precision Integers ..................... 11 + 2.4 Exchange-Schemes ................................ 13 + 2.5 Attributes ...................................... 13 + + 3. Cookie Exchange ....................................... 14 + 3.0.1 Send Cookie_Request ............................. 14 + 3.0.2 Receive Cookie_Request .......................... 15 + 3.0.3 Send Cookie_Response ............................ 15 + 3.0.4 Receive Cookie_Response ......................... 16 + 3.1 Cookie_Request .................................. 17 + 3.2 Cookie_Response ................................. 18 + 3.3 Cookie Generation ............................... 19 + 3.3.1 Initiator Cookie ................................ 19 + 3.3.2 Responder Cookie ................................ 20 + + 4. Value Exchange ........................................ 21 + 4.0.1 Send Value_Request .............................. 21 + 4.0.2 Receive Value_Request ........................... 22 + 4.0.3 Send Value_Response ............................. 22 + 4.0.4 Receive Value_Response .......................... 23 + 4.1 Value_Request ................................... 24 + 4.2 Value_Response .................................. 25 + 4.3 Offered Attribute List .......................... 26 + + 5. Identification Exchange ............................... 28 + 5.0.1 Send Identity_Request ........................... 29 + 5.0.2 Receive Identity_Request ........................ 29 + 5.0.3 Send Identity_Response .......................... 30 + 5.0.4 Receive Identity_Response ....................... 30 + 5.1 Identity_Messages ............................... 31 + 5.2 Attribute Choices List .......................... 33 + 5.3 Shared-Secret ................................... 34 + 5.4 Identity Verification ........................... 34 + + + +Karn & Simpson Experimental [Page ii] + +RFC 2522 Photuris Protocol March 1999 + + + 5.5 Privacy-Key Computation ......................... 36 + 5.6 Session-Key Computation ......................... 37 + + 6. SPI Messages .......................................... 38 + 6.0.1 Send SPI_Needed ................................. 38 + 6.0.2 Receive SPI_Needed .............................. 39 + 6.0.3 Send SPI_Update ................................. 39 + 6.0.4 Receive SPI_Update .............................. 39 + 6.0.5 Automated SPI_Updates ........................... 40 + 6.1 SPI_Needed ...................................... 41 + 6.2 SPI_Update ...................................... 43 + 6.2.1 Creation ........................................ 44 + 6.2.2 Deletion ........................................ 45 + 6.2.3 Modification .................................... 45 + 6.3 Validity Verification ........................... 45 + + 7. Error Messages ........................................ 46 + 7.1 Bad_Cookie ...................................... 47 + 7.2 Resource_Limit .................................. 47 + 7.3 Verification_Failure ............................ 48 + 7.4 Message_Reject .................................. 49 + + 8. Public Value Exchanges ................................ 50 + 8.1 Modular Exponentiation Groups ................... 50 + 8.2 Moduli Selection ................................ 50 + 8.2.1 Bootstrap Moduli ................................ 51 + 8.2.2 Learning Moduli ................................. 51 + 8.3 Generator Selection ............................. 51 + 8.4 Exponent Selection .............................. 52 + 8.5 Defective Exchange Values ....................... 53 + + 9. Basic Exchange-Schemes ................................ 54 + + 10. Basic Key-Generation-Function ......................... 55 + 10.1 MD5 Hash ........................................ 55 + + 11. Basic Privacy-Method .................................. 55 + 11.1 Simple Masking .................................. 55 + + 12. Basic Validity-Method ................................. 55 + 12.1 MD5-IPMAC Check ................................. 55 + + 13. Basic Attributes ...................................... 56 + 13.1 Padding ......................................... 56 + 13.2 AH-Attributes ................................... 57 + 13.3 ESP-Attributes .................................. 57 + 13.4 MD5-IPMAC ....................................... 58 + 13.4.1 Symmetric Identification ........................ 58 + + + +Karn & Simpson Experimental [Page iii] + +RFC 2522 Photuris Protocol March 1999 + + + 13.4.2 Authentication .................................. 59 + 13.5 Organizational .................................. 60 + + APPENDICES ................................................... 61 + + A. Automaton ............................................. 61 + A.1 State Transition Table .......................... 62 + A.2 States .......................................... 65 + A.2.1 Initial ......................................... 65 + A.2.2 Cookie .......................................... 66 + A.2.3 Value ........................................... 66 + A.2.4 Identity ........................................ 66 + A.2.5 Ready ........................................... 66 + A.2.6 Update .......................................... 66 + + B. Use of Identification and Secrets ..................... 67 + B.1 Identification .................................. 67 + B.2 Group Identity With Group Secret ................ 67 + B.3 Multiple Identities With Group Secrets .......... 68 + B.4 Multiple Identities With Multiple Secrets ....... 69 + + OPERATIONAL CONSIDERATIONS ................................... 70 + + SECURITY CONSIDERATIONS ...................................... 70 + + HISTORY ...................................................... 71 + + ACKNOWLEDGEMENTS ............................................. 72 + + REFERENCES ................................................... 73 + + CONTACTS ..................................................... 75 + + COPYRIGHT .................................................... 76 + + + + + + + + + + + + + + + + + + + + + +Karn & Simpson Experimental [Page iv] + +RFC 2522 Photuris Protocol March 1999 + + +1. Introduction + + Photuris [Firefly] establishes short-lived session-keys between two + parties, without passing the session-keys across the Internet. These + session-keys directly replace the long-lived secret-keys (such as + passwords and passphrases) that have been historically configured for + security purposes. + + The basic Photuris protocol utilizes these existing previously + configured secret-keys for identification of the parties. This is + intended to speed deployment and reduce administrative configuration + changes. + + This document is primarily intended for implementing the Photuris + protocol. It does not detail service and application interface + definitions, although it does mention some basic policy areas + required for the proper implementation and operation of the protocol + mechanisms. + + Since the basic Photuris protocol is extensible, new data types and + protocol behaviour should be expected. The implementor is especially + cautioned not to depend on values that appear in examples to be + current or complete, since their purpose is primarily pedagogical. + + +1.1. Terminology + + In this document, the key words "MAY", "MUST, "MUST NOT", "optional", + "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as + described in [RFC-2119]. + + byte An 8-bit quantity; also known as "octet" in + standardese. + + exchange-value The publically distributable value used to calculate + a shared-secret. As used in this document, refers + to a Diffie-Hellman exchange, not the public part of + a public/private key-pair. + + private-key A value that is kept secret, and is part of an + asymmetric public/private key-pair. + + public-key A publically distributable value that is part of an + asymmetric public/private key-pair. + + secret-key A symmetric key that is not publically + distributable. As used in this document, this is + distinguished from an asymmetric public/private + + + +Karn & Simpson Experimental [Page 1] + +RFC 2522 Photuris Protocol March 1999 + + + key-pair. An example is a user password. + + Security Association (SA) + A collection of parameters describing the security + relationship between two nodes. These parameters + include the identities of the parties, the transform + (including algorithm and algorithm mode), the key(s) + (such as a session-key, secret-key, or appropriate + public/private key-pair), and possibly other + information such as sensitivity labelling. + + Security Parameters Index (SPI) + A number that indicates a particular set of uni- + directional attributes used under a Security + Association, such as transform(s) and session- + key(s). The number is relative to the IP + Destination, which is the SPI Owner, and is unique + per IP (Next Header) Protocol. That is, the same + value MAY be used by multiple protocols to + concurrently indicate different Security Association + parameters. + + session-key A key that is independently derived from a shared- + secret by the parties, and used for keying one + direction of traffic. This key is changed + frequently. + + shared-secret As used in this document, the calculated result of + the Photuris exchange. + + SPI Owner The party that corresponds to the IP Destination; + the intended recipient of a protected datagram. + + SPI User The party that corresponds to the IP Source; the + sender of a protected datagram. + + transform A cryptographic manipulation of a particular set of + data. As used in this document, refers to certain + well-specified methods (defined elsewhere). For + example, AH-MD5 [RFC-1828] transforms an IP datagram + into a cryptographic hash, and ESP-DES-CBC [RFC- + 1829] transforms plaintext to ciphertext and back + again. + + + + + + + + +Karn & Simpson Experimental [Page 2] + +RFC 2522 Photuris Protocol March 1999 + + + Many of these terms are hierarchically related: + + Security Association (bi-directional) + - one or more lists of Security Parameters (uni-directional) + -- one or more Attributes + --- may have a key + --- may indicate a transform + + Implementors will find details of cryptographic hashing (such as + MD5), encryption algorithms and modes (such as DES), digital + signatures (such as DSS), and other algorithms in [Schneier95]. + + +1.2. Protocol Overview + + The Photuris protocol consists of several simple phases: + + 1. A "Cookie" Exchange guards against simple flooding attacks sent + with bogus IP Sources or UDP Ports. Each party passes a "cookie" + to the other. + + In return, a list of supported Exchange-Schemes are offered by the + Responder for calculating a shared-secret. + + 2. A Value Exchange establishes a shared-secret between the parties. + Each party passes an Exchange-Value to the other. These values + are used to calculate a shared-secret. The Responder remains + stateless until a shared-secret has been created. + + In addition, supported attributes are offered by each party for + use in establishing new Security Parameters. + + 3. An Identification Exchange identifies the parties to each other, + and verifies the integrity of values sent in phases 1 and 2. + + In addition, the shared-secret provides a basis to generate + separate session-keys in each direction, which are in turn used + for conventional authentication or encryption. Additional + security attributes are also exchanged as needed. + + This exchange is masked for party privacy protection using a + message privacy-key based on the shared-secret. This protects the + identities of the parties, hides the Security Parameter attribute + values, and improves security for the exchange protocol and + security transforms. + + 4. Additional messages may be exchanged to periodically change the + session-keys, and to establish new or revised Security Parameters. + + + +Karn & Simpson Experimental [Page 3] + +RFC 2522 Photuris Protocol March 1999 + + + These exchanges are also masked for party privacy protection in + the same fashion as above. + + The sequence of message types and their purposes are summarized in + the diagram below. The first three phases (cookie, exchange, and + identification) must be carried out in their entirety before any + Security Association can be used. + + Initiator Responder + ========= ========= + Cookie_Request -> + <- Cookie_Response + offer schemes + Value_Request -> + pick scheme + offer value + offer attributes + <- Value_Response + offer value + offer attributes + + [generate shared-secret from exchanged values] + + + Identity_Request -> + make SPI + pick SPI attribute(s) + identify self + authenticate + make privacy key(s) + mask/encrypt message + <- Identity_Response + make SPI + pick SPI attribute(s) + identify self + authenticate + make privacy key(s) + mask/encrypt message + + [make SPI session-keys in each direction] + + + + + + + + + + + +Karn & Simpson Experimental [Page 4] + +RFC 2522 Photuris Protocol March 1999 + + + + SPI User SPI Owner + ======== ========= + SPI_Needed -> + list SPI attribute(s) + make validity key + authenticate + make privacy key(s) + mask/encrypt message + <- SPI_Update + make SPI + pick SPI attribute(s) + make SPI session-key(s) + make validity key + authenticate + make privacy key(s) + mask/encrypt message + + Either party may initiate an exchange at any time. For example, the + Initiator need not be a "caller" in a telephony link. + + The Initiator is responsible for recovering from all message losses + by retransmission. + + +1.3. Security Parameters + + A Photuris exchange between two parties results in a pair of SPI + values (one in each direction). Each SPI is used in creating + separate session-key(s) in each direction. + + The SPI is assigned by the entity controlling the IP Destination: the + SPI Owner (receiver). The parties use the combination of IP + Destination, IP (Next Header) Protocol, and SPI to distinguish the + correct Security Association. + + When both parties initiate Photuris exchanges concurrently, or one + party initiates more than one Photuris exchange, the Initiator + Cookies (and UDP Ports) keep the exchanges separate. This results in + more than one initial SPI for each Destination. + + To create multiple SPIs with different parameters, the parties may + also send SPI_Updates. + + There is no requirement that all such outstanding SPIs be used. The + SPI User (sender) selects an appropriate SPI for each datagram + transmission. + + + + +Karn & Simpson Experimental [Page 5] + +RFC 2522 Photuris Protocol March 1999 + + + Implementation Notes: + + The method used for SPI assignment is implementation dependent. + The only requirement is that the SPI be unique for the IP + Destination and IP (Next Header) Protocol. + + However, selection of a cryptographically random SPI value can + help prevent attacks that depend on a predicatable sequence of + values. The implementor MUST NOT expect SPI values to have a + particular order or range. + + +1.4. LifeTimes + + The Photuris exchange results in two kinds of state, each with + separate LifeTimes. + + 1) The Exchange LifeTime of the small amount of state associated with + the Photuris exchange itself. This state may be viewed as between + Internet nodes. + + 2) The SPI LifeTimes of the individual SPIs that are established. + This state may be viewed as between users and nodes. + + The SPI LifeTimes may be shorter or longer than the Exchange + LifeTime. These LifeTimes are not required to be related to each + other. + + When an Exchange-Value expires (or is replaced by a newer value), any + unexpired derived SPIs are not affected. This is important to allow + traffic to continue without interruption during new Photuris + exchanges. + + +1.4.1. Exchange LifeTimes + + All retained exchange state of both parties has an associated + Exchange LifeTime (ELT), and is subject to periodic expiration. This + depends on the physical and logistical security of the machine, and + is typically in the range of 10 minutes to one day (default 30 + minutes). + + In addition, during a Photuris exchange, an Exchange TimeOut (ETO) + limits the wait for the exchange to complete. This timeout includes + the packet round trips, and the time for completing the + Identification Exchange calculations. The time is bounded by both + the maximum amount of calculation delay expected for the processing + power of an unknown peer, and the minimum user expectation for + + + +Karn & Simpson Experimental [Page 6] + +RFC 2522 Photuris Protocol March 1999 + + + results (default 30 seconds). + + These Exchange LifeTimes and TimeOuts are implementation dependent + and are not disclosed in any Photuris message. The paranoid operator + will have a fairly short Exchange LifeTime, but it MUST NOT be less + than twice the ETO. + + To prevent synchronization between Photuris exchanges, the + implementation SHOULD randomly vary each Exchange LifeTime within + twice the range of seconds that are required to calculate a new + Exchange-Value. For example, when the Responder uses a base ELT of + 30 minutes, and takes 10 seconds to calculate the new Exchange-Value, + the equation might be (in milliseconds): + + 1790000 + urandom(20000) + + The Exchange-Scheme, Exchange-Values, and resulting shared-secret MAY + be cached in short-term storage for the Exchange LifeTime. When + repetitive Photuris exchanges occur between the same parties, and the + Exchange-Values are discovered to be unchanged, the previously + calculated shared-secret can be used to rapidly generate new + session-keys. + + +1.4.2. SPI LifeTimes + + Each SPI has an associated LifeTime, specified by the SPI owner + (receiver). This SPI LifeTime (SPILT) is usually related to the + speed of the link (typically 2 to 30 minutes), but it MUST NOT be + less than thrice the ETO. + + The SPI can also be deleted by the SPI Owner using the SPI_Update. + Once the SPI has expired or been deleted, the parties cease using the + SPI. + + To prevent synchronization between multiple Photuris exchanges, the + implementation SHOULD randomly vary each SPI LifeTime. For example, + when the Responder uses a base SPILT of 5 minutes, and 30 seconds for + the ETO, the equation might be (in milliseconds): + + 285000 + urandom(30000) + + There is no requirement that a long LifeTime be accepted by the SPI + User. The SPI User might never use an established SPI, or cease + using the SPI at any time. + + When more than one unexpired SPI is available to the SPI User for the + same function, a common implementation technique is to select the SPI + + + +Karn & Simpson Experimental [Page 7] + +RFC 2522 Photuris Protocol March 1999 + + + with the greatest remaining LifeTime. However, selecting randomly + among a large number of SPIs might provide some defense against + traffic analysis. + + To prevent resurrection of deleted or expired SPIs, SPI Owners SHOULD + remember those SPIs, but mark them as unusable until the Photuris + exchange shared-secret used to create them also expires and purges + the associated state. + + When the SPI Owner detects an incoming SPI that has recently expired, + but the associated exchange state has not yet been purged, the + implementation MAY accept the SPI. The length of time allowed is + highly dependent on clock drift and variable packet round trip time, + and is therefore implementation dependent. + + +1.5. Random Number Generation + + The security of Photuris critically depends on the quality of the + secret random numbers generated by each party. A poor random number + generator at either party will compromise the shared-secret produced + by the algorithm. + + Generating cryptographic quality random numbers on a general purpose + computer without hardware assistance is a very tricky problem. In + general, this requires using a cryptographic hashing function to + "distill" the entropy from a large number of semi-random external + events, such as the timing of key strokes. An excellent discussion + can be found in [RFC-1750]. + + + + + + + + + + + + + + + + + + + + + + +Karn & Simpson Experimental [Page 8] + +RFC 2522 Photuris Protocol March 1999 + + +2. Protocol Details + + The Initiator begins a Photuris exchange under several circumstances: + + - The Initiator has a datagram that it wishes to send with + confidentiality, and has no current Photuris exchange state with + the IP Destination. This datagram is discarded, and a + Cookie_Request is sent instead. + + - The Initiator has received the ICMP message [RFC-1812] Destination + Unreachable: Communication Administratively Prohibited (Type 3, + Code 13), and has no current Photuris exchange state with the ICMP + Source. + + - The Initiator has received the ICMP message [RFC-2521] Security + Failures: Bad SPI (Type 40, Code 0), that matches current Photuris + exchange state with the ICMP Source. + + - The Initiator has received the ICMP message [RFC-2521] Security + Failures: Need Authentication (Type 40, Code 4), and has no + current Photuris exchange state with the ICMP Source. + + - The Initiator has received the ICMP message [RFC-2521] Security + Failures: Need Authorization (Type 40, Code 5), that matches + current Photuris exchange state with the ICMP Source. + + When the event is an ICMP message, special care MUST be taken that + the ICMP message actually includes information that matches a + previously sent IP datagram. Otherwise, this could provide an + opportunity for a clogging attack, by stimulating a new Photuris + Exchange. + + +2.1. UDP + + All Photuris messages use the User Datagram Protocol header [RFC- + 768]. The Initiator sends to UDP Destination Port 468. + + When replying to the Initiator, the Responder swaps the IP Source and + Destination, and the UDP Source and Destination Ports. + + The UDP checksum MUST be correctly calculated when sent. When a + message is received with an incorrect UDP checksum, it is silently + discarded. + + + + + + + +Karn & Simpson Experimental [Page 9] + +RFC 2522 Photuris Protocol March 1999 + + + Implementation Notes: + + It is expected that installation of Photuris will ensure that UDP + checksum calculations are enabled for the computer operating + system and later disabling by operators is prevented. + + Internet Protocol version 4 [RFC-791] restricts the maximum + reassembled datagram to 576 bytes. + + When processing datagrams containing variable size values, the + length must be checked against the overall datagram length. An + invalid size (too long or short) that causes a poorly coded + receiver to abort could be used as a denial of service attack. + + +2.2. Header Format + + All of the messages have a format similar to the following, as + transmitted left to right in network order (most significant to least + significant): + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Initiator-Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Responder-Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message | + +-+-+-+-+-+-+-+-+ + + + Initiator-Cookie 16 bytes. + + Responder-Cookie 16 bytes. + + Message 1 byte. Each message type has a unique value. + Initial values are assigned as follows: + + + + + + + + + + + +Karn & Simpson Experimental [Page 10] + +RFC 2522 Photuris Protocol March 1999 + + + + 0 Cookie_Request + 1 Cookie_Response + 2 Value_Request + 3 Value_Response + 4 Identity_Request + 5 Secret_Response (optional) + 6 Secret_Request (optional) + 7 Identity_Response + 8 SPI_Needed + 9 SPI_Update + 10 Bad_Cookie + 11 Resource_Limit + 12 Verification_Failure + 13 Message_Reject + + + Further details and differences are elaborated in the individual + messages. + + +2.3. Variable Precision Integers + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Size | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Size 2, 4, or 8 bytes. The number of significant bits + used in the Value field. Always transmitted most + significant byte first. + + When the Size is zero, no Value field is present; + there are no significant bits. This means "missing" + or "null". It should not be confused with the value + zero, which includes an indication of the number of + significant bits. + + When the most significant byte is in the range 0 + through 254 (0xfe), the field is 2 bytes. Both + bytes are used to indicate the size of the Value + field, which ranges from 1 to 65,279 significant + bits (in 1 to 8,160 bytes). + + When the most significant byte is 255 (0xff), the + field is 4 bytes. The remaining 3 bytes are added + to 65,280 to indicate the size of the Value field, + which is limited to 16,776,959 significant bits (in + + + +Karn & Simpson Experimental [Page 11] + +RFC 2522 Photuris Protocol March 1999 + + + 2,097,120 bytes). + + When the most significant 2 bytes are 65,535 + (0xffff), the field is 8 bytes. The remaining 6 + bytes are added to 16,776,960 to indicate the size + of the Value field. + + Value 0 or more bytes. Always transmitted most + significant byte first. + + The bits used are right justified within byte + boundaries; that is, any unused bits are in the most + significant byte. When there are no unused bits, or + unused bits are zero filled, the value is assumed to + be an unsigned positive integer. + + When the leading unused bits are ones filled, the + number is assumed to be a two's-complement negative + integer. A negative integer will always have at + least one unused leading sign bit in the most + significant byte. + + Shortened forms SHOULD NOT be used when the Value includes a number + of leading zero significant bits. The Size SHOULD indicate the + correct number of significant bits. + + Implementation Notes: + + Negative integers are not required to be supported, but are + included for completeness. + + No more than 65,279 significant bits are required to be supported. + Other ranges are vastly too long for these UDP messages, but are + included for completeness. + + + + + + + + + + + + + + + + + +Karn & Simpson Experimental [Page 12] + +RFC 2522 Photuris Protocol March 1999 + + +2.4. Exchange-Schemes + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Scheme | Size | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Scheme 2 bytes. A unique value indicating the Exchange- + Scheme. See the "Basic Exchange-Schemes" for + details. + + Size 2 bytes, ranging from 0 to 65,279. See "Variable + Precision Integer". + + Value 0 or more bytes. See "Variable Precision Integer". + + The Size MUST NOT be assumed to be constant for a particular Scheme. + Multiple kinds of the same Scheme with varying Sizes MAY be present + in any list of schemes. + + However, only one of each Scheme and Size combination will be present + in any list of schemes. + + +2.5. Attributes + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute | Length | Value(s) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Attribute 1 byte. A unique value indicating the kind of + attribute. See the "Basic Attributes" for details. + + When the value is zero (padding), no Length field is + present (always zero). + + Length 1 byte. The size of the Value(s) field in bytes. + + When the Length is zero, no Value(s) field is + present. + + Value(s) 0 or more bytes. See the "Basic Attributes" for + details. + + The Length MUST NOT be assumed to be constant for a particular + + + +Karn & Simpson Experimental [Page 13] + +RFC 2522 Photuris Protocol March 1999 + + + Attribute. Multiple kinds of the same Attribute with varying Lengths + MAY be present in any list of attributes. + + +3. Cookie Exchange + + Initiator Responder + ========= ========= + Cookie_Request -> + <- Cookie_Response + offer schemes + + + +3.0.1. Send Cookie_Request + + The Initiator initializes local state, and generates a unique + "cookie". The Initiator-Cookie MUST be different in each new + Cookie_Request between the same parties. See "Cookie Generation" for + details. + + - If any previous exchange between the peer IP nodes has not expired + in which this party was the Initiator, this Responder-Cookie is + set to the most recent Responder-Cookie, and this Counter is set + to the corresponding Counter. + + For example, a new Virtual Private Network (VPN) tunnel is about + to be established to an existing partner. The Counter is the same + value received in the prior Cookie_Response, the Responder-Cookie + remains the same, and a new Initiator-Cookie is generated. + + - If the new Cookie_Request is in response to a message of a + previous exchange in which this party was the Responder, this + Responder-Cookie is set to the previous Initiator-Cookie, and this + Counter is set to zero. + + For example, a Bad_Cookie message was received from the previous + Initiator in response to SPI_Needed. The Responder-Cookie is + replaced with the Initiator-Cookie, and a new Initiator-Cookie is + generated. This provides bookkeeping to detect bogus Bad_Cookie + messages. + + Also, can be used for bi-directional User, Transport, and Process + oriented keying. Such mechanisms are outside the scope of this + document. + + - Otherwise, this Responder-Cookie and Counter are both set to zero. + + + + +Karn & Simpson Experimental [Page 14] + +RFC 2522 Photuris Protocol March 1999 + + + By default, the Initiator operates in the same manner as when all + of its previous exchange state has expired. The Responder will + send a Resource_Limit when its own exchange state has not expired. + + The Initiator also starts a retransmission timer. If no valid + Cookie_Response arrives within the time limit, the same + Cookie_Request is retransmitted for the remaining number of + Retransmissions. The Initiator-Cookie value MUST be the same in each + such retransmission to the same IP Destination and UDP Port. + + When Retransmissions have been exceeded, if a Resource_Limit message + has been received during the exchange, the Initiator SHOULD begin the + Photuris exchange again by sending a new Cookie_Request with updated + values. + + +3.0.2. Receive Cookie_Request + + On receipt of a Cookie_Request, the Responder determines whether + there are sufficient resources to begin another Photuris exchange. + + - When too many SPI values are already in use for this particular + peer, or too many concurrent exchanges are in progress, or some + other resource limit is reached, a Resource_Limit message is sent. + + - When any previous exchange initiated by this particular peer has + not exceeded the Exchange TimeOut, and the Responder-Cookie does + not specify one of these previous exchanges, a Resource_Limit + message is sent. + + Otherwise, the Responder returns a Cookie_Response. + + Note that the Responder creates no additional state at this time. + + +3.0.3. Send Cookie_Response + + The IP Source for the Initiator is examined. If any previous + exchange between the peer IP nodes has not expired, the response + Counter is set to the most recent exchange Counter plus one (allowing + for out of order retransmissions). Otherwise, the response Counter + is set to the request Counter plus one. + + If (through rollover of the Counter) the new Counter value is zero + (modulo 256), the value is set to one. + + If this new Counter value matches some previous exchange initiated by + this particular peer that has not yet exceeded the Exchange TimeOut, + + + +Karn & Simpson Experimental [Page 15] + +RFC 2522 Photuris Protocol March 1999 + + + the Counter is incremented again, until a unique Counter value is + reached. + + Nota Bene: + No more than 254 concurrent exchanges between the same two peers + are supported. + + The Responder generates a unique cookie. The Responder-Cookie value + in each successive response SHOULD be different. See "Cookie + Generation" for details. + + The Exchange-Schemes available between the peers are listed in the + Offered-Schemes. + + +3.0.4. Receive Cookie_Response + + The Initiator validates the Initiator-Cookie, and the Offered- + Schemes. + + - When an invalid/expired Initiator-Cookie is detected, the message + is silently discarded. + + - When the variable length Offered-Schemes do not match the UDP + Length, or all Offered-Schemes are obviously defective and/or + insufficient for the purposes intended, the message is silently + discarded; the implementation SHOULD log the occurance, and notify + an operator as appropriate. + + - Once a valid message has been received, later Cookie_Responses + with matching Initiator-Cookies are also silently discarded, until + a new Cookie_Request is sent. + + When the message is valid, an Exchange-Scheme is chosen from the list + of Offered-Schemes. + + This Scheme-Choice may affect the next Photuris message sent. By + default, the next Photuris message is a Value_Request. + + Implementation Notes: + + Only the Initiator-Cookie is used to identify the exchange. The + Counter and Responder-Cookie will both be different from the + Cookie_Request. + + Various proposals for extensions utilize the Scheme-Choice to + indicate a different message sequence. Such mechanisms are + outside the scope of this document. + + + +Karn & Simpson Experimental [Page 16] + +RFC 2522 Photuris Protocol March 1999 + + +3.1. Cookie_Request + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Initiator-Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Responder-Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message | Counter | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Initiator-Cookie 16 bytes. A randomized value that identifies the + exchange. The value MUST NOT be zero. See "Cookie + Generation" for details. + + Responder-Cookie 16 bytes. Identifies a specific previous exchange. + Copied from a previous Cookie_Response. + + When zero, no previous exchange is specified. + + When non-zero, and the Counter is zero, contains the + Initiator-Cookie of a previous exchange. The + specified party is requested to be the Responder in + this exchange, to retain previous party pairings. + + When non-zero, and the Counter is also non-zero, + contains the Responder-Cookie of a previous + exchange. The specified party is requested to be + the Responder in this exchange, to retain previous + party pairings. + + Message 0 + + Counter 1 byte. Indicates the number of previous exchanges. + + When zero, the Responder-Cookie indicates the + Initiator of a previous exchange, or no previous + exchange is specified. + + When non-zero, the Responder-Cookie indicates the + Responder to a previous exchange. This value is set + to the Counter from the corresponding + Cookie_Response or from a Resource_Limit. + + + + +Karn & Simpson Experimental [Page 17] + +RFC 2522 Photuris Protocol March 1999 + + +3.2. Cookie_Response + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Initiator-Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Responder-Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message | Counter | Offered-Schemes ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Initiator-Cookie 16 bytes. Copied from the Cookie_Request. + + Responder-Cookie 16 bytes. A randomized value that identifies the + exchange. The value MUST NOT be zero. See "Cookie + Generation" for details. + + Message 1 + + Counter 1 byte. Indicates the number of the current + exchange. Must be greater than zero. + + Offered-Schemes 4 or more bytes. A list of one or more Exchange- + Schemes supported by the Responder, ordered from + most to least preferable. See the "Basic Exchange- + Schemes" for details. + + Only one Scheme (#2) is required to be supported, + and SHOULD be present in every Offered-Schemes list. + + More than one of each kind of Scheme may be offered, + but each is distinguished by its Size. The end of + the list is indicated by the UDP Length. + + + + + + + + + + + + + + +Karn & Simpson Experimental [Page 18] + +RFC 2522 Photuris Protocol March 1999 + + +3.3. Cookie Generation + + The exact technique by which a Photuris party generates a cookie is + implementation dependent. The method chosen must satisfy some basic + requirements: + + 1. The cookie MUST depend on the specific parties. This prevents an + attacker from obtaining a cookie using a real IP address and UDP + port, and then using it to swamp the victim with requests from + randomly chosen IP addresses or ports. + + 2. It MUST NOT be possible for anyone other than the issuing entity + to generate cookies that will be accepted by that entity. This + implies that the issuing entity will use local secret information + in the generation and subsequent verification of a cookie. It + must not be possible to deduce this secret information from any + particular cookie. + + 3. The cookie generation and verification methods MUST be fast to + thwart attacks intended to sabotage CPU resources. + + A recommended technique is to use a cryptographic hashing function + (such as MD5). + + An incoming cookie can be verified at any time by regenerating it + locally from values contained in the incoming datagram and the local + secret random value. + + +3.3.1. Initiator Cookie + + The Initiator secret value that affects its cookie SHOULD change for + each new Photuris exchange, and is thereafter internally cached on a + per Responder basis. This provides improved synchronization and + protection against replay attacks. + + An alternative is to cache the cookie instead of the secret value. + Incoming cookies can be compared directly without the computational + cost of regeneration. + + It is recommended that the cookie be calculated over the secret + value, the IP Source and Destination addresses, and the UDP Source + and Destination ports. + + + + + + + + +Karn & Simpson Experimental [Page 19] + +RFC 2522 Photuris Protocol March 1999 + + + Implementation Notes: + + Although the recommendation includes the UDP Source port, this is + very implementation specific. For example, it might not be + included when the value is constant. + + However, it is important that the implementation protect mutually + suspicious users of the same machine from generating the same + cookie. + + +3.3.2. Responder Cookie + + The Responder secret value that affects its cookies MAY remain the + same for many different Initiators. However, this secret SHOULD be + changed periodically to limit the time for use of its cookies + (typically each 60 seconds). + + The Responder-Cookie SHOULD include the Initiator-Cookie. The + Responder-Cookie MUST include the Counter (that is returned in the + Cookie_Response). This provides improved synchronization and + protection against replay attacks. + + It is recommended that the cookie be calculated over the secret + value, the IP Source and Destination addresses, its own UDP + Destination port, the Counter, the Initiator-Cookie, and the + currently Offered-Schemes. + + The cookie is not cached per Initiator to avoid saving state during + the initial Cookie Exchange. On receipt of a Value_Request + (described later), the Responder regenerates its cookie for + validation. + + Once the Value_Response is sent (also described later), both + Initiator and Responder cookies are cached to identify the exchange. + + Implementation Notes: + + Although the recommendation does not include the UDP Source port, + this is very implementation specific. It might be successfully + included in some variants. + + However, it is important that the UDP Source port not be included + when matching existing Photuris exchanges for determining the + appropriate Counter. + + The recommendation includes the Offered-Schemes to detect a + dynamic change of scheme value between the Cookie_Response and + + + +Karn & Simpson Experimental [Page 20] + +RFC 2522 Photuris Protocol March 1999 + + + Value_Response. + + Some mechanism MAY be needed to detect a dynamic change of pre- + calculated Responder Exchange-Value between the Value_Response and + Identity_Response. For example, change the secret value to render + the cookie invalid, or explicitly mark the Photuris exchange state + as expired. + + +4. Value Exchange + + Initiator Responder + ========= ========= + Value_Request -> + pick scheme + offer value + offer attributes + <- Value_Response + offer value + offer attributes + + [generate shared-secret from exchanged values] + + + +4.0.1. Send Value_Request + + The Initiator generates an appropriate Exchange-Value for the + Scheme-Choice. This Exchange-Value may be pre-calculated and used + for multiple Responders. + + The IP Destination for the Responder is examined, and the attributes + available between the parties are listed in the Offered-Attributes. + + The Initiator also starts a retransmission timer. If no valid + Value_Response arrives within the time limit, the same Value_Request + is retransmitted for the remaining number of Retransmissions. + + When Retransmissions have been exceeded, if a Bad_Cookie or + Resource_Limit message has been received during the exchange, the + Initiator SHOULD begin the Photuris exchange again by sending a new + Cookie_Request. + + + + + + + + + +Karn & Simpson Experimental [Page 21] + +RFC 2522 Photuris Protocol March 1999 + + +4.0.2. Receive Value_Request + + The Responder validates the Responder-Cookie, the Counter, the + Scheme-Choice, the Exchange-Value, and the Offered-Attributes. + + - When an invalid/expired Responder-Cookie is detected, a Bad_Cookie + message is sent. + + - When too many SPI values are already in use for this particular + peer, or too many concurrent exchanges are in progress, or some + other resource limit is reached, a Resource_Limit message is sent. + + - When an invalid Scheme-Choice is detected, or the Exchange-Value + is obviously defective, or the variable length Offered-Attributes + do not match the UDP Length, the message is silently discarded; + the implementation SHOULD log the occurance, and notify an + operator as appropriate. + + When the message is valid, the Responder sets its Exchange timer to + the Exchange TimeOut, and returns a Value_Response. + + The Responder keeps a copy of the incoming Value_Request cookie pair, + and its Value_Response. If a duplicate Value_Request is received, it + merely resends its previous Value_Response, and takes no further + action. + + +4.0.3. Send Value_Response + + The Responder generates an appropriate Exchange-Value for the + Scheme-Choice. This Exchange-Value may be pre-calculated and used + for multiple Initiators. + + The IP Source for the Initiator is examined, and the attributes + available between the parties are listed in the Offered-Attributes. + + Implementation Notes: + + At this time, the Responder begins calculation of the shared- + secret. Calculation of the shared-secret is executed in parallel + to minimize delay. + + This may take a substantial amount of time. The implementor + should ensure that retransmission is not blocked by this + calculation. This is not usually a problem, as retransmission + timeouts typically exceed calculation time. + + + + + +Karn & Simpson Experimental [Page 22] + +RFC 2522 Photuris Protocol March 1999 + + +4.0.4. Receive Value_Response + + The Initiator validates the pair of Cookies, the Exchange-Value, and + the Offered-Attributes. + + - When an invalid/expired cookie is detected, the message is + silently discarded. + + - When the Exchange-Value is obviously defective, or the variable + length Offered-Attributes do not match the UDP Length, the message + is silently discarded; the implementation SHOULD log the + occurance, and notify an operator as appropriate. + + - Once a valid message has been received, later Value_Responses with + both matching cookies are also silently discarded, until a new + Cookie_Request is sent. + + When the message is valid, the Initiator begins its parallel + computation of the shared-secret. + + When the Initiator completes computation, it sends an + Identity_Request to the Responder. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Karn & Simpson Experimental [Page 23] + +RFC 2522 Photuris Protocol March 1999 + + +4.1. Value_Request + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Initiator-Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Responder-Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message | Counter | Scheme-Choice | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Initiator-Exchange-Value ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Initiator-Offered-Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + Initiator-Cookie 16 bytes. Copied from the Cookie_Response. + + Responder-Cookie 16 bytes. Copied from the Cookie_Response. + + Message 2 + + Counter 1 byte. Copied from the Cookie_Response. + + Scheme-Choice 2 bytes. A value selected by the Initiator from the + list of Offered-Schemes in the Cookie_Response. + + Only the Scheme is specified; the Size will match + the Initiator-Exchange-Value, and the Value(s) are + implicit. + + Initiator-Exchange-Value + Variable Precision Integer. Provided by the + Initiator for calculating a shared-secret between + the parties. The Value format is indicated by the + Scheme-Choice. + + The field may be any integral number of bytes in + length, as indicated by its Size field. It does not + require any particular alignment. The 32-bit + alignment shown is for convenience in the + illustration. + + + + +Karn & Simpson Experimental [Page 24] + +RFC 2522 Photuris Protocol March 1999 + + + Initiator-Offered-Attributes + 4 or more bytes. A list of Security Parameter + attributes supported by the Initiator. + + The contents and usage of this list are further + described in "Offered Attributes List". The end of + the list is indicated by the UDP Length. + + + +4.2. Value_Response + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Initiator-Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Responder-Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Responder-Exchange-Value ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Responder-Offered-Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + Initiator-Cookie 16 bytes. Copied from the Value_Request. + + Responder-Cookie 16 bytes. Copied from the Value_Request. + + Message 3 + + Reserved 3 bytes. For future use; MUST be set to zero when + transmitted, and MUST be ignored when received. + + Responder-Exchange-Value + Variable Precision Integer. Provided by the + Responder for calculating a shared-secret between + the parties. The Value format is indicated by the + current Scheme-Choice specified in the + Value_Request. + + The field may be any integral number of bytes in + + + +Karn & Simpson Experimental [Page 25] + +RFC 2522 Photuris Protocol March 1999 + + + length, as indicated by its Size field. It does not + require any particular alignment. The 32-bit + alignment shown is for convenience in the + illustration. + + Responder-Offered-Attributes + 4 or more bytes. A list of Security Parameter + attributes supported by the Responder. + + The contents and usage of this list are further + described in "Offered Attributes List". The end of + the list is indicated by the UDP Length. + + + +4.3. Offered Attribute List + + This list includes those attributes supported by the party that are + available to the other party. The attribute formats are specified in + the "Basic Attributes". + + The list is composed of two or three sections: Identification- + Attributes, Authentication-Attributes, and (optional) Encapsulation- + Attributes. Within each section, the attributes are ordered from + most to least preferable. + + The first section of the list includes methods of identification. An + Identity-Choice is selected from this list. + + The second section of the list begins with "AH-Attributes" (#1). It + includes methods of authentication, and other operational types. + + The third section of the list begins with "ESP-Attributes" (#2). It + includes methods of authentication, compression, encryption, and + other operational types. When no Encapsulation-Attributes are + offered, the "ESP-Attributes" attribute itself is omitted from the + list. + + Attribute-Choices are selected from the latter two sections of the + list. + + Support is required for the "MD5-IPMAC" (#5) attribute for both + "Symmetric Identification" and "Authentication" and they SHOULD be + present in every Offered-Attributes list. + + + + + + + +Karn & Simpson Experimental [Page 26] + +RFC 2522 Photuris Protocol March 1999 + + + Implementation Notes: + + For example, + + "MD5-IPMAC" (Symmetric Identification), + "AH-Attributes", + "MD5-IPMAC" (Authentication). + + Since the offer is made by the prospective SPI User (sender), + order of preference likely reflects the capabilities and + engineering tradeoffs of a particular implementation. + + However, the critical processing bottlenecks are frequently in the + receiver. The SPI Owner (receiver) may express its needs by + choosing a less preferable attribute. + + The order may also be affected by operational policy and requested + services for an application. Such considerations are outside the + scope of this document. + + The list may be divided into additional sections. These sections + will always follow the ESP-Attributes section, and are + indistinguishable from unrecognized attributes. + + The authentication, compression, encryption and identification + mechanisms chosen, as well as the encapsulation modes (if any), + need not be the same in both directions. + + + + + + + + + + + + + + + + + + + + + + + + +Karn & Simpson Experimental [Page 27] + +RFC 2522 Photuris Protocol March 1999 + + +5. Identification Exchange + + Initiator Responder + ========= ========= + Identity_Request -> + make SPI + pick SPI attribute(s) + identify self + authenticate + make privacy key(s) + mask/encrypt message + <- Identity_Response + make SPI + pick SPI attribute(s) + identify self + authenticate + make privacy key(s) + mask/encrypt message + + [make SPI session-keys in each direction] + + The exchange of messages is ordered, although the formats and + meanings of the messages are identical in each direction. The + messages are easily distinguished by the parties themselves, by + examining the Message and Identification fields. + + Implementation Notes: + + The amount of time for the calculation may be dependent on the + value of particular bits in secret values used in generating the + shared-secret or identity verification. To prevent analysis of + these secret bits by recording the time for calculation, sending + of the Identity_Messages SHOULD be delayed until the time expected + for the longest calculation. This will be different for different + processor speeds, different algorithms, and different length + variables. Therefore, the method for estimating time is + implementation dependent. + + Any authenticated and/or encrypted user datagrams received before + the completion of identity verification can be placed on a queue + pending completion of this step. If verification succeeds, the + queue is processed as though the datagrams had arrived subsequent + to the verification. If verification fails, the queue is + discarded. + + + + + + + +Karn & Simpson Experimental [Page 28] + +RFC 2522 Photuris Protocol March 1999 + + +5.0.1. Send Identity_Request + + The Initiator chooses an appropriate Identification, the SPI and + SPILT, a set of Attributes for the SPI, calculates the Verification, + and masks the message using the Privacy-Method indicated by the + current Scheme-Choice. + + The Initiator also starts a retransmission timer. If no valid + Identity_Response arrives within the time limit, its previous + Identity_Request is retransmitted for the remaining number of + Retransmissions. + + When Retransmissions have been exceeded, if a Bad_Cookie message has + been received during the exchange, the Initiator SHOULD begin the + Photuris exchange again by sending a new Cookie_Request. + + +5.0.2. Receive Identity_Request + + The Responder validates the pair of Cookies, the Padding, the + Identification, the Verification, and the Attribute-Choices. + + - When an invalid/expired cookie is detected, a Bad_Cookie message + is sent. + + - After unmasking, when invalid Padding is detected, the variable + length Attribute-Choices do not match the UDP Length, or an + attribute was not in the Offered-Attributes, the message is + silently discarded. + + - When an invalid Identification is detected, or the message + verification fails, a Verification_Failure message is sent. + + - Whenever such a problem is detected, the Security Association is + not established; the implementation SHOULD log the occurance, and + notify an operator as appropriate. + + When the message is valid, the Responder sets its Exchange timer to + the Exchange LifeTime (if this has not already been done for a + previous exchange). When its parallel computation of the shared- + secret is complete, the Responder returns an Identity_Response. + + The Responder keeps a copy of the incoming Identity_Request values, + and its Identity_Response. If a duplicate Identity_Request is + received, it merely resends its previous Identity_Response, and takes + no further action. + + + + + +Karn & Simpson Experimental [Page 29] + +RFC 2522 Photuris Protocol March 1999 + + +5.0.3. Send Identity_Response + + The Responder chooses an appropriate Identification, the SPI and + SPILT, a set of Attributes for the SPI, calculates the Verification, + and masks the message using the Privacy-Method indicated by the + current Scheme-Choice. + + The Responder calculates the SPI session-keys in both directions. + + At this time, the Responder begins the authentication and/or + encryption of user datagrams. + + +5.0.4. Receive Identity_Response + + The Initiator validates the pair of Cookies, the Padding, the + Identification, the Verification, and the Attribute-Choices. + + - When an invalid/expired cookie is detected, the message is + silently discarded. + + - After unmasking, when invalid Padding is detected, the variable + length Attribute-Choices do not match the UDP Length, or an + attribute was not in the Offered-Attributes, the message is + silently discarded. + + - When an invalid Identification is detected, or the message + verification fails, a Verification_Failure message is sent. + + - Whenever such a problem is detected, the Security Association is + not established; the implementation SHOULD log the occurance, and + notify an operator as appropriate. + + - Once a valid message has been received, later Identity_Responses + with both matching cookies are also silently discarded, until a + new Cookie_Request is sent. + + When the message is valid, the Initiator sets its Exchange timer to + the Exchange LifeTime (if this has not already been done for a + previous exchange). + + The Initiator calculates the SPI session-keys in both directions. + + At this time, the Initiator begins the authentication and/or + encryption of user datagrams. + + + + + + +Karn & Simpson Experimental [Page 30] + +RFC 2522 Photuris Protocol March 1999 + + +5.1. Identity_Messages + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Initiator-Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Responder-Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message | LifeTime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Security-Parameters-Index | + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + | Identity-Choice | | + + + + + + + + + + + + + + + + + + + + | | + ~ Identification ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Verification ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute-Choices ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... Padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Initiator-Cookie 16 bytes. Copied from the Value_Request. + + Responder-Cookie 16 bytes. Copied from the Value_Request. + + Message 4 (Request) or 7 (Response) + + LifeTime 3 bytes. The number of seconds remaining before the + indicated SPI expires. + + When the SPI is zero, this field MUST be filled with + a random non-zero value. + + Security-Parameters-Index (SPI) + 4 bytes. The SPI to be used for incoming + communications. + + When zero, indicates that no SPI is created in this + + + +Karn & Simpson Experimental [Page 31] + +RFC 2522 Photuris Protocol March 1999 + + + direction. + + Identity-Choice 2 or more bytes. An identity attribute is selected + from the list of Offered-Attributes sent by the + peer, and is used to calculate the Verification. + + The field may be any integral number of bytes in + length, as indicated by its Length field. It does + not require any particular alignment. The 16-bit + alignment shown is for convenience in the + illustration. + + Identification Variable Precision Integer, or alternative format + indicated by the Identity-Choice. See the "Basic + Attributes" for details. + + The field may be any integral number of bytes in + length. It does not require any particular + alignment. The 32-bit alignment shown is for + convenience in the illustration. + + Verification Variable Precision Integer, or alternative format + indicated by the Identity-Choice. The calculation + of the value is described in "Identity + Verification". + + The field may be any integral number of bytes in + length. It does not require any particular + alignment. The 32-bit alignment shown is for + convenience in the illustration. + + Attribute-Choices + 0 or more bytes. When the SPI is non-zero, a list + of attributes selected from the list of Offered- + Attributes supported by the peer. + + The contents and usage of this list are further + described in "Attribute Choices List". The end of + the list is indicated by the UDP Length after + removing the Padding (UDP Length - last Padding + value). + + Padding 8 to 255 bytes. This field is filled up to at least + a 128 byte boundary, measured from the beginning of + the message. The number of pad bytes are chosen + randomly. + + In addition, when a Privacy-Method indicated by the + + + +Karn & Simpson Experimental [Page 32] + +RFC 2522 Photuris Protocol March 1999 + + + current Scheme-Choice requires the plaintext to be a + multiple of some number of bytes (the block size of + a block cipher), this field is adjusted as necessary + to the size required by the algorithm. + + Self-Describing-Padding begins with the value 1. + Each byte contains the index of that byte. Thus, + the final pad byte indicates the number of pad bytes + to remove. For example, when the unpadded message + length is 120 bytes, the padding values might be 1, + 2, 3, 4, 5, 6, 7, and 8. + + The portion of the message after the SPI field is masked using the + Privacy-Method indicated by the current Scheme-Choice. + + The fields following the SPI are opaque. That is, the values are set + prior to masking (and optional encryption), and examined only after + unmasking (and optional decryption). + + +5.2. Attribute Choices List + + This list specifies the attributes of the SPI. The attribute formats + are specified in the "Basic Attributes". + + The list is composed of one or two sections: Authentication- + Attributes, and/or Encapsulation-Attributes. + + When sending from the SPI User to the SPI Owner, the attributes are + processed in the order listed. For example, + + "ESP-Attributes", + "Deflate" (Compression), + "XOR" (Encryption), + "DES-CBC" (Encryption), + "XOR" (Encryption), + "AH-Attributes", + "AH-Sequence", + "MD5-IPMAC" (Authentication), + + would result in ESP with compression and triple encryption (inside), + and then AH authentication with sequence numbers (outside) of the ESP + payload. + + The SPI Owner will naturally process the datagram in the reverse + order. + + This ordering also affects the order of key generation. Both SPI + + + +Karn & Simpson Experimental [Page 33] + +RFC 2522 Photuris Protocol March 1999 + + + Owner and SPI User generate the keys in the order listed. + + Implementation Notes: + + When choices are made from the list of Offered-Attributes, it is + not required that any Security Association include every kind of + offered attribute in any single SPI, or that a separate SPI be + created for every offered attribute. + + Some kinds of attributes may be included more than once in a + single SPI. The set of allowable combinations of attributes are + dependent on implementation and operational policy. Such + considerations are outside the scope of this document. + + The list may be divided into additional sections. This can occur + only when both parties recognize the affected attributes. + + The authentication, compression, encryption and identification + mechanisms chosen, as well as the encapsulation modes (if any), + need not be the same in both directions. + + +5.3. Shared-Secret + + A shared-secret is used in a number of calculations. Regardless of + the internal representation of the shared-secret, when used in + calculations it is in the same form as the Value part of a Variable + Precision Integer: + + - most significant byte first. + - bits used are right justified within byte boundaries. + - any unused bits are in the most significant byte. + - unused bits are zero filled. + + The shared-secret does not include a Size field. + + +5.4. Identity Verification + + These messages are authenticated using the Identity-Choice. The + Verification value is calculated prior to masking (and optional + encryption), and verified after unmasking (and optional decryption). + + The Identity-Choice authentication function is supplied with two + input values: + + - the sender (SPI Owner) verification-key, + - the data to be verified (as a concatenated sequence of bytes). + + + +Karn & Simpson Experimental [Page 34] + +RFC 2522 Photuris Protocol March 1999 + + + The resulting output value is stored in the Verification field. + + The Identity-Choice verification data consists of the following + concatenated values: + + + the Initiator Cookie, + + the Responder Cookie, + + the Message, LifeTime and SPI fields, + + the Identity-Choice and Identification, + + the SPI User Identity Verification (response only), + + the Attribute-Choices following the Verification field, + + the Padding, + + the SPI Owner TBV, + + the SPI Owner Exchange-Value, + + the SPI Owner Offered-Attributes, + + the SPI User TBV, + + the SPI User Exchange-Value, + + the SPI User Offered-Attributes, + + the Responder Offered-Schemes. + + The TBV (Three Byte Value) consists of the Counter and Scheme-Choice + fields from the Value_Request, or the Reserved field from the + Value_Response, immediately preceding the associated Exchange-Value. + + Note that the order of the Exchange-Value and Offered-Attributes + fields is different in each direction, and the Identification and SPI + fields are also likely to be different in each direction. Note also + that the SPI User Identity Verification (from the Identity_Request) + is present only in the Identity_Response. + + If the verification fails, the users are notified, and a + Verification_Failure message is sent, without adding any SPI. On + success, normal operation begins with the authentication and/or + encryption of user datagrams. + + Implementation Notes: + + This is distinct from any authentication method specified for the + SPI. + + The exact details of the Identification and verification-key + included in the Verification calculation are dependent on the + Identity-Choice, as described in the "Basic Attributes". + + Each party may wish to keep their own trusted databases, such as + the Pretty Good Privacy (PGP) web of trust, and accept only those + identities found there. Failure to find the Identification in + either an internal or external database results in the same + + + +Karn & Simpson Experimental [Page 35] + +RFC 2522 Photuris Protocol March 1999 + + + Verification_Failure message as failure of the verification + computation. + + The Exchange-Value data includes both the Size and Value fields. + The Offered-Attributes and Attribute-Choices data includes the + Attribute, Length and Value fields. + + +5.5. Privacy-Key Computation + + Identification Exchange messages are masked using the Privacy-Method + indicated by the current Scheme-Choice. Masking begins with the next + field after the SPI, and continues to the end of the data indicated + by the UDP Length, including the Padding. + + The Scheme-Choice specified Key-Generation-Function is used to create + a special privacy-key for each message. This function is calculated + over the following concatenated values: + + + the SPI Owner Exchange-Value, + + the SPI User Exchange-Value, + + the Initiator Cookie, + + the Responder Cookie, + + the Message, LifeTime and SPI (or Reserved) fields, + + the computed shared-secret. + + Since the order of the Exchange-Value fields is different in each + direction, and the Message, LifeTime and SPI fields are also + different in each direction, the resulting privacy-key will usually + be different in each direction. + + When a larger number of keying-bits are needed than are available + from one iteration of the specified Key-Generation-Function, more + keying-bits are generated by duplicating the trailing shared-secret, + and recalculating the function. That is, the first iteration will + have one trailing copy of the shared-secret, the second iteration + will have two trailing copies of the shared-secret, and so forth. + + Implementation Notes: + + This is distinct from any encryption method specified for the SPI. + + The length of the Padding, and other details, are dependent on the + Privacy-Method. See the "Basic Privacy-Method" list for details. + + To avoid keeping the Exchange-Values in memory after the initial + verification, it is often possible to pre-compute the function + over the initial bytes of the concatenated data values for each + + + +Karn & Simpson Experimental [Page 36] + +RFC 2522 Photuris Protocol March 1999 + + + direction, and append the trailing copies of the shared-secret. + + The Exchange-Value data includes both the Size and Value fields. + + +5.6. Session-Key Computation + + Each SPI has one or more session-keys. These keys are generated + based on the attributes of the SPI. See the "Basic Attributes" for + details. + + The Scheme-Choice specified Key-Generation-Function is used to create + the SPI session-key for that particular attribute. This function is + calculated over the following concatenated values: + + + the Initiator Cookie, + + the Responder Cookie, + + the SPI Owner generation-key, + + the SPI User generation-key, + + the message Verification field, + + the computed shared-secret. + + Since the order of the generation-keys is different in each + direction, and the Verification field is also likely to be different + in each direction, the resulting session-key will usually be + different in each direction. + + When a larger number of keying-bits are needed than are available + from one iteration of the specified Key-Generation-Function, more + keying-bits are generated by duplicating the trailing shared-secret, + and recalculating the function. That is, the first iteration will + have one trailing copy of the shared-secret, the second iteration + will have two trailing copies of the shared-secret, and so forth. + + Implementation Notes: + + This is distinct from any privacy-key generated for the Photuris + exchange. Different initialization data is used, and iterations + are maintained separately. + + The exact details of the Verification field and generation-keys + that are included in the session-key calculation are dependent on + the Identity-Choices, as described in the "Basic Attributes". + + To avoid keeping the generation-keys in memory after the initial + verification, it is often possible to pre-compute the function + over the initial bytes of the concatenated data values for each + direction, and append the trailing copies of the shared-secret. + + + +Karn & Simpson Experimental [Page 37] + +RFC 2522 Photuris Protocol March 1999 + + + When both authentication and encryption attributes are used for + the same SPI, there may be multiple session-keys associated with + the same SPI. These session-keys are generated in the order of + the Attribute-Choices list. + + +6. SPI Messages + + SPI User SPI Owner + ======== ========= + SPI_Needed -> + list SPI attribute(s) + make validity key + authenticate + make privacy key(s) + mask/encrypt message + <- SPI_Update + make SPI + pick SPI attribute(s) + make SPI session-key(s) + make validity key + authenticate + make privacy key(s) + mask/encrypt message + + The exchange of messages is not related to the Initiator and + Responder. Instead, either party may send one of these messages at + any time. The messages are easily distinguished by the parties. + + +6.0.1. Send SPI_Needed + + At any time after completion of the Identification Exchange, either + party can send SPI_Needed. This message is sent when a prospective + SPI User needs particular attributes for a datagram (such as + confidentiality), and no current SPI has those attributes. + + The prospective SPI User selects from the intersection of attributes + that both parties have previously offered, calculates the + Verification, and masks the message using the Privacy-Method + indicated by the current Scheme-Choice. + + + + + + + + + + +Karn & Simpson Experimental [Page 38] + +RFC 2522 Photuris Protocol March 1999 + + +6.0.2. Receive SPI_Needed + + The potential SPI Owner validates the pair of Cookies, the Padding, + the Verification, and the Attributes-Needed. + + - When an invalid/expired cookie is detected, a Bad_Cookie message + is sent. + + - When too many SPI values are already in use for this particular + peer, or some other resource limit is reached, a Resource_Limit + message is sent. + + - After unmasking, when invalid Padding is detected, the variable + length Attributes-Needed do not match the UDP Length, or an + attribute was not in the Offered-Attributes, the message is + silently discarded. + + - When the message verification fails, a Verification_Failure + message is sent. + + - Whenever such a problem is detected, the SPI is not established; + the implementation SHOULD log the occurance, and notify an + operator as appropriate. + + When the message is valid, the party SHOULD send SPI_Update with the + necessary attributes. + + If an existing SPI has those attributes, that SPI is returned in the + SPI_Update with the remaining SPILT. + + +6.0.3. Send SPI_Update + + At any time after completion of the Identification Exchange, either + party can send SPI_Update. This message has effect in only one + direction, from the SPI Owner to the SPI User. + + The SPI Owner chooses the SPI and SPILT, a set of Attributes for the + SPI, calculates the Verification, and masks the message using the + Privacy-Method indicated by the current Scheme-Choice. + + +6.0.4. Receive SPI_Update + + The prospective SPI User validates the pair of Cookies, the Padding, + the Verification, and the Attributes-Needed. + + - When an invalid/expired cookie is detected, a Bad_Cookie message + + + +Karn & Simpson Experimental [Page 39] + +RFC 2522 Photuris Protocol March 1999 + + + is sent. + + - After unmasking, when invalid Padding is detected, the variable + length Attribute-Choices do not match the UDP Length, an attribute + was not in the Offered-Attributes, or the message modifies an + existing SPI, the message is silently discarded. + + - When the message verification fails, a Verification_Failure + message is sent. + + - Whenever such a problem is detected, the SPI is not established; + the implementation SHOULD log the occurance, and notify an + operator as appropriate. + + When the message is valid, further actions are dependent on the value + of the LifeTime field, as described later. + + +6.0.5. Automated SPI_Updates + + Each SPI requires replacement under several circumstances: + + - the volume of data processed (inhibiting probability + cryptanalysis), + + - exhaustion of available anti-replay Sequence Numbers, + + - and expiration of the LifeTime. + + In general, a determination is made upon receipt of a datagram. If + the transform specific processing finds that refreshment is needed, + an automated SPI_Update is triggered. + + In addition, automated SPI_Updates allow rapid SPI refreshment for + high bandwidth applications in a high delay environment. The update + messages flow in the opposite direction from the primary traffic, + conserving bandwidth and avoiding service interruption. + + When creating each SPI, the implementation MAY optionally set an + Update TimeOut (UTO); by default, to half the value of the LifeTime + (SPILT/2). This time is highly dynamic, and adjustable to provide an + automated SPI_Update long before transform specific processing. If + no new Photuris exchange occurs within the time limit, and the + current exchange state has not expired, an automated SPI_Update is + sent. + + + + + + +Karn & Simpson Experimental [Page 40] + +RFC 2522 Photuris Protocol March 1999 + + +6.1. SPI_Needed + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Initiator-Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Responder-Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message | Reserved-LT | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved-SPI | + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + | | + ~ Verification ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes-Needed ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... Padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Initiator-Cookie 16 bytes. Copied from the Value_Request. + + Responder-Cookie 16 bytes. Copied from the Value_Request. + + Message 8 + + Reserved-LT 3 bytes. For future use; MUST be filled with a + random non-zero value when transmitted, and MUST be + ignored when received. + + Reserved-SPI 4 bytes. For future use; MUST be set to zero when + transmitted, and MUST be ignored when received. + + Verification Variable Precision Integer, or other format + indicated by the current Scheme-Choice. The + calculation of the value is described in "Validity + Verification". + + The field may be any integral number of bytes in + length. It does not require any particular + alignment. The 32-bit alignment shown is for + convenience in the illustration. + + + + +Karn & Simpson Experimental [Page 41] + +RFC 2522 Photuris Protocol March 1999 + + + Attributes-Needed + 4 or more bytes. A list of two or more attributes, + selected from the list of Offered-Attributes + supported by the peer. + + The contents and usage of this list are as + previously described in "Attribute Choices List". + The end of the list is indicated by the UDP Length + after removing the Padding (UDP Length - last + Padding value). + + Padding 8 or more bytes. The message is padded in the same + fashion specified for Identification Exchange + messages. + + The portion of the message after the SPI field is masked using the + Privacy-Method indicated by the current Scheme-Choice. + + The fields following the SPI are opaque. That is, the values are set + prior to masking (and optional encryption), and examined only after + unmasking (and optional decryption). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Karn & Simpson Experimental [Page 42] + +RFC 2522 Photuris Protocol March 1999 + + +6.2. SPI_Update + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Initiator-Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Responder-Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message | LifeTime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Security-Parameters-Index | + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + | | + ~ Verification ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute-Choices ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... Padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Initiator-Cookie 16 bytes. Copied from the Value_Request. + + Responder-Cookie 16 bytes. Copied from the Value_Request. + + Message 9 + + LifeTime 3 bytes. The number of seconds remaining before the + indicated SPI expires. The value zero indicates + deletion of the indicated SPI. + + Security-Parameters-Index (SPI) + 4 bytes. The SPI to be used for incoming + communications. + + This may be a new SPI value (for creation), or an + existing SPI value (for deletion). The value zero + indicates special processing. + + Verification Variable Precision Integer, or other format + indicated by the current Scheme-Choice. The + calculation of the value is described in "Validity + Verification". + + + + +Karn & Simpson Experimental [Page 43] + +RFC 2522 Photuris Protocol March 1999 + + + The field may be any integral number of bytes in + length. It does not require any particular + alignment. The 32-bit alignment shown is for + convenience in the illustration. + + Attribute-Choices + 0 or more bytes. When the SPI and SPILT are non- + zero, a list of attributes selected from the list of + Offered-Attributes supported by the peer. + + The contents and usage of this list are as + previously described in "Attribute Choices List". + The end of the list is indicated by the UDP Length + after removing the Padding (UDP Length - last + Padding value). + + Padding 8 or more bytes. The message is padded in the same + fashion specified for Identification Exchange + messages. + + The portion of the message after the SPI field is masked using the + Privacy-Method indicated by the current Scheme-Choice. + + The fields following the SPI are opaque. That is, the values are set + prior to masking (and optional encryption), and examined only after + unmasking (and optional decryption). + + +6.2.1. Creation + + When the LifeTime is non-zero, and the SPI is also non-zero, the + SPI_Update can be used to create a new SPI. When the SPI is zero, + the SPI_Update is silently discarded. + + The new session-keys are calculated in the same fashion as the + Identity_Messages. Since the SPI value is always different than any + previous SPI during the Exchange LifeTime of the shared-secret, the + resulting session-keys will necessarily be different from all others + used in the same direction. + + No retransmission timer is necessary. Success is indicated by the + peer use of the new SPI. + + Should all creation attempts fail, eventually the peer will find that + all existing SPIs have expired, and will begin the Photuris exchange + again by sending a new Cookie_Request. When appropriate, this + Cookie_Request MAY include a Responder-Cookie to retain previous + party pairings. + + + +Karn & Simpson Experimental [Page 44] + +RFC 2522 Photuris Protocol March 1999 + + +6.2.2. Deletion + + When the LifeTime is zero, the SPI_Update can be used to delete a + single existing SPI. When the SPI is also zero, the SPI_Update will + delete all existing SPIs related to this Security Association, and + mark the Photuris exchange state as expired. This is especially + useful when the application that needed them terminates. + + No retransmission timer is necessary. This message is advisory, to + reduce the number of ICMP Security Failures messages. + + Should any deletion attempts fail, the peer will learn that the + deleted SPIs are invalid through the normal ICMP Security Failures + messages, and will initiate a Photuris exchange by sending a new + Cookie_Request. + + +6.2.3. Modification + + The SPI_Update cannot be used to modify existing SPIs, such as + lengthen an existing SPI LifeTime, resurrect an expired SPI, or + add/remove an Attribute-Choice. + + On receipt, such an otherwise valid message is silently discarded. + + +6.3. Validity Verification + + These messages are authenticated using the Validity-Method indicated + by the current Scheme-Choice. The Verification value is calculated + prior to masking (and optional encryption), and verified after + unmasking (and optional decryption). + + The Validity-Method authentication function is supplied with two + input values: + + - the sender (SPI Owner) verification-key, + - the data to be verified (as a concatenated sequence of bytes). + + The resulting output value is stored in the Verification field. + + The Validity-Method verification data consists of the following + concatenated values: + + + + + + + + +Karn & Simpson Experimental [Page 45] + +RFC 2522 Photuris Protocol March 1999 + + + + + the Initiator Cookie, + + the Responder Cookie, + + the Message, LifeTime and SPI (or Reserved) fields, + + the SPI Owner Identity Verification, + + the SPI User Identity Verification, + + the Attribute-Choices following the Verification field, + + the Padding. + + Note that the order of the Identity Verification fields (from the + Identity_Messages) is different in each direction, and the Message, + LifeTime and SPI fields are also likely to be different in each + direction. + + If the verification fails, the users are notified, and a + Verification_Failure message is sent, without adding or deleting any + SPIs. On success, normal operation begins with the authentication + and/or encryption of user datagrams. + + Implementation Notes: + + This is distinct from any authentication method specified for the + SPI. + + The Identity Verification data includes both the Size and Value + fields. The Attribute-Choices data includes the Attribute, Length + and Value fields. + + +7. Error Messages + + These messages are issued in response to Photuris state loss or other + problems. A message has effect in only one direction. No + retransmission timer is necessary. + + These messages are not masked. + + The receiver checks the Cookies for validity. Special care MUST be + taken that the Cookie pair in the Error Message actually match a pair + currently in use, and that the protocol is currently in a state where + such an Error Message might be expected. Otherwise, these messages + could provide an opportunity for a denial of service attack. Invalid + messages are silently discarded. + + + + + + + + +Karn & Simpson Experimental [Page 46] + +RFC 2522 Photuris Protocol March 1999 + + +7.1. Bad_Cookie + + For the format of the 33 byte message, see "Header Format". There + are no additional fields. + + Initiator-Cookie 16 bytes. Copied from the offending message. + + Responder-Cookie 16 bytes. Copied from the offending message. + + Message 10 + + This error message is sent when a Value_Request, Identity_Request, + SPI_Needed, or SPI_Update is received, and the receiver specific + Cookie is invalid or the associated exchange state has expired. + + During the Photuris exchange, when this error message is received, it + has no immediate effect on the operation of the protocol phases. + Later, when Retransmissions have been exceeded, and this error + message has been received, the Initiator SHOULD begin the Photuris + exchange again by sending a new Cookie_Request with the Responder- + Cookie and Counter updated appropriately. + + When this error message is received in response to SPI_Needed, the + exchange state SHOULD NOT be marked as expired, but the party SHOULD + initiate a Photuris exchange by sending a new Cookie_Request. + + When this error message is received in response to SPI_Update, the + exchange state SHOULD NOT be marked as expired, and no further action + is taken. A new exchange will be initiated later when needed by the + peer to send authenticated and/or encrypted data. + + Existing SPIs are not deleted. They expire normally, and are purged + sometime later. + + +7.2. Resource_Limit + + For the format of the 34 byte message, see "Cookie_Request". There + are no additional fields. + + Initiator-Cookie 16 bytes. Copied from the offending message. + + Responder-Cookie 16 bytes. Copied from the offending message. + + Special processing is applied to a Cookie_Request. + When the offending message Responder-Cookie and + Counter were both zero, and an existing exchange has + not yet been purged, this field is replaced with the + + + +Karn & Simpson Experimental [Page 47] + +RFC 2522 Photuris Protocol March 1999 + + + Responder-Cookie from the existing exchange. + + Message 11 + + Counter 1 byte. Copied from the offending message. + + When zero, the Responder-Cookie indicates the + Initiator of a previous exchange, or no previous + exchange is specified. + + When non-zero, the Responder-Cookie indicates the + Responder to a previous exchange. This value is set + to the Counter from the corresponding + Cookie_Response. + + This error message is sent when a Cookie_Request, Value_Request or + SPI_Needed is received, and too many SPI values are already in use + for that peer, or some other Photuris resource is unavailable. + + During the Photuris exchange, when this error message is received in + response to a Cookie_Request or Value_Request, the implementation + SHOULD double the retransmission timeout (as usual) for sending + another Cookie_Request or Value_Request. Otherwise, it has no + immediate effect on the operation of the protocol phases. Later, + when Retransmissions have been exceeded, and this error message has + been received, the Initiator SHOULD begin the Photuris exchange again + by sending a new Cookie_Request with the Responder-Cookie and Counter + updated appropriately. + + When this error message is received in response to SPI_Needed, the + implementation SHOULD NOT send another SPI_Needed until one of the + existing SPIs associated with this exchange is deleted or has + expired. + + +7.3. Verification_Failure + + For the format of the 33 byte message, see "Header Format". There + are no additional fields. + + Initiator-Cookie 16 bytes. Copied from the offending message. + + Responder-Cookie 16 bytes. Copied from the offending message. + + Message 12 + + This error message is sent when an Identity_Message, SPI_Needed or + SPI_Update is received, and verification fails. + + + +Karn & Simpson Experimental [Page 48] + +RFC 2522 Photuris Protocol March 1999 + + + When this error message is received, the implementation SHOULD log + the occurance, and notify an operator as appropriate. However, + receipt has no effect on the operation of the protocol. + + +7.4. Message_Reject + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Initiator-Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Responder-Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message | Bad-Message | Offset | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Initiator-Cookie 16 bytes. Copied from the offending message. + + Responder-Cookie 16 bytes. Copied from the offending message. + + Message 13 + + Bad-Message 1 byte. Indicates the Message number of the + offending message. + + Offset 2 bytes. The number of bytes from the beginning of + the offending message where the unrecognized field + starts. The minimum value is 32. + + This error message is sent when an optional Message type is received + that is not supported, or an optional format of a supported Message + is not recognized. + + When this error message is received, the implementation SHOULD log + the occurance, and notify an operator as appropriate. However, + receipt has no effect on the operation of the protocol. + + + + + + + + + + + +Karn & Simpson Experimental [Page 49] + +RFC 2522 Photuris Protocol March 1999 + + +8. Public Value Exchanges + + Photuris is based in principle on public-key cryptography, + specifically Diffie-Hellman key exchange. Exchange of public D-H + Exchange-Values based on private-secret values results in a mutual + shared-secret between the parties. This shared-secret can be used on + its own, or to generate a series of session-keys for authentication + and encryption of subsequent traffic. + + This document assumes familiarity with the Diffie-Hellman public-key + algorithm. A good description can be found in [Schneier95]. + + +8.1. Modular Exponentiation Groups + + The original Diffie-Hellman technique [DH76] specified modular + exponentiation. A public-value is generated using a generator (g), + raised to a private-secret exponent (x), modulo a prime (p): + + (g**x) mod p. + + When these public-values are exchanged between parties, the parties + can calculate a shared-secret value between themselves: + + (g**xy) mod p. + + The generator (g) and modulus (p) are established by the Scheme- + Choice (see the "Basic Exchange-Schemes" for details). They are + offered in the Cookie_Response, and one pair is chosen in the + Value_Request. + + The private exponents (x) and (y) are kept secret by the parties. + Only the public-value result of the modular exponentiation with (x) + or (y) is sent as the Initiator and Responder Exchange-Value. + + These public-values are represented in single Variable Precision + Integers. The Size of these Exchange-Values will match the Size of + the modulus (p). + + +8.2. Moduli Selection + + Each implementation proposes one or more moduli in its Offered- + Schemes. Every implementation MUST support up to 1024-bit moduli. + + For any particular Photuris node, these moduli need not change for + significant periods of time; likely days or weeks. A background + process can periodically generate new moduli. + + + +Karn & Simpson Experimental [Page 50] + +RFC 2522 Photuris Protocol March 1999 + + + For 512-bit moduli, current estimates would provide 64 + (pessimistic) bit-equivalents of cryptographic strength. + + For 1024-bit moduli, current estimates would range from 80 + (pessimistic) through 98 (optimistic) bit-equivalents of + cryptographic strength. + + These estimates are used when choosing moduli that are appropriate + for the desired Security Parameter attributes. + + +8.2.1. Bootstrap Moduli + + Each implementation is likely to use a fixed modulus during its + bootstrap, until it can generate another modulus in the background. + As the bootstrap modulus will be widely distributed, and reused + whenever the machine reinitializes, it SHOULD be a "safe" prime (p = + 2q+1) to provide the greatest long-term protection. + + Implementors are encouraged to generate their own bootstrap moduli, + and to change bootstrap moduli in successive implementation releases. + + +8.2.2. Learning Moduli + + As Photuris exchanges are initiated, new moduli will be learned from + the Responder Offered-Schemes. The Initiator MAY cache these moduli + for its own use. + + Before offering any learned modulus, the implementation MUST perform + at least one iteration of probable primality verification. In this + fashion, many processors will perform verification in parallel as + moduli are passed around. + + When primality verification failures are found, the failed moduli + SHOULD be retained for some (implementation dependent) period of + time, to avoid re-learning and re-testing after subsequent exchanges. + + +8.3. Generator Selection + + The generator (g) should be chosen such that the private-secret + exponents will generate all possible public-values, evenly + distributed throughout the range of the modulus (p), without cycling + through a smaller subset. Such a generator is called a "primitive + root" (which is trivial to find when p is "safe"). + + Only one generator (2) is required to be supported. + + + +Karn & Simpson Experimental [Page 51] + +RFC 2522 Photuris Protocol March 1999 + + + Implementation Notes: + + One useful technique is to select the generator, and then limit + the modulus selection sieve to primes with that generator: + + 2 when p (mod 24) = 11. + 3 when p (mod 12) = 5. + 5 when p (mod 10) = 3 or 7. + + The required generator (2) improves efficiency in multiplication + performance. It is usable even when it is not a primitive root, + as it still covers half of the space of possible residues. + + +8.4. Exponent Selection + + Each implementation generates a separate random private-secret + exponent for each different modulus. Then, a D-H Exchange-Value is + calculated for the given modulus, generator, and exponent. + + This specification recommends that the exponent length be at least + twice the desired cryptographic strength of the longest session-key + needed by the strongest offered-attribute. + + Based on the estimates in "Moduli Selection" (above): + + For 512-bit moduli, exponent lengths of 128 bits (or more) are + recommended. + + For 1024-bit moduli, exponent lengths of 160 to 256 bits (or more) + are recommended. + + Although the same exponent and Exchange-Value may be used with + several parties whenever the same modulus and generator are used, the + exponent SHOULD be changed at random intervals. A background process + can periodically destroy the old values, generate a new random + private-secret exponent, and recalculate the Exchange-Value. + + Implementation Notes: + + The size of the exponent is entirely implementation dependent, is + unknown to the other party, and can be easily changed. + + Since these operations involve several time-consuming modular + exponentiations, moving them to the "background" substantially + improves the apparent execution speed of the Photuris protocol. + It also reduces CPU loading sufficiently to allow a single + public/private key-pair to be used in several closely spaced + + + +Karn & Simpson Experimental [Page 52] + +RFC 2522 Photuris Protocol March 1999 + + + Photuris executions, when creating Security Associations with + several different nodes over a short period of time. + + Other pre-computation suggestions are described in [BGMW93, LL94, + Rooij94]. + + +8.5. Defective Exchange Values + + Some exponents do not qualify as secret. The exponent 0 will + generate the Exchange-Value 1, and the exponent 1 will generate the + Exchange-Value g. Small exponents will be easily visible and SHOULD + be avoided where: + + g**x < p. + + Depending on the structure of the moduli, certain exponents can be + used for sub-group confinement attacks. For "safe" primes (p = + 2q+1), these exponents are p-1 and (p-1)/2, which will generate the + Exchange-Values 1 and p-1 respectively. + + When an implementation chooses a random exponent, the resulting + Exchange-Value is examined. If the Exchange-Value is represented in + less than half the number of significant bits in the modulus, then a + new random exponent MUST be chosen. + + For 512-bit moduli, Exchange-Values of 2**256 or greater are + required. + + For 1024-bit moduli, Exchange-Values of 2**512 or greater are + required. + + In addition, if the resulting Exchange-Value is p-1, then a new + random exponent MUST be chosen. + + Upon receipt of an Exchange-Value that fails to meet the + requirements, the Value Exchange message is silently discarded. + + Implementation Notes: + + Avoidance of small exponents can be assured by setting at least + one bit in the most significant half of the exponent. + + + + + + + + + +Karn & Simpson Experimental [Page 53] + +RFC 2522 Photuris Protocol March 1999 + + +9. Basic Exchange-Schemes + + Initial values are assigned as follows: + + (0) Reserved. + + (1) Reserved. + + (2) Implementation Required. Any modulus (p) with a recommended + generator (g) of 2. When the Exchange-Scheme Size is non-zero, + the modulus is contained 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 combination of features requires a modulus with at least + 64-bits of cryptographic strength. + + (3) Exchange-Schemes 3 to 255 are intended for future well-known + published schemes. + + (256) Exchange-Schemes 256 to 32767 are intended for vendor-specific + unpublished schemes. Implementors wishing a number MUST + request the number from the authors. + + (32768) + Exchange-Schemes 32768 to 65535 are available for cooperating + parties to indicate private schemes, regardless of vendor + implementation. These numbers are not reserved, and are + subject to duplication. Other criteria, such as the IP Source + and Destination of the Cookie_Request, are used to + differentiate the particular Exchange-Schemes available. + + + + + + + + + + + + + + + +Karn & Simpson Experimental [Page 54] + +RFC 2522 Photuris Protocol March 1999 + + +10. Basic Key-Generation-Function +10.1. MD5 Hash + + MD5 [RFC-1321] is used as a pseudo-random-function for generating the + key(s). The key(s) begin with the most significant bits of the hash. + MD5 is iterated as needed to generate the requisite length of key + material. + + When an individual key does not use all 128-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 will begin with a new hash iteration. + + +11. Basic Privacy-Method +11.1. Simple Masking + + As described in "Privacy-Key Computation", sufficient privacy-key + material is generated to match the message length, beginning with the + next field after the SPI, and including the Padding. The message is + masked by XOR with the privacy-key. + + +12. Basic Validity-Method +12.1. MD5-IPMAC Check + + As described in "Validity Verification", the Verification field value + is the MD5 [RFC-1321] hash over the concatenation of + + MD5( key, keyfill, data, datafill, key, md5fill ) + + where the key is the computed verification-key. + + The keyfill and datafill use the same pad-with-length technique + defined for md5fill. This padding and length is implicit, and does + not appear in the datagram. + + The resulting Verification field is a 128-bit Variable Precision + Integer (18 bytes including Size). When used in calculations, the + Verification data includes both the Size and Value fields. + + + + + + + + + + + +Karn & Simpson Experimental [Page 55] + +RFC 2522 Photuris Protocol March 1999 + + +13. Basic Attributes + + Implementors wishing a number MUST request the number from the + authors. Initial values are assigned as follows: + + Use Type + - 0* padding + - 1* AH-Attributes + - 2+ ESP-Attributes + AEI 5* MD5-IPMAC + AEIX 255+ Organizational + + A AH Attribute-Choice + E ESP Attribute-Choice + I Identity-Choice + X dependent on list location + + feature must be recognized even when not supported + * feature must be supported (mandatory) + + Other attributes are specified in companion documents. + + +13.1. Padding + + +-+-+-+-+-+-+-+-+ + | Attribute | + +-+-+-+-+-+-+-+-+ + + + Attribute 0 + + Each attribute may have value fields that are multiple bytes. To + facilitate processing efficiency, these fields are aligned on + integral modulo 8 byte (64-bit) boundaries. + + Padding is accomplished by insertion of 1 to 7 Attribute 0 padding + bytes before the attribute that needs alignment. + + No padding is used after the final attribute in a list. + + + + + + + + + + + + +Karn & Simpson Experimental [Page 56] + +RFC 2522 Photuris Protocol March 1999 + + +13.2. AH-Attributes + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Attribute 1 + + Length 0 + + When a list of Attributes is specified, this Attribute begins the + section of the list which applies to the Authentication Header (AH). + + +13.3. ESP-Attributes + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute | Length | PayloadType | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Attribute 2 + + Length 1 + + PayloadType 1 byte. Indicates the contents of the ESP Transform + Data field, using the IP Next Header (Protocol) + value. Up-to-date values of the IP Next Header + (Protocol) are specified in the most recent + "Assigned Numbers" [RFC-1700]. + + For example, when encrypting an entire IP datagram, + this field will contain the value 4, indicating IP- + in-IP encapsulation. + + When a list of Attributes is specified, this Attribute begins the + section of the list which applies to the Encapsulating Security + Payload (ESP). + + When listed as an Offered-Attribute, the PayloadType is set to 255. + + When selected as an Attribute-Choice, the PayloadType is set to the + actual value to be used. + + + + + + + +Karn & Simpson Experimental [Page 57] + +RFC 2522 Photuris Protocol March 1999 + + +13.4. MD5-IPMAC + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Attribute 5 + + Length 0 + + + +13.4.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 "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 64-bits of cryptographic strength. + + As described in "Identity Verification", the Verification field value + is the MD5 [RFC-1321] hash over the concatenation of: + + MD5( key, keyfill, data, datafill, key, md5fill ) + + where the key is the computed verification-key. + + The keyfill and datafill use the same pad-with-length technique + defined for md5fill. This padding and length is implicit, and does + not appear in the datagram. + + The resulting Verification field is a 128-bit Variable Precision + Integer (18 bytes including Size). When used in calculations, the + Verification data includes both the Size and Value fields. + + For both "Identity Verification" and "Validity Verification", the + verification-key is the MD5 [RFC-1321] hash of the following + concatenated values: + + + + +Karn & Simpson Experimental [Page 58] + +RFC 2522 Photuris Protocol March 1999 + + + + + the symmetric secret-key, + + the computed shared-secret. + + For "Session-Key Computation", the symmetric secret-key is used + directly as the generation-key. + + Regardless of the internal representation of the symmetric secret- + key, when used in calculations it is in the same form as the Value + part of a Variable Precision Integer: + + - most significant byte first. + - bits used are right justified within byte boundaries. + - any unused bits are in the most significant byte. + - unused bits are zero filled. + + The symmetric secret-key does not include a Size field. + + +13.4.2. Authentication + + May be selected as an AH or ESP Attribute-Choice, pursuant to [RFC- + 1828] et sequitur. The selected Exchange-Scheme SHOULD provide at + least 64-bits of cryptographic strength. + + As described in "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-1828]. + + The form of the authenticated message is: + + MD5( key, keyfill, datagram, datafill, key, md5fill ) + + where the key is the SPI session-key. + + The additional datafill protects against the (impractical) attack + described in [PO96]. The keyfill and datafill use the same pad- + with-length technique defined for md5fill. This padding and + length is implicit, and does not appear in the datagram. + + + + + + + +Karn & Simpson Experimental [Page 59] + +RFC 2522 Photuris Protocol March 1999 + + +13.5. Organizational + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute | Length | OUI + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... | Kind | Value(s) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Attribute 255 + + Length >= 4 + + When the Length is four, no Value(s) field is + present. + + OUI 3 bytes. The vendor's Organizationally Unique + Identifier, assigned by IEEE 802 or IANA (see [RFC- + 1700] for contact details). The bits within the + byte are in canonical order, and the most + significant byte is transmitted first. + + Kind 1 byte. Indicates a sub-type for the OUI. There is + no standardization for this field. Each OUI + implements its own values. + + Value(s) 0 or more bytes. The details are implementation + specific. + + Some implementors might not need nor want to publish their + proprietary algorithms and attributes. This OUI mechanism is + available to specify these without encumbering the authors with + proprietary number requests. + + + + + + + + + + + + + + + + + + +Karn & Simpson Experimental [Page 60] + +RFC 2522 Photuris Protocol March 1999 + + +A. Automaton + + An example automaton is provided to illustrate the operation of the + protocol. It is incomplete and non-deterministic; many of the + Good/Bad semantic decisions are policy-based or too difficult to + represent in tabular form. Where conflicts appear between this + example and the text, the text takes precedence. + + The finite-state automaton is defined by events, actions and state + transitions. Events include reception of external commands such as + expiration of a timer, and reception of datagrams from a peer. + Actions include the starting of timers and transmission of datagrams + to the peer. + + Events + + DU13 = Communication Administratively Prohibited + SF0 = Bad SPI + SF4 = Need Authentication + SF5 = Need Authorization + WC = Want Confidentiality + + RCQ+ = Receive Cookie_Request (Good) + RCQ- = Receive Cookie_Request (Bad) + RCR+ = Receive Cookie_Response (Good) + RCR- = Receive Cookie_Response (Bad) + + RVQ+ = Receive Value_Request (Good) + RVQ- = Receive Value_Request (Bad) + RVR+ = Receive Value_Response (Good) + RVR- = Receive Value_Response (Bad) + + RIQ+ = Receive Identity_Request (Good) + RIQ- = Receive Identity_Request (Bad) + RIR+ = Receive Identity_Response (Good) + RIR- = Receive Identity_Response (Bad) + + RUN+ = Receive SPI_Needed (Good) + RUN- = Receive SPI_Needed (Bad) + RUM+ = Receive SPI_Update (Good) + RUM- = Receive SPI_Update (Bad) + + RBC = Receive Bad Cookie + RRL = Receive Resource Limit + RVF = Receive Verification Failure + RMR = Receive Message Reject + + TO+ = Timeout with counter > 0 + + + +Karn & Simpson Experimental [Page 61] + +RFC 2522 Photuris Protocol March 1999 + + + TO- = Timeout with counter expired + UTO = Update TimeOut + XTO = Exchange TimeOut + + + Actions + + scq = Send Cookie_Request + scr = Send Cookie_Response + + svq = Send Value_Request + svr = Send Value_Response + + siq = Send Identity_Request + sir = Send Identity_Response + + sum = Send SPI_Update + + se* = Send error message (see text) + sbc = Send Bad Cookie + srl = Send Resource Limit + svf = Send Verification Failure + + brto = Backoff Retransmission TimeOut + buto = Backoff Update TimeOut + rto = Set Retransmission TimeOut + uto = Set Update TimeOut + xto = Set Exchange TimeOut + + log = log operator message + + +A.1. State Transition Table + + States are indicated horizontally, and events are read vertically. + State transitions and actions are represented in the form + action/new-state. Multiple actions are separated by commas, and may + continue on succeeding lines as space requires; multiple actions may + be implemented in any convenient order. The state may be followed by + a letter, which indicates an explanatory footnote. The dash ('-') + indicates an illegal transition. + + + + + + + + + + +Karn & Simpson Experimental [Page 62] + +RFC 2522 Photuris Protocol March 1999 + + + + Initiator + + | 0 1 2 3 4 + | Initial Cookie CookieBad Value ValueBad + ------+-------------------------------------------------- + DU13 |rto,scq/1 rto,scq/1 rto,scq/1 3 4 + SF0 |rto,scq/1 1 2 3 4 + SF4 |rto,scq/1 1 2 3 4 + SF5 |rto,scq/1 1 2 3 4 + WC |rto,scq/1 1 2 3 4 + | + RCR+ | - rto,svq/3 rto,svq/3 3 4 + RCR- | 0 1 2 3 4 + RVR+ | - - - rto,siq/5 rto,siq/5 + RVR- | 0 1 2 3 4 + RIR+ | - - - - - + RIR- | 0 1 2 3 4 + | + RUN+ | - - - - - + RUN- | sbc/0 sbc/1 sbc/2 sbc/3 sbc/4 + RUM+ | - - - - - + RUM- | sbc/0 sbc/1 sbc/2 sbc/3 sbc/4 + | + RBC | - - - 4 4 + RRL | - brto/2 brto/2 brto/4 brto/4 + RVF | - - - - - + RMR | - - - - - + | + TO+ | - scq/1 scq/2 svq/3 svq/4 + TO- | - 0 scq/1 0 scq/1 + UTO | - - - - - + XTO | - 0 0 0 0 + + + + + + + + + + + + + + + + + + +Karn & Simpson Experimental [Page 63] + +RFC 2522 Photuris Protocol March 1999 + + + + Initiator + + | 5 6 8 + |Identity IdentityBad Update + ------+----------------------------- + DU13 | 5 6 8 + SF0 | 5 6 rto,scq/1 + SF4 | 5 6 rto,scq/1 + SF5 | 5 6 rto,scq/1 + WC | 5 6 sun/8 + | + RCR+ | 5 6 8 + RCR- | 5 6 8 + RVR+ | 5 6 8 + RVR- | 5 6 8 + RIR+ | uto/8 uto/8 8 + RIR- | svf/5 svf/6 8 + | + RUN+ | - - sum/8 + RUN- | sbc/5 sbc/6 se*/8 + RUM+ | - - 8 + RUM- | sbc/5 sbc/6 se*/8 + | + RBC | 6 6 rto,scq/1 + RRL | 5 6 buto/8 + RVF | log/5 log/6 log/8 + RMR | log/5 log/6 log/8 + | + TO+ | sim/5 sim/6 - + TO- | 0 scq/1 - + UTO | - - sum/8 + XTO | 0 0 0 + + + + + + + + + + + + + + + + + + +Karn & Simpson Experimental [Page 64] + +RFC 2522 Photuris Protocol March 1999 + + + + Responder + + | 0 7 8 + | Initial Ready Update + ------+----------------------------- + WC | - 7 sun/8 + | + RCQ+ | scr/0 scr/7 scr/8 + RCQ- | srl/0 srl/7 srl/8 + RVQ+ |xto,svr/7 svr/7 svr/8 + RVQ- | sbc/0 sbc/7 sbc/8 + RIQ+ | - uto,sir/8 sir/8 + RIQ- | sbc/0 se*/7 se*/8 + | + RUN+ | - - sum/8 + RUN- | sbc/0 sbc/7 se*/8 + RUM+ | - - 8 + RUM- | sbc/0 sbc/7 se*/8 + | + RBC | - 7 rto,scq/1 + RRL | - - buto/8 + RVF | - - log/8 + RMR | - - log/8 + | + UTO | - - sum/8 + XTO | - 0 0 + + + +A.2. States + + Following is a more detailed description of each automaton state. + + The "Bad" version of a state is to indicate that the Bad_Cookie or + Resource_Limit message has been received. + + +A.2.1. Initial + + The Initial state is fictional, in that there is no state between the + parties. + + + + + + + + + +Karn & Simpson Experimental [Page 65] + +RFC 2522 Photuris Protocol March 1999 + + +A.2.2. Cookie + + In the Cookie state, the Initiator has sent a Cookie_Request, and is + waiting for a Cookie_Response. Both the Restart and Exchange timers + are running. + + Note that the Responder has no Cookie state. + + +A.2.3. Value + + In the Value state, the Initiator has sent its Exchange-Value, and is + waiting for an Identity_Message. Both the Restart and Exchange + timers are running. + + +A.2.4. Identity + + In the Identity state, the Initiator has sent an Identity_Request, + and is waiting for an Identity_Response in reply. Both the Restart + and Exchange timers are running. + + +A.2.5. Ready + + In the Ready state, the Responder has sent its Exchange-Value, and is + waiting for an Identity_Message. The Exchange timer is running. + + +A.2.6. Update + + In the Update state, each party has concluded the Photuris exchange, + and is unilaterally updating expiring SPIs until the Exchange + LifeTime expires. Both the Update and Exchange timers are running. + + + + + + + + + + + + + + + + + +Karn & Simpson Experimental [Page 66] + +RFC 2522 Photuris Protocol March 1999 + + +B. Use of Identification and Secrets + + Implementation of the base protocol requires support for operator + configuration of participant identities and associated symmetric + secret-keys. + + The form of the Identification and Secret fields is not constrained + to be a readable string. In addition to a simpler quoted string + configuration, an implementation MUST allow configuration of an + arbitrary stream of bytes. + + +B.1. Identification + + Typically, the Identification is a user name, a site name, a Fully + Qualified Domain Name, or an email address which contains a user name + and a domain name. Examples include: + + user + node.site. + user@node.site. + rcmd@node.site. + "Mundane Name" + + There is no requirement that the domain name match any of the + particular IP addresses in use by the parties. + + +B.2. Group Identity With Group Secret + + A simple configuration approach could use a single Identity and + Secret, distributed to all the participants in the trusted group. + This might be appropriate between routers under a single + administration comprising a Virtual Private Network over the + Internet. + + Nota Bene: + The passwords used in these examples do not meet the "MD5-IPMAC + Symmetric Identification" recommendation for at least 64-bits of + cryptographic strength. + + The administrator configures each router with the same username and + password: + + identity local "Tiny VPN 1995 November" "abracadabra" + identity remote "Tiny VPN 1995 November" "abracadabra" + + When the Initiator sends its Identity_Request, the SPI Owner + + + +Karn & Simpson Experimental [Page 67] + +RFC 2522 Photuris Protocol March 1999 + + + Identification field is "Tiny VPN 1995 November" and the SPI Owner + secret-key is "abracadabra". + + When the Responder sends its Identity_Response, the SPI Owner + Identification field is "Tiny VPN 1995 November" and the SPI Owner + secret-key is "abracadabra". The SPI User Identification is "Tiny + VPN 1995 November" (taken from the request), and the SPI User + secret-key is "abracadabra". + + Note that even in the face of implementations with very poor random + number generation yielding the same random numbers for both parties + at every step, and with this completely identical configuration, the + addition of the SPI User Verification field in the response + calculation is highly likely to produce a different Verification + value (see "Identity Verification"). In turn, the different + Verification values affect the calculation of SPI session-keys that + are highly likely to be different in each direction (see "Session-Key + Computation"). + + +B.3. Multiple Identities With Group Secrets + + A more robust configuration approach could use a separate Identity + and Secret for each party, distributed to the participants in the + trusted group. This might be appropriate for authenticated firewall + traversal. + + An administrator has one or more networks, and a number of mobile + users. It is desirable to restrict access to authorized external + users. The example boundary router is 10.0.0.1. + + The administrator gives each user a different username and password, + together with a group username and password for the router. + + The administrator configures (in part): + + identity local "199511@router.site" "FalDaRah" + identity remote "Happy_Wanderer@router.site" "FalDaRee" + + Each mobile user adds commands to tunnel and authenticate. + + route addprivate 10.0.0.0/8 tunnel 10.0.0.1 + secure 10.0.0.1 authenticate-only + identity local "Happy_Wanderer@router.site" "FalDaRee" + identity remote "199511@router.site" "FalDaRah" + identity remote "199512@router.site" "FalDaHaHaHaHaHaHa" + + When the mobile Initiator sends its Identity_Request, the SPI Owner + + + +Karn & Simpson Experimental [Page 68] + +RFC 2522 Photuris Protocol March 1999 + + + Identification field is "Happy_Wanderer@router.site" and the SPI + Owner secret-key is "FalDaRee". + + When the firewall Responder sends its Identity_Response, the SPI + Owner Identification field is "199511@router.site" and the SPI Owner + secret-key is "FalDaRah". The SPI User Identification field is + "Happy_Wanderer@router.site" (taken from the request), and the SPI + User secret-key is "FalDaRee". + + In this example, the mobile user is already prepared for a monthly + password changeover, where the router might identify itself as + "199512@router.site". + + +B.4. Multiple Identities With Multiple Secrets + + Greater security might be achieved through configuration of a pair of + secrets between each party. As before, one secret is used for + initial contact to any member of the group, but another secret is + used between specific parties. Compromise of one secret or pair of + secrets does not affect any other member of the group. This might be + appropriate between the routers forming a boundary between + cooperating Virtual Private Networks that establish local policy for + each VPN member access. + + One administrator configures: + + identity local "Apple" "all for one" + identity local "Apple-Baker" "Apple to Baker" "Baker" + identity remote "Baker" "one for all" + identity remote "Baker-Apple" "Baker to Apple" + + Another configures: + + identity local "Baker" "one for all" + identity local "Baker-Apple" "Baker to Apple" "Apple" + identity remote "Apple" "all for one" + identity remote "Apple-Baker" "Apple to Baker" + + When the Initiator sends its Identity_Request, the SPI Owner + Identification field is "Apple" and the SPI Owner secret-key is "all + for one". + + When the Responder sends its Identity_Response, finding that the + special pairing exists for "Apple" (in this example, indicated by a + third field), the SPI Owner Identification field is "Baker-Apple" and + the SPI Owner secret-key is "Baker to Apple". The SPI User + Identification is "Apple" (taken from the request), and the SPI User + + + +Karn & Simpson Experimental [Page 69] + +RFC 2522 Photuris Protocol March 1999 + + + secret-key is "all for one". + + +Operational Considerations + + The specification provides only a few configurable parameters, with + defaults that should satisfy most situations. + + Retransmissions + Default: 3. + + Initial Retransmission TimeOut (IRTO) + Default: 5 seconds. + + Exchange TimeOut (ETO) + Default: 30 seconds. Minimum: Retransmissions * IRTO. + + Exchange LifeTime (ELT) + Default: 30 minutes. Minimum: 2 * ETO. + + SPI LifeTime (SPILT) + Default: 5 minutes. Minimum: 3 * ETO. + + Each party configures a list of known identities and symmetric + secret-keys. + + In addition, each party configures local policy that determines what + access (if any) is granted to the holder of a particular identity. + For example, the party might allow anonymous FTP, but prohibit + Telnet. Such considerations are outside the scope of this document. + + +Security Considerations + + Photuris was based on currently available tools, by experienced + network protocol designers with an interest in cryptography, rather + than by cryptographers with an interest in network protocols. This + specification is intended to be readily implementable without + requiring an extensive background in cryptology. + + Therefore, only minimal background cryptologic discussion and + rationale is included in this document. Although some review has + been provided by the general cryptologic community, it is anticipated + that design decisions and tradeoffs will be thoroughly analysed in + subsequent dissertations and debated for many years to come. + + Cryptologic details are reserved for separate documents that may be + more readily and timely updated with new analysis. + + + +Karn & Simpson Experimental [Page 70] + +RFC 2522 Photuris Protocol March 1999 + + +History + + The initial specification of Photuris, now called version 1 (December + 1994 to March 1995), was based on a short list of design + requirements, and simple experimental code by Phil Karn. Only one + modular exponentiation form was used, with a single byte index of + pre-specified group parameters. The transform attributes were + selected during the public value exchange. Party privacy was + protected in the identification signature exchange with standard ESP + transforms. + + Upon submission for review by the IP Security Working Group, a large + number of features were demanded. A mere 254 future group choices + were not deemed enough; it was expanded to two bytes (and renamed + schemes), and was expanded again to carry variable parameters. The + transform attributes were made variable length to accomodate optional + parameters. Every other possible parameter was made negotiable. + Some participants were unable to switch modes on the UDP sockets to + use standard ESP transforms for only some messages, and party privacy + was integrated into the protocol. The message headers were + reorganized, and selection of transform attributes was delayed until + the identification exchange. An additional update message phase was + added. + + Version 2 (July 1995 to December 1995) specification stability was + achieved in November 1995 by moving most parameters into separate + documents for later discussion, and leaving only a few mandatory + features in the base specification. Within a month, multiple + interoperable implementations were produced. + + Unfortunately, in a fit of demagoguery, the IP Security Working Group + decided in a straw poll to remove party privacy protection, and the + Working Group chair terminated the meeting without allowing further + discussion. Because the identification exchange messages required + privacy to function correctly, the messages were reorganized again. + Party privacy and other optional schemes were split into a separate + document. + + The implementors established a separate discussion group. Version 3 + (April 1996 to June 1997) enjoyed a long period of specification + stability and multiple implementations on half a dozen platforms. + + Meanwhile, the IP Security Working Group has developed a competing + specification with large numbers of negotiable parameters. Also, the + PPP Extensions Working Group has deployed link security transforms. + + Version 4 (July 1997 onward) attempts to maintain a semblance of + interface compatibility with these other efforts. Minor changes are + + + +Karn & Simpson Experimental [Page 71] + +RFC 2522 Photuris Protocol March 1999 + + + specified in transform padding format and key generation. More than + one value is permitted per scheme, giving greater latitude in choice + for future extensions. The opportunity is taken to return party + privacy to the base document, and make small semantic changes in + automated updates and error recovery. All ESP transform attributes + are moved to separate documents, to (hopefully) avoid future + incompatible changes to the base document. + + +Acknowledgements + + Thou shalt make no law restricting the size of integers that may + be multiplied together, nor the number of times that an integer + may be multiplied by itself, nor the modulus by which an integer + may be reduced. [Prime Commandment] + + Phil Karn was principally responsible for the design of the protocol + phases, particularly the "cookie" anti-clogging defense, developed + the initial testing implementation, and provided much of the design + rationale text (now removed to a separate document). + + William Simpson was responsible for the packet formats and + attributes, additional message types, editing and formatting. All + such mistakes are his responsibility. + + This protocol was later discovered to have many elements in common + with the Station-To-Station authentication protocol [DOW92]. + + Angelos Keromytis developed the first completely independent + implementation (circa October 1995). Also, he suggested the cookie + exchange rate limitation counter. + + Paul C van Oorschot suggested signing both the public exponents and + the shared-secret, to provide an authentication-only version of + identity verification. Also, he provided text regarding moduli, + generator, and exponent selection (now removed to a separate + document). + + Hilarie Orman suggested adding secret "nonces" to session-key + generation for asymmetric public/private-key identity methods (now + removed to a separate document), and provided extensive review of the + protocol details. + + Bart Preneel and Paul C van Oorschot in [PO96] recommended padding + between the data and trailing key when hashing for authentication. + + Niels Provos developed another independent implementation (circa May + 1997), ported to AIX, Linux, OpenBSD, and Solaris. Also, he made + + + +Karn & Simpson Experimental [Page 72] + +RFC 2522 Photuris Protocol March 1999 + + + suggestions regarding automated update, and listing multiple moduli + per scheme. + + Bill Sommerfeld suggested including the authentication symmetric + secret-keys in the session-key generation, and using the Cookie + values on successive exchanges to provide bi-directional user- + oriented keying (now removed to a separate document). + + Oliver Spatscheck developed the second independent implementation + (circa December 1995) for the Xkernel. + + International interoperability testing between early implementors + provided the impetus for many of the implementation notes herein, and + numerous refinements in the semantics of the protocol messages. + + Randall Atkinson, Steven Bellovin, Wataru Hamada, James Hughes, Brian + LaMacchia, Cheryl Madson, Lewis McCarthy, Perry Metzger, Bob Quinn, + Ron Rivest, Rich Schroeppel, and Norman Shulman provided useful + critiques of earlier versions of this document. + + Special thanks to the Center for Information Technology Integration + (CITI) for providing computing resources. + + +References + + [BGMW93] E. Brickell, D. Gordon, K. McCurley, and D. Wilson, "Fast + Exponentiation with Precomputation (Extended Abstract)", + Advances in Cryptology -- Eurocrypt '92, Lecture Notes in + Computer Science 658 (1993), Springer-Verlag, 200-207. + + Also U.S. Patent #5,299,262, E.F. Brickell, D.M. Gordon, + K.S. McCurley, "Method for exponentiating in + cryptographic systems", 29 Mar 1994. + + [DH76] Diffie, W., and Hellman, H.E., "New Directions in + Cryptography", IEEE Transactions on Information Theory, v + IT-22 n 6 pp 644-654, November 1976. + + [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. + + [Firefly] "Photuris" is the latin name for the firefly. "Firefly" + is in turn the name for the USA National Security + Administration's (classified) key exchange protocol for + the STU-III secure telephone. Informed speculation has + + + +Karn & Simpson Experimental [Page 73] + +RFC 2522 Photuris Protocol March 1999 + + + it that Firefly is based on very similar design + principles. + + [LL94] Lim, C.H., Lee, P.J., "More flexible exponentiation with + precomputation", Advances in Cryptology -- Crypto '94, + Lecture Notes in Computer Science 839 (1994), Springer- + Verlag, pages 95-107. + + [Prime Commandment] + A derivation of an apocryphal quote from the usenet list + sci.crypt. + + [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-768] Postel, J., "User Datagram Protocol", STD 6, + USC/Information Sciences Institute, August 1980. + + [RFC-791] Postel, J., "Internet Protocol", STD 5, USC/Information + Sciences Institute, September 1981. + + [RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", MIT + Laboratory for Computer Science, April 1992. + + [RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, + USC/Information Sciences Institute, October 1994. + + [RFC-1812] Baker, F., Editor, "Requirements for IP Version 4 + Routers", Cisco Systems, June 1995. + + [RFC-1828] Metzger, P., Simpson, W., "IP Authentication using Keyed + MD5", July 1995. + + [RFC-1829] Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC + Transform", July 1995. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, Harvard University, March + 1997. + + [RFC-2521] Karn, P., and Simpson, W., "ICMP Security Failures + Messages", March 1999. + + [Rooij94] P. de Rooij, "Efficient exponentiation using + precomputation and vector addition chains", Advances in + Cryptology -- Eurocrypt '94, Lecture Notes in Computer + + + +Karn & Simpson Experimental [Page 74] + +RFC 2522 Photuris Protocol March 1999 + + + Science, Springer-Verlag, pages 403-415. + + [Schneier95] + Schneier, B., "Applied Cryptography Second Edition", John + Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. + + + +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) + + + + + + + + + + + + + + + + + + + +Karn & Simpson Experimental [Page 75] + +RFC 2522 Photuris Protocol March 1999 + + +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. + + + + + + + + + + + + + + + + + + + + + + + +Karn & Simpson Experimental [Page 76] + -- cgit v1.2.3