idnits 2.17.1 draft-simpson-photuris-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 96 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1998) is 9561 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Qualcomm' is mentioned on line 1, but not defined == Missing Reference: 'DayDreamer' is mentioned on line 2, but not defined == Missing Reference: 'RFC-1750' is mentioned on line 386, but not defined ** Obsolete undefined reference: RFC 1750 (Obsoleted by RFC 4086) == Unused Reference: 'BGMW93' is defined on line 3135, but no explicit reference was found in the text == Unused Reference: 'LL94' is defined on line 3159, but no explicit reference was found in the text == Unused Reference: 'Rooij94' is defined on line 3200, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BGMW93' -- Possible downref: Non-RFC (?) normative reference: ref. 'DH76' -- Possible downref: Non-RFC (?) normative reference: ref. 'DOW92' -- Possible downref: Non-RFC (?) normative reference: ref. 'Firefly' -- Possible downref: Non-RFC (?) normative reference: ref. 'LL94' -- Possible downref: Non-RFC (?) normative reference: ref. 'PO96' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Downref: Normative reference to an Historic RFC: RFC 1828 ** Downref: Normative reference to an Experimental draft: draft-simpson-icmp-ipsec-fail (ref. 'RFC-xxxx') -- Possible downref: Non-RFC (?) normative reference: ref. 'Rooij94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier95' Summary: 16 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P Karn [Qualcomm] 2 Internet Draft W A Simpson [DayDreamer] 3 expires in six months February 1998 5 Photuris: Session-Key Management Protocol 6 draft-simpson-photuris-18.txt | 8 Status of this Memo 10 This document is an Internet-Draft. Internet Drafts are working doc- 11 uments of the Internet Engineering Task Force (IETF), its Areas, and 12 its Working Groups. Note that other groups may also distribute work- 13 ing documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months, and may be updated, replaced, or obsoleted by other documents 17 at any time. It is not appropriate to use Internet Drafts as refer- 18 ence material, or to cite them other than as a ``working draft'' or 19 ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 23 Directories on: 25 ftp.is.co.za (Africa) 26 nic.nordu.net (Northern Europe) 27 ftp.nis.garr.it (Southern Europe) 28 ds.internic.net (Eastern USA) 29 ftp.isi.edu (Western USA) 30 munnari.oz.au (Pacific Rim) 32 Distribution of this memo is unlimited. 34 Copyright Notice 36 Copyright (C) Philip Karn and William Allen Simpson (1994-1998). All 37 Rights Reserved. 39 Abstract 41 Photuris is a session-key management protocol intended for use with 42 the IP Security Protocols (AH and ESP). This document defines the 43 basic protocol mechanisms. 45 1. Introduction 47 Photuris [Firefly] establishes short-lived session-keys between two 48 parties, without passing the session-keys across the Internet. These 49 session-keys directly replace the long-lived secret-keys (such as 50 passwords and passphrases) that have been historically configured for 51 security purposes. 53 The basic Photuris protocol utilizes these existing previously con- 54 figured secret-keys for identification of the parties. This is 55 intended to speed deployment and reduce administrative configuration 56 changes. 58 This document is primarily intended for implementing the Photuris 59 protocol. It does not detail service and application interface defi- 60 nitions, although it does mention some basic policy areas required 61 for the proper implementation and operation of the protocol mecha- 62 nisms. 64 Since the basic Photuris protocol is extensible, new data types and 65 protocol behaviour should be expected. The implementor is especially 66 cautioned not to depend on values that appear in examples to be cur- 67 rent or complete, since their purpose is primarily pedagogical. 69 1.1. Terminology 71 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 72 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 73 described in [RFC-2119]. 75 byte An 8-bit quantity; also known as "octet" in stan- 76 dardese. 78 exchange-value The publically distributable value used to calculate 79 a shared-secret. As used in this document, refers 80 to a Diffie-Hellman exchange, not the public part of 81 a public/private key-pair. 83 private-key A value that is kept secret, and is part of an asym- 84 metric public/private key-pair. 86 public-key A publically distributable value that is part of an 87 asymmetric public/private key-pair. 89 secret-key A symmetric key that is not publically dis- 90 tributable. As used in this document, this is dis- 91 tinguished from an asymmetric public/private key- 92 pair. An example is a user password. 94 Security Association (SA) 95 A collection of parameters describing the security 96 relationship between two nodes. These parameters 97 include the identities of the parties, the transform 98 (including algorithm and algorithm mode), the key(s) 99 (such as a session-key, secret-key, or appropriate 100 public/private key-pair), and possibly other infor- 101 mation such as sensitivity labelling. 103 Security Parameters Index (SPI) 104 A number that indicates a particular set of uni- | 105 directional attributes used under a Security Associ- 106 ation, such as transform(s) and session-key(s). The 107 number is relative to the IP Destination, which is 108 the SPI Owner, and is unique per IP (Next Header) 109 Protocol. That is, the same value MAY be used by 110 multiple protocols to concurrently indicate differ- 111 ent Security Association parameters. 113 session-key A key that is independently derived from a shared- 114 secret by the parties, and used for keying one 115 direction of traffic. This key is changed fre- 116 quently. 118 shared-secret As used in this document, the calculated result of 119 the Photuris exchange. 121 SPI Owner The party that corresponds to the IP Destination; 122 the intended recipient of a protected datagram. 124 SPI User The party that corresponds to the IP Source; the 125 sender of a protected datagram. 127 transform A cryptographic manipulation of a particular set of 128 data. As used in this document, refers to certain 129 well-specified methods (defined elsewhere). For 130 example, AH-MD5 [RFC-1828] transforms an IP datagram 131 into a cryptographic hash, and ESP-DES-CBC 132 [RFC-1829] transforms plaintext to ciphertext and 133 back again. 135 Many of these terms are hierarchically related: + 136 Security Association (bi-directional) + 137 - one or more lists of Security Parameters (uni-directional) + 138 -- one or more Attributes + 139 --- may have a key + 140 --- may indicate a transform + 142 Implementors will find details of cryptographic hashing (such as 143 MD5), encryption algorithms and modes (such as DES), digital signa- 144 tures (such as DSS), and other algorithms in [Schneier95]. 146 1.2. Protocol Overview 148 The Photuris protocol consists of several simple phases: 150 1. A "Cookie" Exchange guards against simple flooding attacks sent 151 with bogus IP Sources or UDP Ports. Each party passes a "cookie" 152 to the other. 154 In return, a list of supported Exchange-Schemes are offered by the 155 Responder for calculating a shared-secret. 157 2. A Value Exchange establishes a shared-secret between the parties. 158 Each party passes an Exchange-Value to the other. These values | 159 are used to calculate a shared-secret. The Responder remains 160 stateless until a shared-secret has been created. 162 In addition, supported attributes are offered by each party for 163 use in establishing new Security Parameters. 165 3. An Identification Exchange identifies the parties to each other, 166 and verifies the integrity of values sent in phases 1 and 2. 168 In addition, the shared-secret provides a basis to generate sepa- 169 rate session-keys in each direction, which are in turn used for 170 conventional authentication or encryption. Additional security 171 attributes are also exchanged as needed. 173 This exchange is masked for party privacy protection using a mes- 174 sage privacy-key based on the shared-secret. This protects the 175 identities of the parties, hides the Security Parameter attribute 176 values, and improves security for the exchange protocol and secu- 177 rity transforms. 179 4. Additional messages may be exchanged to periodically change the 180 session-keys, and to establish new or revised Security Parameters. 182 These exchanges are also masked for party privacy protection in 183 the same fashion as above. 185 The sequence of message types and their purposes are summarized in 186 the diagram below. The first three phases (cookie, exchange, and 187 identification) must be carried out in their entirety before any 188 Security Association can be used. 190 Initiator Responder 191 ========= ========= 192 Cookie_Request -> 193 <- Cookie_Response 194 offer schemes 195 Value_Request -> 196 pick scheme 197 offer value 198 offer attributes 199 <- Value_Response 200 offer value 201 offer attributes 203 [generate shared-secret from exchanged values] 205 Identity_Request -> 206 make SPI 207 pick SPI attribute(s) 208 identify self 209 authenticate 210 make privacy key(s) 211 mask/encrypt message 212 <- Identity_Response 213 make SPI 214 pick SPI attribute(s) 215 identify self 216 authenticate 217 make privacy key(s) 218 mask/encrypt message 220 [make SPI session-keys in each direction] 222 SPI User SPI Owner 223 ======== ========= 224 SPI_Needed -> 225 list SPI attribute(s) 226 make validity key 227 authenticate 228 make privacy key(s) 229 mask/encrypt message 230 <- SPI_Update 231 make SPI 232 pick SPI attribute(s) 233 make SPI session-key(s) 234 make validity key 235 authenticate 236 make privacy key(s) 237 mask/encrypt message 239 Either party may initiate an exchange at any time. For example, the 240 Initiator need not be a "caller" in a telephony link. 242 The Initiator is responsible for recovering from all message losses 243 by retransmission. 245 1.3. Security Parameters 247 A Photuris exchange between two parties results in a pair of SPI val- 248 ues (one in each direction). Each SPI is used in creating separate 249 session-key(s) in each direction. 251 The SPI is assigned by the entity controlling the IP Destination: the 252 SPI Owner (receiver). The parties use the combination of IP Destina- 253 tion, IP (Next Header) Protocol, and SPI to distinguish the correct 254 Security Association. 256 When both parties initiate Photuris exchanges concurrently, or one 257 party initiates more than one Photuris exchange, the Initiator Cook- 258 ies (and UDP Ports) keep the exchanges separate. This results in 259 more than one initial SPI for each Destination. 261 To create multiple SPIs with different parameters, the parties may 262 also send SPI_Updates. 264 There is no requirement that all such outstanding SPIs be used. The 265 SPI User (sender) selects an appropriate SPI for each datagram trans- 266 mission. 268 Implementation Notes: 270 The method used for SPI assignment is implementation dependent. 271 The only requirement is that the SPI be unique for the IP Destina- 272 tion and IP (Next Header) Protocol. 274 However, selection of a cryptographically random SPI value can 275 help prevent attacks that depend on a predicatable sequence of 276 values. The implementor MUST NOT expect SPI values to have a par- 277 ticular order or range. 279 1.4. LifeTimes 281 The Photuris exchange results in two kinds of state, each with sepa- 282 rate LifeTimes. 284 1) The Exchange LifeTime of the small amount of state associated with 285 the Photuris exchange itself. This state may be viewed as between 286 Internet nodes. 288 2) The SPI LifeTimes of the individual SPIs that are established. 289 This state may be viewed as between users and nodes. 291 The SPI LifeTimes may be shorter or longer than the Exchange Life- 292 Time. These LifeTimes are not required to be related to each other. 294 When an Exchange-Value expires (or is replaced by a newer value), any 295 unexpired derived SPIs are not affected. This is important to allow 296 traffic to continue without interruption during new Photuris 297 exchanges. 299 1.4.1. Exchange LifeTimes 301 All retained exchange state of both parties has an associated 302 Exchange LifeTime (ELT), and is subject to periodic expiration. This 303 depends on the physical and logistical security of the machine, and 304 is typically in the range of 10 minutes to one day (default 30 min- 305 utes). 307 In addition, during a Photuris exchange, an Exchange TimeOut (ETO) 308 limits the wait for the exchange to complete. This timeout includes 309 the packet round trips, and the time for completing the Identifica- 310 tion Exchange calculations. The time is bounded by both the maximum 311 amount of calculation delay expected for the processing power of an 312 unknown peer, and the minimum user expectation for results (default 313 30 seconds). 315 These Exchange LifeTimes and TimeOuts are implementation dependent 316 and are not disclosed in any Photuris message. The paranoid operator 317 will have a fairly short Exchange LifeTime, but it MUST NOT be less 318 than twice the ETO. 320 To prevent synchronization between Photuris exchanges, the implemen- 321 tation SHOULD randomly vary each Exchange LifeTime within twice the 322 range of seconds that are required to calculate a new Exchange-Value. 323 For example, when the Responder uses a base ELT of 30 minutes, and 324 takes 10 seconds to calculate the new Exchange-Value, the equation 325 might be (in milliseconds): 327 1790000 + urandom(20000) 329 The Exchange-Scheme, Exchange-Values, and resulting shared-secret MAY 330 be cached in short-term storage for the Exchange LifeTime. When 331 repetitive Photuris exchanges occur between the same parties, and the 332 Exchange-Values are discovered to be unchanged, the previously calcu- | 333 lated shared-secret can be used to rapidly generate new session-keys. | 335 1.4.2. SPI LifeTimes 337 Each SPI has an associated LifeTime, specified by the SPI owner 338 (receiver). This SPI LifeTime (SPILT) is usually related to the 339 speed of the link (typically 2 to 30 minutes), but it MUST NOT be 340 less than thrice the ETO. 342 The SPI can also be deleted by the SPI Owner using the SPI_Update. 343 Once the SPI has expired or been deleted, the parties cease using the 344 SPI. 346 To prevent synchronization between multiple Photuris exchanges, the 347 implementation SHOULD randomly vary each SPI LifeTime. For example, 348 when the Responder uses a base SPILT of 5 minutes, and 30 seconds for 349 the ETO, the equation might be (in milliseconds): 351 285000 + urandom(30000) 353 There is no requirement that a long LifeTime be accepted by the SPI 354 User. The SPI User might never use an established SPI, or cease 355 using the SPI at any time. 357 When more than one unexpired SPI is available to the SPI User for the 358 same function, a common implementation technique is to select the SPI 359 with the greatest remaining LifeTime. However, selecting randomly 360 among a large number of SPIs might provide some defense against traf- 361 fic analysis. 363 To prevent resurrection of deleted or expired SPIs, SPI Owners SHOULD 364 remember those SPIs, but mark them as unusable until the Photuris 365 exchange shared-secret used to create them also expires and purges 366 the associated state. 368 When the SPI Owner detects an incoming SPI that has recently expired, 369 but the associated exchange state has not yet been purged, the imple- 370 mentation MAY accept the SPI. The length of time allowed is highly 371 dependent on clock drift and variable packet round trip time, and is 372 therefore implementation dependent. 374 1.5. Random Number Generation 376 The security of Photuris critically depends on the quality of the 377 secret random numbers generated by each party. A poor random number 378 generator at either party will compromise the shared-secret produced 379 by the algorithm. 381 Generating cryptographic quality random numbers on a general purpose 382 computer without hardware assistance is a very tricky problem. In 383 general, this requires using a cryptographic hashing function to 384 "distill" the entropy from a large number of semi-random external 385 events, such as the timing of key strokes. An excellent discussion 386 can be found in [RFC-1750]. 388 2. Protocol Details 390 The Initiator begins a Photuris exchange under several circumstances: 392 - The Initiator has a datagram that it wishes to send with confiden- 393 tiality, and has no current Photuris exchange state with the IP 394 Destination. This datagram is discarded, and a Cookie_Request is 395 sent instead. 397 - The Initiator has received the ICMP message [RFC-1812] Destination 398 Unreachable: Communication Administratively Prohibited (Type 3, 399 Code 13), and has no current Photuris exchange state with the ICMP 400 Source. 402 - The Initiator has received the ICMP message [RFC-xxxx] Security 403 Failures: Bad SPI (Type 40, Code 0), that matches current Photuris 404 exchange state with the ICMP Source. 406 - The Initiator has received the ICMP message [RFC-xxxx] Security 407 Failures: Need Authentication (Type 40, Code 4), and has no cur- 408 rent Photuris exchange state with the ICMP Source. 410 - The Initiator has received the ICMP message [RFC-xxxx] Security 411 Failures: Need Authorization (Type 40, Code 5), that matches cur- 412 rent Photuris exchange state with the ICMP Source. 414 When the event is an ICMP message, special care MUST be taken that 415 the ICMP message actually includes information that matches a previ- 416 ously sent IP datagram. Otherwise, this could provide an opportunity 417 for a clogging attack, by stimulating a new Photuris Exchange. 419 2.1. UDP 421 All Photuris messages use the User Datagram Protocol header 422 [RFC-768]. The Initiator sends to UDP Destination Port 468. 424 When replying to the Initiator, the Responder swaps the IP Source and 425 Destination, and the UDP Source and Destination Ports. 427 The UDP checksum MUST be correctly calculated when sent. When a mes- 428 sage is received with an incorrect UDP checksum, it is silently dis- 429 carded. 431 Implementation Notes: 433 It is expected that installation of Photuris will ensure that UDP 434 checksum calculations are enabled for the computer operating sys- 435 tem and later disabling by operators is prevented. 437 Internet Protocol version 4 [RFC-791] restricts the maximum 438 reassembled datagram to 576 bytes. 440 When processing datagrams containing variable size values, the 441 length must be checked against the overall datagram length. An 442 invalid size (too long or short) that causes a poorly coded 443 receiver to abort could be used as a denial of service attack. 445 2.2. Header Format 447 All of the messages have a format similar to the following, as trans- 448 mitted left to right in network order (most significant to least sig- 449 nificant): 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | | 453 ~ Initiator-Cookie ~ 454 | | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | | 457 ~ Responder-Cookie ~ 458 | | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Message | 461 +-+-+-+-+-+-+-+-+ 463 Initiator-Cookie 16 bytes. 465 Responder-Cookie 16 bytes. 467 Message 1 byte. Each message type has a unique value. Ini- 468 tial values are assigned as follows: 470 0 Cookie_Request 471 1 Cookie_Response 472 2 Value_Request 473 3 Value_Response 474 4 Identity_Request 475 5 Secret_Response (optional) 476 6 Secret_Request (optional) 477 7 Identity_Response 478 8 SPI_Needed 479 9 SPI_Update 480 10 Bad_Cookie 481 11 Resource_Limit 482 12 Verification_Failure 483 13 Message_Reject 485 Further details and differences are elaborated in the individual mes- 486 sages. 488 2.3. Variable Precision Integers 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Size | Value ... 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 Size 2, 4, or 8 bytes. The number of significant bits 495 used in the Value field. Always transmitted most 496 significant byte first. 498 When the Size is zero, no Value field is present; 499 there are no significant bits. This means "missing" 500 or "null". It should not be confused with the value 501 zero, which includes an indication of the number of 502 significant bits. 504 When the most significant byte is in the range 0 505 through 254 (0xfe), the field is 2 bytes. Both 506 bytes are used to indicate the size of the Value 507 field, which ranges from 1 to 65,279 significant 508 bits (in 1 to 8,160 bytes). 510 When the most significant byte is 255 (0xff), the 511 field is 4 bytes. The remaining 3 bytes are added 512 to 65,280 to indicate the size of the Value field, 513 which is limited to 16,776,959 significant bits (in 514 2,097,120 bytes). 516 When the most significant 2 bytes are 65,535 517 (0xffff), the field is 8 bytes. The remaining 6 518 bytes are added to 16,776,960 to indicate the size 519 of the Value field. 521 Value 0 or more bytes. Always transmitted most signifi- 522 cant byte first. 524 The bits used are right justified within byte bound- 525 aries; that is, any unused bits are in the most sig- 526 nificant byte. When there are no unused bits, or 527 unused bits are zero filled, the value is assumed to 528 be an unsigned positive integer. 530 When the leading unused bits are ones filled, the 531 number is assumed to be a two's-complement negative 532 integer. A negative integer will always have at 533 least one unused leading sign bit in the most sig- 534 nificant byte. 536 Shortened forms SHOULD NOT be used when the Value includes a number 537 of leading zero significant bits. The Size SHOULD indicate the cor- 538 rect number of significant bits. 540 Implementation Notes: 542 Negative integers are not required to be supported, but are 543 included for completeness. 545 No more than 65,279 significant bits are required to be supported. 546 Other ranges are vastly too long for these UDP messages, but are 547 included for completeness. 549 2.4. Exchange-Schemes 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Scheme | Size | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Value ... 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 Scheme 2 bytes. A unique value indicating the Exchange- 558 Scheme. See the "Basic Exchange-Schemes" for 559 details. 561 Size 2 bytes, ranging from 0 to 65,279. See "Variable 562 Precision Integer". 564 Value 0 or more bytes. See "Variable Precision Integer". 566 The Size MUST NOT be assumed to be constant for a particular Scheme. 567 Multiple kinds of the same Scheme with varying Sizes MAY be present 568 in any list of schemes. 570 However, only one of each Scheme and Size combination will be present 571 in any list of schemes. 573 2.5. Attributes 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Attribute | Length | Value(s) ... 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Attribute 1 byte. A unique value indicating the kind of 580 attribute. See the "Basic Attributes" for details. 582 When the value is zero (padding), no Length field is 583 present (always zero). 585 Length 1 byte. The size of the Value(s) field in bytes. 587 When the Length is zero, no Value(s) field is pre- 588 sent. 590 Value(s) 0 or more bytes. See the "Basic Attributes" for 591 details. 593 The Length MUST NOT be assumed to be constant for a particular 594 Attribute. Multiple kinds of the same Attribute with varying Lengths 595 MAY be present in any list of attributes. 597 Implementation Note: 599 The authentication, compression, encryption and identification 600 mechanisms chosen, as well as the encapsulation modes (if any), 601 need not be the same in both directions. 603 3. Cookie Exchange 605 Initiator Responder 606 ========= ========= 607 Cookie_Request -> 608 <- Cookie_Response 609 offer schemes 611 3.0.1. Send Cookie_Request 613 The Initiator initializes local state, and generates a unique 614 "cookie". The Initiator-Cookie MUST be different in each new 615 Cookie_Request between the same parties. See "Cookie Generation" for 616 details. 618 - If any previous exchange between the peer IP nodes has not expired 619 in which this party was the Initiator, this Responder-Cookie is 620 set to the most recent Responder-Cookie, and this Counter is set 621 to the corresponding Counter. 623 For example, a new Virtual Private Network (VPN) tunnel is about 624 to be established to an existing partner. The Counter is the same 625 value received in the prior Cookie_Response, the Responder-Cookie 626 remains the same, and a new Initiator-Cookie is generated. 628 - If the new Cookie_Request is in response to a message of a previ- 629 ous exchange in which this party was the Responder, this Respon- 630 der-Cookie is set to the previous Initiator-Cookie, and this 631 Counter is set to zero. 633 For example, a Bad_Cookie message was received from the previous 634 Initiator in response to SPI_Needed. The Responder-Cookie is 635 replaced with the Initiator-Cookie, and a new Initiator-Cookie is 636 generated. This provides bookkeeping to detect bogus Bad_Cookie 637 messages. 639 Also, can be used for bi-directional User, Transport, and Process 640 oriented keying. Such mechanisms are outside the scope of this 641 document. 643 - Otherwise, this Responder-Cookie and Counter are both set to zero. 645 By default, the Initiator operates in the same manner as when all 646 of its previous exchange state has expired. The Responder will 647 send a Resource_Limit when its own exchange state has not expired. 649 The Initiator also starts a retransmission timer. If no valid 650 Cookie_Response arrives within the time limit, the same 651 Cookie_Request is retransmitted for the remaining number of Retrans- 652 missions. The Initiator-Cookie value MUST be the same in each such 653 retransmission to the same IP Destination and UDP Port. 655 When Retransmissions have been exceeded, if a Resource_Limit message 656 has been received during the exchange, the Initiator SHOULD begin the 657 Photuris exchange again by sending a new Cookie_Request with updated 658 values. 660 3.0.2. Receive Cookie_Request 662 On receipt of a Cookie_Request, the Responder determines whether 663 there are sufficient resources to begin another Photuris exchange. 665 - When too many SPI values are already in use for this particular 666 peer, or too many concurrent exchanges are in progress, or some 667 other resource limit is reached, a Resource_Limit message is sent. 669 - When any previous exchange initiated by this particular peer has 670 not exceeded the Exchange TimeOut, and the Responder-Cookie does 671 not specify one of these previous exchanges, a Resource_Limit mes- 672 sage is sent. 674 Otherwise, the Responder returns a Cookie_Response. 676 Note that the Responder creates no additional state at this time. 678 3.0.3. Send Cookie_Response 680 The IP Source for the Initiator is examined. If any previous 681 exchange between the peer IP nodes has not expired, the response 682 Counter is set to the most recent exchange Counter plus one (allowing 683 for out of order retransmissions). Otherwise, the response Counter 684 is set to the request Counter plus one. 686 If (through rollover of the Counter) the new Counter value is zero 687 (modulo 256), the value is set to one. 689 If this new Counter value matches some previous exchange initiated by 690 this particular peer that has not yet exceeded the Exchange TimeOut, 691 the Counter is incremented again, until a unique Counter value is 692 reached. 694 Nota Bene: 695 No more than 254 concurrent exchanges between the same two peers 696 are supported. 698 The Responder generates a unique cookie. The Responder-Cookie value 699 in each successive response SHOULD be different. See "Cookie Genera- 700 tion" for details. 702 The Exchange-Schemes available between the peers are listed in the 703 Offered-Schemes. 705 3.0.4. Receive Cookie_Response 707 The Initiator validates the Initiator-Cookie, and the Offered- 708 Schemes. 710 - When an invalid/expired Initiator-Cookie is detected, the message | 711 is silently discarded. 713 - When the variable length Offered-Schemes do not match the UDP | 714 Length, or all Offered-Schemes are obviously defective and/or 715 insufficient for the purposes intended, the message is silently 716 discarded; the implementation SHOULD log the occurance, and notify 717 an operator as appropriate. 719 - Once a valid message has been received, later Cookie_Responses 720 with matching Initiator-Cookies are also silently discarded, until 721 a new Cookie_Request is sent. 723 When the message is valid, an Exchange-Scheme is chosen from the list 724 of Offered-Schemes. 726 This Scheme-Choice may affect the next Photuris message sent. By 727 default, the next Photuris message is a Value_Request. 729 Implementation Notes: 731 Only the Initiator-Cookie is used to identify the exchange. The 732 Counter and Responder-Cookie will both be different from the 733 Cookie_Request. 735 Various proposals for extensions utilize the Scheme-Choice to 736 indicate a different message sequence. Such mechanisms are out- 737 side the scope of this document. 739 3.1. Cookie_Request 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | | 743 ~ Initiator-Cookie ~ 744 | | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | | 747 ~ Responder-Cookie ~ 748 | | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Message | Counter | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 Initiator-Cookie 16 bytes. A randomized value that identifies the 754 exchange. The value MUST NOT be zero. See "Cookie 755 Generation" for details. 757 Responder-Cookie 16 bytes. Identifies a specific previous exchange. 758 Copied from a previous Cookie_Response. 760 When zero, no previous exchange is specified. 762 When non-zero, and the Counter is zero, contains the 763 Initiator-Cookie of a previous exchange. The speci- 764 fied party is requested to be the Responder in this 765 exchange, to retain previous party pairings. 767 When non-zero, and the Counter is also non-zero, 768 contains the Responder-Cookie of a previous 769 exchange. The specified party is requested to be 770 the Responder in this exchange, to retain previous 771 party pairings. 773 Message 0 775 Counter 1 byte. Indicates the number of previous exchanges. 777 When zero, the Responder-Cookie indicates the Ini- 778 tiator of a previous exchange, or no previous 779 exchange is specified. 781 When non-zero, the Responder-Cookie indicates the 782 Responder to a previous exchange. This value is set 783 to the Counter from the corresponding 784 Cookie_Response or from a Resource_Limit. 786 3.2. Cookie_Response 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | | 790 ~ Initiator-Cookie ~ 791 | | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | | 794 ~ Responder-Cookie ~ 795 | | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Message | Counter | Offered-Schemes ... 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 Initiator-Cookie 16 bytes. Copied from the Cookie_Request. 802 Responder-Cookie 16 bytes. A randomized value that identifies the 803 exchange. The value MUST NOT be zero. See "Cookie 804 Generation" for details. 806 Message 1 808 Counter 1 byte. Indicates the number of the current 809 exchange. Must be greater than zero. 811 Offered-Schemes 4 or more bytes. A list of one or more Exchange- 812 Schemes supported by the Responder, ordered from 813 most to least preferable. See the "Basic Exchange- 814 Schemes" for details. 816 Only one Scheme (#2) is required to be supported, 817 and SHOULD be present in every Offered-Schemes list. 819 More than one of each kind of Scheme may be offered, 820 but each is distinguished by its Size. The end of 821 the list is indicated by the UDP Length. 823 3.3. Cookie Generation 825 The exact technique by which a Photuris party generates a cookie is 826 implementation dependent. The method chosen must satisfy some basic 827 requirements: 829 1. The cookie MUST depend on the specific parties. This prevents an 830 attacker from obtaining a cookie using a real IP address and UDP 831 port, and then using it to swamp the victim with requests from 832 randomly chosen IP addresses or ports. 834 2. It MUST NOT be possible for anyone other than the issuing entity 835 to generate cookies that will be accepted by that entity. This 836 implies that the issuing entity will use local secret information 837 in the generation and subsequent verification of a cookie. It 838 must not be possible to deduce this secret information from any 839 particular cookie. 841 3. The cookie generation and verification methods MUST be fast to 842 thwart attacks intended to sabotage CPU resources. 844 A recommended technique is to use a cryptographic hashing function 845 (such as MD5). 847 An incoming cookie can be verified at any time by regenerating it 848 locally from values contained in the incoming datagram and the local 849 secret random value. 851 3.3.1. Initiator Cookie 853 The Initiator secret value that affects its cookie SHOULD change for 854 each new Photuris exchange, and is thereafter internally cached on a 855 per Responder basis. This provides improved synchronization and pro- 856 tection against replay attacks. 858 An alternative is to cache the cookie instead of the secret value. 859 Incoming cookies can be compared directly without the computational 860 cost of regeneration. 862 It is recommended that the cookie be calculated over the secret 863 value, the IP Source and Destination addresses, and the UDP Source 864 and Destination ports. 866 Implementation Notes: 868 Although the recommendation includes the UDP Source port, this is 869 very implementation specific. For example, it might not be 870 included when the value is constant. 872 However, it is important that the implementation protect mutually 873 suspicious users of the same machine from generating the same 874 cookie. 876 3.3.2. Responder Cookie 878 The Responder secret value that affects its cookies MAY remain the 879 same for many different Initiators. However, this secret SHOULD be 880 changed periodically to limit the time for use of its cookies (typi- 881 cally each 60 seconds). 883 The Responder-Cookie SHOULD include the Initiator-Cookie. The 884 Responder-Cookie MUST include the Counter (that is returned in the 885 Cookie_Response). This provides improved synchronization and protec- 886 tion against replay attacks. 888 It is recommended that the cookie be calculated over the secret 889 value, the IP Source and Destination addresses, its own UDP Destina- 890 tion port, the Counter, the Initiator-Cookie, and the currently 891 Offered-Schemes. 893 The cookie is not cached per Initiator to avoid saving state during 894 the initial Cookie Exchange. On receipt of a Value_Request 895 (described later), the Responder regenerates its cookie for valida- 896 tion. 898 Once the Value_Response is sent (also described later), both Initia- 899 tor and Responder cookies are cached to identify the exchange. 901 Implementation Notes: 903 Although the recommendation does not include the UDP Source port, 904 this is very implementation specific. It might be successfully 905 included in some variants. 907 However, it is important that the UDP Source port not be included 908 when matching existing Photuris exchanges for determining the 909 appropriate Counter. 911 The recommendation includes the Offered-Schemes to detect a 912 dynamic change of scheme value between the Cookie_Response and 913 Value_Response. 915 Some mechanism MAY be needed to detect a dynamic change of pre- 916 calculated Responder Exchange-Value between the Value_Response and 917 Identity_Response. For example, change the secret value to render 918 the cookie invalid, or explicitly mark the Photuris exchange state 919 as expired. 921 4. Value Exchange 923 Initiator Responder 924 ========= ========= 925 Value_Request -> 926 pick scheme 927 offer value 928 offer attributes 929 <- Value_Response 930 offer value 931 offer attributes 933 [generate shared-secret from exchanged values] 935 4.0.1. Send Value_Request 937 The Initiator generates an appropriate Exchange-Value for the Scheme- 938 Choice. This Exchange-Value may be pre-calculated and used for mul- 939 tiple Responders. 941 The IP Destination for the Responder is examined, and the attributes 942 available between the parties are listed in the Offered-Attributes. 944 The Initiator also starts a retransmission timer. If no valid 945 Value_Response arrives within the time limit, the same Value_Request 946 is retransmitted for the remaining number of Retransmissions. 948 When Retransmissions have been exceeded, if a Bad_Cookie or 949 Resource_Limit message has been received during the exchange, the 950 Initiator SHOULD begin the Photuris exchange again by sending a new 951 Cookie_Request. 953 4.0.2. Receive Value_Request 955 The Responder validates the Responder-Cookie, the Counter, the 956 Scheme-Choice, the Exchange-Value, and the Offered-Attributes. 958 - When an invalid/expired Responder-Cookie is detected, a Bad_Cookie | 959 message is sent. 961 - When too many SPI values are already in use for this particular | 962 peer, or too many concurrent exchanges are in progress, or some | 963 other resource limit is reached, a Resource_Limit message is sent. | 965 - When an invalid Scheme-Choice is detected, or the Exchange-Value 966 is obviously defective, or the variable length Offered-Attributes 967 do not match the UDP Length, the message is silently discarded; 968 the implementation SHOULD log the occurance, and notify an opera- 969 tor as appropriate. 971 When the message is valid, the Responder sets its Exchange timer to 972 the Exchange TimeOut, and returns a Value_Response. 974 The Responder keeps a copy of the incoming Value_Request cookie pair, 975 and its Value_Response. If a duplicate Value_Request is received, it 976 merely resends its previous Value_Response, and takes no further 977 action. 979 4.0.3. Send Value_Response 981 The Responder generates an appropriate Exchange-Value for the Scheme- 982 Choice. This Exchange-Value may be pre-calculated and used for mul- 983 tiple Initiators. 985 The IP Source for the Initiator is examined, and the attributes 986 available between the parties are listed in the Offered-Attributes. 988 Implementation Notes: 990 At this time, the Responder begins calculation of the shared- 991 secret. Calculation of the shared-secret is executed in parallel 992 to minimize delay. 994 This may take a substantial amount of time. The implementor 995 should ensure that retransmission is not blocked by this calcula- 996 tion. This is not usually a problem, as retransmission timeouts 997 typically exceed calculation time. 999 4.0.4. Receive Value_Response 1001 The Initiator validates the pair of Cookies, the Exchange-Value, and 1002 the Offered-Attributes. 1004 - When an invalid/expired cookie is detected, the message is | 1005 silently discarded. 1007 - When the Exchange-Value is obviously defective, or the variable | 1008 length Offered-Attributes do not match the UDP Length, the message 1009 is silently discarded; the implementation SHOULD log the occu- 1010 rance, and notify an operator as appropriate. 1012 - Once a valid message has been received, later Value_Responses with 1013 both matching cookies are also silently discarded, until a new 1014 Cookie_Request is sent. 1016 When the message is valid, the Initiator begins its parallel computa- 1017 tion of the shared-secret. 1019 When the Initiator completes computation, it sends an Iden- 1020 tity_Request to the Responder. 1022 4.1. Value_Request 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | | 1026 ~ Initiator-Cookie ~ 1027 | | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | | 1030 ~ Responder-Cookie ~ 1031 | | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | Message | Counter | Scheme-Choice | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | | 1036 ~ Initiator-Exchange-Value ~ 1037 | | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Initiator-Offered-Attributes ... 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1042 Initiator-Cookie 16 bytes. Copied from the Cookie_Response. 1044 Responder-Cookie 16 bytes. Copied from the Cookie_Response. 1046 Message 2 1048 Counter 1 byte. Copied from the Cookie_Response. 1050 Scheme-Choice 2 bytes. A value selected by the Initiator from the 1051 list of Offered-Schemes in the Cookie_Response. 1053 Only the Scheme is specified; the Size will match 1054 the Initiator-Exchange-Value, and the Value(s) are 1055 implicit. 1057 Initiator-Exchange-Value 1058 Variable Precision Integer. Provided by the Initia- 1059 tor for calculating a shared-secret between the par- 1060 ties. The Value format is indicated by the Scheme- 1061 Choice. 1063 The field may be any integral number of bytes in 1064 length, as indicated by its Size field. It does not 1065 require any particular alignment. The 32-bit align- 1066 ment shown is for convenience in the illustration. 1068 Initiator-Offered-Attributes 1069 4 or more bytes. A list of Security Parameter 1070 attributes supported by the Initiator. 1072 The contents and usage of this list are further 1073 described in "Offered Attributes List". The end of 1074 the list is indicated by the UDP Length. 1076 4.2. Value_Response 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | | 1080 ~ Initiator-Cookie ~ 1081 | | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | | 1084 ~ Responder-Cookie ~ 1085 | | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | Message | Reserved | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 | | 1090 ~ Responder-Exchange-Value ~ 1091 | | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Responder-Offered-Attributes ... 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1096 Initiator-Cookie 16 bytes. Copied from the Value_Request. 1098 Responder-Cookie 16 bytes. Copied from the Value_Request. 1100 Message 3 1102 Reserved 3 bytes. For future use; MUST be set to zero when 1103 transmitted, and MUST be ignored when received. 1105 Responder-Exchange-Value 1106 Variable Precision Integer. Provided by the Respon- 1107 der for calculating a shared-secret between the par- 1108 ties. The Value format is indicated by the current 1109 Scheme-Choice specified in the Value_Request. 1111 The field may be any integral number of bytes in 1112 length, as indicated by its Size field. It does not 1113 require any particular alignment. The 32-bit align- 1114 ment shown is for convenience in the illustration. 1116 Responder-Offered-Attributes 1117 4 or more bytes. A list of Security Parameter 1118 attributes supported by the Responder. 1120 The contents and usage of this list are further 1121 described in "Offered Attributes List". The end of 1122 the list is indicated by the UDP Length. 1124 4.3. Offered Attribute List 1126 This list includes those attributes supported by the party that are 1127 available to the other party. The attribute formats are specified in 1128 the "Basic Attributes". 1130 The list is composed of two or three sections: Identification- 1131 Attributes, Authentication-Attributes, and (optional) Encapsulation- 1132 Attributes. Within each section, the attributes are ordered from 1133 most to least preferable. 1135 The first section of the list includes methods of identification. An 1136 Identity-Choice is selected from this list. 1138 The second section of the list begins with "AH-Attributes" (#1). It 1139 includes methods of authentication, and other operational types. 1141 The third section of the list begins with "ESP-Attributes" (#2). It 1142 includes methods of authentication, compression, encryption, and 1143 other operational types. When no Encapsulation-Attributes are 1144 offered, the "ESP-Attributes" attribute itself is omitted from the 1145 list. 1147 Attribute-Choices are selected from the latter two sections of the 1148 list. 1150 Support is required for the "MD5-IPMAC" (#5) attribute for both "Sym- | 1151 metric Identification" and "Authentication" and they SHOULD be pre- | 1152 sent in every Offered-Attributes list. 1154 Implementation Notes: 1156 For example, + 1158 "MD5-IPMAC" (Symmetric Identification), + 1159 "AH-Attributes", + 1160 "MD5-IPMAC" (Authentication). + 1162 Since the offer is made by the prospective SPI User (sender), 1163 order of preference likely reflects the capabilities and engineer- 1164 ing tradeoffs of a particular implementation. 1166 However, the critical processing bottlenecks are frequently in the 1167 receiver. The SPI Owner (receiver) may express its needs by 1168 choosing a less preferable attribute. 1170 The order may also be affected by operational policy and requested 1171 services for an application. Such considerations are outside the 1172 scope of this document. + 1174 The list may be divided into additional sections. These sections + 1175 will always follow the ESP-Attributes section, and are indistin- + 1176 guishable from unrecognized attributes. 1178 5. Identification Exchange 1180 Initiator Responder 1181 ========= ========= 1182 Identity_Request -> 1183 make SPI 1184 pick SPI attribute(s) 1185 identify self 1186 authenticate 1187 make privacy key(s) 1188 mask/encrypt message 1189 <- Identity_Response 1190 make SPI 1191 pick SPI attribute(s) 1192 identify self 1193 authenticate 1194 make privacy key(s) 1195 mask/encrypt message 1197 [make SPI session-keys in each direction] 1199 The exchange of messages is ordered, although the formats and mean- 1200 ings of the messages are identical in each direction. The messages 1201 are easily distinguished by the parties themselves, by examining the 1202 Message and Identification fields. 1204 Implementation Notes: 1206 The amount of time for the calculation may be dependent on the 1207 value of particular bits in secret values used in generating the 1208 shared-secret or identity verification. To prevent analysis of 1209 these secret bits by recording the time for calculation, sending 1210 of the Identity_Messages SHOULD be delayed until the time expected 1211 for the longest calculation. This will be different for different 1212 processor speeds, different algorithms, and different length vari- 1213 ables. Therefore, the method for estimating time is implementa- 1214 tion dependent. 1216 Any authenticated and/or encrypted user datagrams received before 1217 the completion of identity verification can be placed on a queue 1218 pending completion of this step. If verification succeeds, the 1219 queue is processed as though the datagrams had arrived subsequent 1220 to the verification. If verification fails, the queue is dis- 1221 carded. 1223 5.0.1. Send Identity_Request 1225 The Initiator chooses an appropriate Identification, the SPI and 1226 SPILT, a set of Attributes for the SPI, calculates the Verification, 1227 and masks the message using the Privacy-Method indicated by the cur- 1228 rent Scheme-Choice. 1230 The Initiator also starts a retransmission timer. If no valid Iden- 1231 tity_Response arrives within the time limit, its previous Iden- 1232 tity_Request is retransmitted for the remaining number of Retransmis- 1233 sions. 1235 When Retransmissions have been exceeded, if a Bad_Cookie message has 1236 been received during the exchange, the Initiator SHOULD begin the 1237 Photuris exchange again by sending a new Cookie_Request. 1239 5.0.2. Receive Identity_Request 1241 The Responder validates the pair of Cookies, the Padding, the Identi- 1242 fication, the Verification, and the Attribute-Choices. 1244 - When an invalid/expired cookie is detected, a Bad_Cookie message | 1245 is sent. 1247 - After unmasking, when invalid Padding is detected, the variable | 1248 length Attribute-Choices do not match the UDP Length, or an | 1249 attribute was not in the Offered-Attributes, the message is | 1250 silently discarded. | 1252 - When an invalid Identification is detected, or the message verifi- 1253 cation fails, a Verification_Failure message is sent. 1255 - Whenever such a problem is detected, the Security Association is - 1256 not established; the implementation SHOULD log the occurance, and 1257 notify an operator as appropriate. 1259 When the message is valid, the Responder sets its Exchange timer to 1260 the Exchange LifeTime (if this has not already been done for a previ- 1261 ous exchange). When its parallel computation of the shared-secret is 1262 complete, the Responder returns an Identity_Response. 1264 The Responder keeps a copy of the incoming Identity_Request values, 1265 and its Identity_Response. If a duplicate Identity_Request is 1266 received, it merely resends its previous Identity_Response, and takes 1267 no further action. 1269 5.0.3. Send Identity_Response 1271 The Responder chooses an appropriate Identification, the SPI and 1272 SPILT, a set of Attributes for the SPI, calculates the Verification, 1273 and masks the message using the Privacy-Method indicated by the cur- 1274 rent Scheme-Choice. 1276 The Responder calculates the SPI session-keys in both directions. 1278 At this time, the Responder begins the authentication and/or encryp- 1279 tion of user datagrams. 1281 5.0.4. Receive Identity_Response 1283 The Initiator validates the pair of Cookies, the Padding, the Identi- 1284 fication, the Verification, and the Attribute-Choices. 1286 - When an invalid/expired cookie is detected, the message is | 1287 silently discarded. 1289 - After unmasking, when invalid Padding is detected, the variable | 1290 length Attribute-Choices do not match the UDP Length, or an | 1291 attribute was not in the Offered-Attributes, the message is | 1292 silently discarded. | 1294 - When an invalid Identification is detected, or the message verifi- 1295 cation fails, a Verification_Failure message is sent. 1297 - Whenever such a problem is detected, the Security Association is - 1298 not established; the implementation SHOULD log the occurance, and 1299 notify an operator as appropriate. 1301 - Once a valid message has been received, later Identity_Responses 1302 with both matching cookies are also silently discarded, until a 1303 new Cookie_Request is sent. 1305 When the message is valid, the Initiator sets its Exchange timer to 1306 the Exchange LifeTime (if this has not already been done for a previ- 1307 ous exchange). 1309 The Initiator calculates the SPI session-keys in both directions. 1311 At this time, the Initiator begins the authentication and/or encryp- 1312 tion of user datagrams. 1314 5.1. Identity_Messages 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 | | 1318 ~ Initiator-Cookie ~ 1319 | | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 | | 1322 ~ Responder-Cookie ~ 1323 | | 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 | Message | LifeTime | 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | Security-Parameters-Index | 1328 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1329 | Identity-Choice | | 1330 + + + + + + + + + + + + + + + + + + | 1331 | | 1332 ~ Identification ~ 1333 | | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | | 1336 ~ Verification ~ 1337 | | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | Attribute-Choices ... 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 ... Padding | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 Initiator-Cookie 16 bytes. Copied from the Value_Request. 1346 Responder-Cookie 16 bytes. Copied from the Value_Request. 1348 Message 4 (Request) or 7 (Response) 1350 LifeTime 3 bytes. The number of seconds remaining before the 1351 indicated SPI expires. 1353 When the SPI is zero, this field MUST be filled with 1354 a random non-zero value. 1356 Security-Parameters-Index (SPI) 1357 4 bytes. The SPI to be used for incoming communica- 1358 tions. 1360 When zero, indicates that no SPI is created in this 1361 direction. 1363 Identity-Choice 2 or more bytes. An identity attribute is selected 1364 from the list of Offered-Attributes sent by the 1365 peer, and is used to calculate the Verification. 1367 The field may be any integral number of bytes in 1368 length, as indicated by its Length field. It does 1369 not require any particular alignment. The 16-bit 1370 alignment shown is for convenience in the illustra- 1371 tion. 1373 Identification Variable Precision Integer, or alternative format 1374 indicated by the Identity-Choice. See the "Basic 1375 Attributes" for details. 1377 The field may be any integral number of bytes in 1378 length. It does not require any particular align- 1379 ment. The 32-bit alignment shown is for convenience 1380 in the illustration. 1382 Verification Variable Precision Integer, or alternative format 1383 indicated by the Identity-Choice. The calculation 1384 of the value is described in "Identity Verifica- 1385 tion". 1387 The field may be any integral number of bytes in 1388 length. It does not require any particular align- 1389 ment. The 32-bit alignment shown is for convenience 1390 in the illustration. 1392 Attribute-Choices 1393 0 or more bytes. When the SPI is non-zero, a list 1394 of attributes selected from the list of Offered- 1395 Attributes supported by the peer. 1397 The contents and usage of this list are further 1398 described in "Attribute Choices List". The end of 1399 the list is indicated by the UDP Length after remov- 1400 ing the Padding (UDP Length - last Padding value). 1402 Padding 8 to 255 bytes. This field is filled up to at least 1403 a 128 byte boundary, measured from the beginning of 1404 the message. The number of pad bytes are chosen 1405 randomly. 1407 In addition, when a Privacy-Method indicated by the 1408 current Scheme-Choice requires the plaintext to be a 1409 multiple of some number of bytes (the block size of 1410 a block cipher), this field is adjusted as necessary 1411 to the size required by the algorithm. 1413 Self-Describing-Padding begins with the value 1. 1414 Each byte contains the index of that byte. Thus, 1415 the final pad byte indicates the number of pad bytes 1416 to remove. For example, when the unpadded message 1417 length is 120 bytes, the padding values might be 1, 1418 2, 3, 4, 5, 6, 7, and 8. 1420 The portion of the message after the SPI field is masked using the 1421 Privacy-Method indicated by the current Scheme-Choice. 1423 The fields following the SPI are opaque. That is, the values are set 1424 prior to masking (and optional encryption), and examined only after 1425 unmasking (and optional decryption). 1427 5.2. Attribute Choices List 1429 This list specifies the attributes of the SPI. The attribute formats 1430 are specified in the "Basic Attributes". 1432 The list is composed of one or two sections: Authentication- 1433 Attributes, and/or Encapsulation-Attributes. 1435 When sending from the SPI User to the SPI Owner, the attributes are 1436 processed in the order listed. For example, 1438 "ESP-Attributes", 1439 "ESP-Sequence", 1440 "Deflate" (Compression), | 1441 "DES-CBC" (Encryption), | 1442 "AH-Attributes", 1443 "MD5-IPMAC" (Authentication), | 1445 would result in ESP with sequence numbers, compression and triple 1446 encryption (inside), and then AH authentication (outside) of the ESP 1447 payload. 1449 The SPI Owner will naturally process the datagram in the reverse 1450 order. 1452 This ordering also affects the order of key generation. Both SPI 1453 Owner and SPI User generate the keys in the order listed. 1455 Implementation Notes: 1457 When choices are made from the list of Offered-Attributes, it is 1458 not required that any Security Association include every kind of 1459 offered attribute in any single SPI, or that a separate SPI be 1460 created for every offered attribute. 1462 Some kinds of attributes may be included more than once in a sin- 1463 gle SPI. The set of allowable combinations of attributes are 1464 dependent on implementation and operational policy. Such consid- 1465 erations are outside the scope of this document. + 1467 The list may be divided into additional sections. This can occur + 1468 only when both parties recognize the affected attributes. 1470 5.3. Shared-Secret 1472 A shared-secret is used in a number of calculations. Regardless of 1473 the internal representation of the shared-secret, when used in calcu- 1474 lations it is in the same form as the Value part of a Variable Preci- 1475 sion Integer: 1477 - most significant byte first. 1478 - bits used are right justified within byte boundaries. 1479 - any unused bits are in the most significant byte. 1480 - unused bits are zero filled. 1482 The shared-secret does not include a Size field. 1484 5.4. Identity Verification - 1486 These messages are authenticated using the Identity-Choice. The Ver- 1487 ification value is calculated prior to masking (and optional encryp- 1488 tion), and verified after unmasking (and optional decryption). 1490 The Identity-Choice authentication function is supplied with two 1491 input values: 1493 - the sender (SPI Owner) verification-key, 1494 - the data to be verified (as a concatenated sequence of bytes). 1496 The resulting output value is stored in the Verification field. 1498 The Identity-Choice verification data consists of the following con- 1499 catenated values: 1501 + the Initiator Cookie, 1502 + the Responder Cookie, 1503 + the Message, LifeTime and SPI fields, 1504 + the Identity-Choice and Identification, | 1505 + the SPI User Identity Verification (response only), | 1506 + the Attribute-Choices following the Verification field, | 1507 + the Padding, | 1508 + the SPI Owner TBV, | 1509 + the SPI Owner Exchange-Value, 1510 + the SPI Owner Offered-Attributes, 1511 + the SPI User TBV, | 1512 + the SPI User Exchange-Value, 1513 + the SPI User Offered-Attributes, 1514 + the Responder Offered-Schemes. | 1516 The TBV (Three Byte Value) consists of the Counter and Scheme-Choice | 1517 fields from the Value_Request, or the Reserved field from the | 1518 Value_Response, immediately preceding the associated Exchange-Value. | 1520 Note that the order of the Exchange-Value and Offered-Attributes | 1521 fields is different in each direction, and the Identification and SPI 1522 fields are also likely to be different in each direction. Note also 1523 that the SPI User Identity Verification (from the Identity_Request) 1524 is present only in the Identity_Response. 1526 If the verification fails, the users are notified, and a Verifica- 1527 tion_Failure message is sent, without adding any SPI. On success, 1528 normal operation begins with the authentication and/or encryption of 1529 user datagrams. 1531 Implementation Notes: 1533 This is distinct from any authentication method specified for the 1534 SPI. 1536 The exact details of the Identification and verification-key 1537 included in the Verification calculation are dependent on the 1538 Identity-Choice, as described in the "Basic Attributes". 1540 Each party may wish to keep their own trusted databases, such as 1541 the Pretty Good Privacy (PGP) web of trust, and accept only those 1542 identities found there. Failure to find the Identification in 1543 either an internal or external database results in the same Veri- 1544 fication_Failure message as failure of the verification computa- 1545 tion. 1547 The Exchange-Value data includes both the Size and Value fields. 1548 The Offered-Attributes and Attribute-Choices data includes the 1549 Attribute, Length and Value fields. 1551 5.5. Privacy-Key Computation 1553 Identification Exchange messages are masked using the Privacy-Method 1554 indicated by the current Scheme-Choice. Masking begins with the next 1555 field after the SPI, and continues to the end of the data indicated 1556 by the UDP Length, including the Padding. 1558 The Scheme-Choice specified Key-Generation-Function is used to create 1559 a special privacy-key for each message. This function is calculated 1560 over the following concatenated values: 1562 + the SPI Owner Exchange-Value, 1563 + the SPI User Exchange-Value, 1564 + the Initiator Cookie, 1565 + the Responder Cookie, 1566 + the Message, LifeTime and SPI (or Reserved) fields, 1567 + the computed shared-secret. 1569 Since the order of the Exchange-Value fields is different in each 1570 direction, and the Message, LifeTime and SPI fields are also differ- 1571 ent in each direction, the resulting privacy-key will usually be dif- 1572 ferent in each direction. 1574 When a larger number of keying-bits are needed than are available 1575 from one iteration of the specified Key-Generation-Function, more 1576 keying-bits are generated by duplicating the trailing shared-secret, 1577 and recalculating the function. That is, the first iteration will 1578 have one trailing copy of the shared-secret, the second iteration 1579 will have two trailing copies of the shared-secret, and so forth. 1581 Implementation Notes: 1583 This is distinct from any encryption method specified for the SPI. 1585 The length of the Padding, and other details, are dependent on the 1586 Privacy-Method. See the "Basic Privacy-Method" list for details. 1588 To avoid keeping the Exchange-Values in memory after the initial 1589 verification, it is often possible to pre-compute the function 1590 over the initial bytes of the concatenated data values for each 1591 direction, and append the trailing copies of the shared-secret. 1593 The Exchange-Value data includes both the Size and Value fields. 1595 5.6. Session-Key Computation 1597 Each SPI has one or more session-keys. These keys are generated 1598 based on the attributes of the SPI. See the "Basic Attributes" for 1599 details. 1601 The Scheme-Choice specified Key-Generation-Function is used to create 1602 the SPI session-key for that particular attribute. This function is 1603 calculated over the following concatenated values: 1605 + the Initiator Cookie, 1606 + the Responder Cookie, 1607 + the SPI Owner generation-key, 1608 + the SPI User generation-key, 1609 + the message Verification field, 1610 + the computed shared-secret. 1612 Since the order of the generation-keys is different in each direc- 1613 tion, and the Verification field is also likely to be different in 1614 each direction, the resulting session-key will usually be different 1615 in each direction. 1617 When a larger number of keying-bits are needed than are available 1618 from one iteration of the specified Key-Generation-Function, more 1619 keying-bits are generated by duplicating the trailing shared-secret, 1620 and recalculating the function. That is, the first iteration will 1621 have one trailing copy of the shared-secret, the second iteration 1622 will have two trailing copies of the shared-secret, and so forth. 1624 Implementation Notes: 1626 This is distinct from any privacy-key generated for the Photuris 1627 exchange. Different initialization data is used, and iterations 1628 are maintained separately. 1630 The exact details of the Verification field and generation-keys 1631 that are included in the session-key calculation are dependent on 1632 the Identity-Choices, as described in the "Basic Attributes". 1634 To avoid keeping the generation-keys in memory after the initial 1635 verification, it is often possible to pre-compute the function 1636 over the initial bytes of the concatenated data values for each 1637 direction, and append the trailing copies of the shared-secret. 1639 When both authentication and encryption attributes are used for 1640 the same SPI, there may be multiple session-keys associated with 1641 the same SPI. These session-keys are generated in the order of 1642 the Attribute-Choices list. 1644 6. SPI Messages 1646 SPI User SPI Owner 1647 ======== ========= 1648 SPI_Needed -> 1649 list SPI attribute(s) 1650 make validity key 1651 authenticate 1652 make privacy key(s) 1653 mask/encrypt message 1654 <- SPI_Update 1655 make SPI 1656 pick SPI attribute(s) 1657 make SPI session-key(s) 1658 make validity key 1659 authenticate 1660 make privacy key(s) 1661 mask/encrypt message 1663 The exchange of messages is not related to the Initiator and Respon- 1664 der. Instead, either party may send one of these messages at any 1665 time. The messages are easily distinguished by the parties. 1667 6.0.1. Send SPI_Needed 1669 At any time after completion of the Identification Exchange, either 1670 party can send SPI_Needed. This message is sent when a prospective 1671 SPI User needs particular attributes for a datagram (such as confi- 1672 dentiality), and no current SPI has those attributes. 1674 The prospective SPI User selects from the intersection of attributes 1675 that both parties have previously offered, calculates the Verifica- 1676 tion, and masks the message using the Privacy-Method indicated by the 1677 current Scheme-Choice. 1679 6.0.2. Receive SPI_Needed 1681 The potential SPI Owner validates the pair of Cookies, the Padding, 1682 the Verification, and the Attributes-Needed. 1684 - When an invalid/expired cookie is detected, a Bad_Cookie message | 1685 is sent. 1687 - When too many SPI values are already in use for this particular - 1688 peer, or some other resource limit is reached, a Resource_Limit 1689 message is sent. 1691 - After unmasking, when invalid Padding is detected, the variable | 1692 length Attributes-Needed do not match the UDP Length, or an | 1693 attribute was not in the Offered-Attributes, the message is 1694 silently discarded. 1696 - When the message verification fails, a Verification_Failure mes- + 1697 sage is sent. + 1699 - Whenever such a problem is detected, the SPI is not established; 1700 the implementation SHOULD log the occurance, and notify an opera- 1701 tor as appropriate. 1703 When the message is valid, the party SHOULD send SPI_Update with the 1704 necessary attributes. 1706 If an existing SPI has those attributes, that SPI is returned in the 1707 SPI_Update with the remaining SPILT. 1709 6.0.3. Send SPI_Update 1711 At any time after completion of the Identification Exchange, either 1712 party can send SPI_Update. This message has effect in only one 1713 direction, from the SPI Owner to the SPI User. 1715 The SPI Owner chooses the SPI and SPILT, a set of Attributes for the 1716 SPI, calculates the Verification, and masks the message using the 1717 Privacy-Method indicated by the current Scheme-Choice. 1719 6.0.4. Receive SPI_Update 1721 The prospective SPI User validates the pair of Cookies, the Padding, 1722 the Verification, and the Attributes-Needed. 1724 - When an invalid/expired cookie is detected, a Bad_Cookie message | 1725 is sent. 1727 - After unmasking, when invalid Padding is detected, the variable | 1728 length Attribute-Choices do not match the UDP Length, an attribute | 1729 was not in the Offered-Attributes, or the message modifies an 1730 existing SPI, the message is silently discarded. 1732 - When the message verification fails, a Verification_Failure mes- + 1733 sage is sent. + 1735 - Whenever such a problem is detected, the SPI is not established; 1736 the implementation SHOULD log the occurance, and notify an 1737 operator as appropriate. 1739 When the message is valid, further actions are dependent on the value 1740 of the LifeTime field, as described later. 1742 6.0.5. Automated SPI_Updates 1744 Each SPI requires replacement under several circumstances: 1746 - the volume of data processed (inhibiting probability cryptanaly- 1747 sis), 1749 - exhaustion of available anti-replay Sequence Numbers, 1751 - and expiration of the LifeTime. 1753 In general, a determination is made upon receipt of a datagram. If 1754 the transform specific processing finds that refreshment is needed, 1755 an automated SPI_Update is triggered. 1757 In addition, automated SPI_Updates allow rapid SPI refreshment for 1758 high bandwidth applications in a high delay environment. The update 1759 messages flow in the opposite direction from the primary traffic, 1760 conserving bandwidth and avoiding service interruption. 1762 When creating each SPI, the implementation MAY optionally set an 1763 Update TimeOut (UTO); by default, to half the value of the LifeTime 1764 (SPILT/2). This time is highly dynamic, and adjustable to provide an 1765 automated SPI_Update long before transform specific processing. If 1766 no new Photuris exchange occurs within the time limit, and the cur- 1767 rent exchange state has not expired, an automated SPI_Update is sent. 1769 6.1. SPI_Needed 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 | | 1773 ~ Initiator-Cookie ~ 1774 | | 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 | | 1777 ~ Responder-Cookie ~ 1778 | | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 | Message | Reserved-LT | 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 | Reserved-SPI | 1783 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1784 | | 1785 ~ Verification ~ 1786 | | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 | Attributes-Needed ... 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 ... Padding | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 Initiator-Cookie 16 bytes. Copied from the Value_Request. 1795 Responder-Cookie 16 bytes. Copied from the Value_Request. 1797 Message 8 1799 Reserved-LT 3 bytes. For future use; MUST be filled with a ran- 1800 dom non-zero value when transmitted, and MUST be 1801 ignored when received. 1803 Reserved-SPI 4 bytes. For future use; MUST be set to zero when 1804 transmitted, and MUST be ignored when received. 1806 Verification Variable Precision Integer, or other format indi- 1807 cated by the current Scheme-Choice. The calculation 1808 of the value is described in "Validity Verifica- 1809 tion". 1811 The field may be any integral number of bytes in 1812 length. It does not require any particular align- 1813 ment. The 32-bit alignment shown is for convenience 1814 in the illustration. 1816 Attributes-Needed 1817 4 or more bytes. A list of two or more attributes, 1818 selected from the list of Offered-Attributes sup- 1819 ported by the peer. 1821 The contents and usage of this list are as previ- 1822 ously described in "Attribute Choices List". The 1823 end of the list is indicated by the UDP Length after 1824 removing the Padding (UDP Length - last Padding 1825 value). 1827 Padding 8 or more bytes. The message is padded in the same 1828 fashion specified for Identification Exchange mes- 1829 sages. 1831 The portion of the message after the SPI field is masked using the 1832 Privacy-Method indicated by the current Scheme-Choice. 1834 The fields following the SPI are opaque. That is, the values are set 1835 prior to masking (and optional encryption), and examined only after 1836 unmasking (and optional decryption). 1838 6.2. SPI_Update 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 | | 1842 ~ Initiator-Cookie ~ 1843 | | 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1845 | | 1846 ~ Responder-Cookie ~ 1847 | | 1848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1849 | Message | LifeTime | 1850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1851 | Security-Parameters-Index | 1852 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1853 | | 1854 ~ Verification ~ 1855 | | 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 | Attribute-Choices ... 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 ... Padding | 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 Initiator-Cookie 16 bytes. Copied from the Value_Request. 1864 Responder-Cookie 16 bytes. Copied from the Value_Request. 1866 Message 9 1868 LifeTime 3 bytes. The number of seconds remaining before the 1869 indicated SPI expires. The value zero indicates 1870 deletion of the indicated SPI. 1872 Security-Parameters-Index (SPI) 1873 4 bytes. The SPI to be used for incoming communica- 1874 tions. 1876 This may be a new SPI value (for creation), or an 1877 existing SPI value (for deletion). The value zero 1878 indicates special processing. 1880 Verification Variable Precision Integer, or other format indi- 1881 cated by the current Scheme-Choice. The calculation 1882 of the value is described in "Validity Verifica- 1883 tion". 1885 The field may be any integral number of bytes in 1886 length. It does not require any particular align- 1887 ment. The 32-bit alignment shown is for convenience 1888 in the illustration. 1890 Attribute-Choices 1891 0 or more bytes. When the SPI and SPILT are non- 1892 zero, a list of attributes selected from the list of 1893 Offered-Attributes supported by the peer. 1895 The contents and usage of this list are as previ- 1896 ously described in "Attribute Choices List". The 1897 end of the list is indicated by the UDP Length after 1898 removing the Padding (UDP Length - last Padding 1899 value). 1901 Padding 8 or more bytes. The message is padded in the same 1902 fashion specified for Identification Exchange mes- 1903 sages. 1905 The portion of the message after the SPI field is masked using the 1906 Privacy-Method indicated by the current Scheme-Choice. 1908 The fields following the SPI are opaque. That is, the values are set 1909 prior to masking (and optional encryption), and examined only after 1910 unmasking (and optional decryption). 1912 6.2.1. Creation 1914 When the LifeTime is non-zero, and the SPI is also non-zero, the 1915 SPI_Update can be used to create a new SPI. When the SPI is zero, 1916 the SPI_Update is silently discarded. 1918 The new session-keys are calculated in the same fashion as the Iden- 1919 tity_Messages. Since the SPI value is always different than any pre- 1920 vious SPI during the Exchange LifeTime of the shared-secret, the 1921 resulting session-keys will necessarily be different from all others 1922 used in the same direction. 1924 No retransmission timer is necessary. Success is indicated by the 1925 peer use of the new SPI. 1927 Should all creation attempts fail, eventually the peer will find that 1928 all existing SPIs have expired, and will begin the Photuris exchange 1929 again by sending a new Cookie_Request. When appropriate, this 1930 Cookie_Request MAY include a Responder-Cookie to retain previous 1931 party pairings. 1933 6.2.2. Deletion 1935 When the LifeTime is zero, the SPI_Update can be used to delete a 1936 single existing SPI. When the SPI is also zero, the SPI_Update will 1937 delete all existing SPIs related to this Security Association, and 1938 mark the Photuris exchange state as expired. This is especially use- 1939 ful when the application that needed them terminates. 1941 No retransmission timer is necessary. This message is advisory, to 1942 reduce the number of ICMP Security Failures messages. 1944 Should any deletion attempts fail, the peer will learn that the 1945 deleted SPIs are invalid through the normal ICMP Security Failures 1946 messages, and will initiate a Photuris exchange by sending a new 1947 Cookie_Request. 1949 6.2.3. Modification 1951 The SPI_Update cannot be used to modify existing SPIs, such as 1952 lengthen an existing SPI LifeTime, resurrect an expired SPI, or 1953 add/remove an Attribute-Choice. 1955 On receipt, such an otherwise valid message is silently discarded. 1957 6.3. Validity Verification - 1959 These messages are authenticated using the Validity-Method indicated 1960 by the current Scheme-Choice. The Verification value is calculated 1961 prior to masking (and optional encryption), and verified after 1962 unmasking (and optional decryption). 1964 The Validity-Method authentication function is supplied with two 1965 input values: 1967 - the sender (SPI Owner) verification-key, 1968 - the data to be verified (as a concatenated sequence of bytes). 1970 The resulting output value is stored in the Verification field. 1972 The Validity-Method verification data consists of the following con- 1973 catenated values: 1975 + the Initiator Cookie, 1976 + the Responder Cookie, 1977 + the Message, LifeTime and SPI (or Reserved) fields, 1978 + the SPI Owner Identity Verification, 1979 + the SPI User Identity Verification, 1980 + the Attribute-Choices following the Verification field, 1981 + the Padding. 1983 Note that the order of the Identity Verification fields (from the 1984 Identity_Messages) is different in each direction, and the Message, 1985 LifeTime and SPI fields are also likely to be different in each 1986 direction. 1988 If the verification fails, the users are notified, and a Verifica- 1989 tion_Failure message is sent, without adding or deleting any SPIs. 1990 On success, normal operation begins with the authentication and/or 1991 encryption of user datagrams. 1993 Implementation Notes: 1995 This is distinct from any authentication method specified for the 1996 SPI. 1998 The Identity Verification data includes both the Size and Value 1999 fields. The Attribute-Choices data includes the Attribute, Length 2000 and Value fields. 2002 7. Error Messages 2004 These messages are issued in response to Photuris state loss or other 2005 problems. A message has effect in only one direction. No retrans- 2006 mission timer is necessary. 2008 These messages are not masked. 2010 The receiver checks the Cookies for validity. Special care MUST be 2011 taken that the Cookie pair in the Error Message actually match a pair 2012 currently in use, and that the protocol is currently in a state where 2013 such an Error Message might be expected. Otherwise, these messages 2014 could provide an opportunity for a denial of service attack. Invalid 2015 messages are silently discarded. 2017 7.1. Bad_Cookie 2019 For the format of the 33 byte message, see "Header Format". There 2020 are no additional fields. 2022 Initiator-Cookie 16 bytes. Copied from the offending message. 2024 Responder-Cookie 16 bytes. Copied from the offending message. 2026 Message 10 2028 This error message is sent when a Value_Request, Identity_Request, 2029 SPI_Needed, or SPI_Update is received, and the receiver specific 2030 Cookie is invalid or the associated exchange state has expired. 2032 During the Photuris exchange, when this error message is received, it 2033 has no immediate effect on the operation of the protocol phases. 2034 Later, when Retransmissions have been exceeded, and this error mes- 2035 sage has been received, the Initiator SHOULD begin the Photuris 2036 exchange again by sending a new Cookie_Request with the Responder- 2037 Cookie and Counter updated appropriately. 2039 When this error message is received in response to SPI_Needed, the 2040 exchange state SHOULD NOT be marked as expired, but the party SHOULD 2041 initiate a Photuris exchange by sending a new Cookie_Request. 2043 When this error message is received in response to SPI_Update, the 2044 exchange state SHOULD NOT be marked as expired, and no further action 2045 is taken. A new exchange will be initiated later when needed by the 2046 peer to send authenticated and/or encrypted data. 2048 Existing SPIs are not deleted. They expire normally, and are purged 2049 sometime later. 2051 7.2. Resource_Limit 2053 For the format of the 34 byte message, see "Cookie_Request". There 2054 are no additional fields. 2056 Initiator-Cookie 16 bytes. Copied from the offending message. 2058 Responder-Cookie 16 bytes. Copied from the offending message. 2060 Special processing is applied to a Cookie_Request. 2061 When the offending message Responder-Cookie and 2062 Counter were both zero, and an existing exchange has 2063 not yet been purged, this field is replaced with the 2064 Responder-Cookie from the existing exchange. 2066 Message 11 2068 Counter 1 byte. Copied from the offending message. 2070 When zero, the Responder-Cookie indicates the Ini- 2071 tiator of a previous exchange, or no previous 2072 exchange is specified. 2074 When non-zero, the Responder-Cookie indicates the 2075 Responder to a previous exchange. This value is set 2076 to the Counter from the corresponding 2077 Cookie_Response. 2079 This error message is sent when a Cookie_Request, Value_Request or 2080 SPI_Needed is received, and too many SPI values are already in use 2081 for that peer, or some other Photuris resource is unavailable. 2083 During the Photuris exchange, when this error message is received in 2084 response to a Cookie_Request or Value_Request, the implementation 2085 SHOULD double the retransmission timeout (as usual) for sending 2086 another Cookie_Request or Value_Request. Otherwise, it has no imme- 2087 diate effect on the operation of the protocol phases. Later, when 2088 Retransmissions have been exceeded, and this error message has been 2089 received, the Initiator SHOULD begin the Photuris exchange again by 2090 sending a new Cookie_Request with the Responder-Cookie and Counter 2091 updated appropriately. 2093 When this error message is received in response to SPI_Needed, the 2094 implementation SHOULD NOT send another SPI_Needed until one of the 2095 existing SPIs associated with this exchange is deleted or has 2096 expired. 2098 7.3. Verification_Failure 2100 For the format of the 33 byte message, see "Header Format". There 2101 are no additional fields. 2103 Initiator-Cookie 16 bytes. Copied from the offending message. 2105 Responder-Cookie 16 bytes. Copied from the offending message. 2107 Message 12 2109 This error message is sent when an Identity_Message, SPI_Needed or 2110 SPI_Update is received, and verification fails. 2112 When this error message is received, the implementation SHOULD log 2113 the occurance, and notify an operator as appropriate. However, 2114 receipt has no effect on the operation of the protocol. 2116 7.4. Message_Reject 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 | | 2120 ~ Initiator-Cookie ~ 2121 | | 2122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2123 | | 2124 ~ Responder-Cookie ~ 2125 | | 2126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2127 | Message | Bad-Message | Offset | 2128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 Initiator-Cookie 16 bytes. Copied from the offending message. 2132 Responder-Cookie 16 bytes. Copied from the offending message. 2134 Message 13 2136 Bad-Message 1 byte. Indicates the Message number of the offend- 2137 ing message. 2139 Offset 2 bytes. The number of bytes from the beginning of 2140 the offending message where the unrecognized field 2141 starts. The minimum value is 32. 2143 This error message is sent when an optional Message type is received 2144 that is not supported, or an optional format of a supported Message 2145 is not recognized. 2147 When this error message is received, the implementation SHOULD log 2148 the occurance, and notify an operator as appropriate. However, 2149 receipt has no effect on the operation of the protocol. 2151 8. Public Value Exchanges 2153 Photuris is based in principle on public-key cryptography, specifi- 2154 cally Diffie-Hellman key exchange. Exchange of public D-H Exchange- 2155 Values based on private-secret values results in a mutual shared- 2156 secret between the parties. This shared-secret can be used on its 2157 own, or to generate a series of session-keys for authentication and 2158 encryption of subsequent traffic. 2160 This document assumes familiarity with the Diffie-Hellman public-key 2161 algorithm. A good description can be found in [Schneier95]. 2163 8.1. Modular Exponentiation Groups 2165 The original Diffie-Hellman technique [DH76] specified modular expo- 2166 nentiation. A public-value is generated using a generator (g), 2167 raised to a private-secret exponent (x), modulo a prime (p): 2169 (g**x) mod p. 2171 When these public-values are exchanged between parties, the parties 2172 can calculate a shared-secret value between themselves: 2174 (g**xy) mod p. 2176 The generator (g) and modulus (p) are established by the Scheme- 2177 Choice (see the "Basic Exchange-Schemes" for details). They are 2178 offered in the Cookie_Response, and one pair is chosen in the 2179 Value_Request. 2181 The private exponents (x) and (y) are kept secret by the parties. 2182 Only the public-value result of the modular exponentiation with (x) 2183 or (y) is sent as the Initiator and Responder Exchange-Value. 2185 These public-values are represented in single Variable Precision 2186 Integers. The Size of these Exchange-Values will match the Size of 2187 the modulus (p). 2189 8.2. Moduli Selection 2191 Each implementation proposes one or more moduli in its Offered- 2192 Schemes. Every implementation MUST support up to 1024-bit moduli. 2194 For any particular Photuris node, these moduli need not change for 2195 significant periods of time; likely days or weeks. A background pro- 2196 cess can periodically generate new moduli. 2198 For 512-bit moduli, current estimates would provide 64 (pes- 2199 simistic) bit-equivalents of cryptographic strength. 2201 For 1024-bit moduli, current estimates would range from 80 (pes- 2202 simistic) through 98 (optimistic) bit-equivalents of cryptographic 2203 strength. 2205 These estimates are used when choosing moduli that are appropriate 2206 for the desired Security Parameter attributes. 2208 8.2.1. Bootstrap Moduli 2210 Each implementation is likely to use a fixed modulus during its boot- 2211 strap, until it can generate another modulus in the background. As 2212 the bootstrap modulus will be widely distributed, and reused whenever 2213 the machine reinitializes, it SHOULD be a "safe" prime (p = 2q+1) to 2214 provide the greatest long-term protection. 2216 Implementors are encouraged to generate their own bootstrap moduli, 2217 and to change bootstrap moduli in successive implementation releases. 2219 8.2.2. Learning Moduli 2221 As Photuris exchanges are initiated, new moduli will be learned from 2222 the Responder Offered-Schemes. The Initiator MAY cache these moduli 2223 for its own use. 2225 Before offering any learned modulus, the implementation MUST perform 2226 at least one iteration of probable primality verification. In this 2227 fashion, many processors will perform verification in parallel as 2228 moduli are passed around. 2230 When primality verification failures are found, the failed moduli 2231 SHOULD be retained for some (implementation dependent) period of 2232 time, to avoid re-learning and re-testing after subsequent exchanges. 2234 8.3. Generator Selection 2236 The generator (g) should be chosen such that the private-secret expo- 2237 nents will generate all possible public-values, evenly distributed 2238 throughout the range of the modulus (p), without cycling through a 2239 smaller subset. Such a generator is called a "primitive root" (which 2240 is trivial to find when p is "safe"). 2242 Only one generator (2) is required to be supported. 2244 Implementation Notes: 2246 One useful technique is to select the generator, and then limit 2247 the modulus selection sieve to primes with that generator: 2249 2 when p (mod 24) = 11. 2250 3 when p (mod 12) = 5. 2251 5 when p (mod 10) = 3 or 7. 2253 The required generator (2) improves efficiency in multiplication 2254 performance. It is usable even when it is not a primitive root, 2255 as it still covers half of the space of possible residues. 2257 8.4. Exponent Selection 2259 Each implementation generates a separate random private-secret expo- 2260 nent for each different modulus. Then, a D-H Exchange-Value is cal- 2261 culated for the given modulus, generator, and exponent. 2263 This specification recommends that the exponent length be at least 2264 twice the desired cryptographic strength of the longest session-key 2265 needed by the strongest offered-attribute. 2267 Based on the estimates in "Moduli Selection" (above): 2269 For 512-bit moduli, exponent lengths of 128 bits (or more) are 2270 recommended. 2272 For 1024-bit moduli, exponent lengths of 160 to 256 bits (or more) 2273 are recommended. 2275 Although the same exponent and Exchange-Value may be used with sev- 2276 eral parties whenever the same modulus and generator are used, the 2277 exponent SHOULD be changed at random intervals. A background process 2278 can periodically destroy the old values, generate a new random pri- 2279 vate-secret exponent, and recalculate the Exchange-Value. 2281 Implementation Notes: 2283 The size of the exponent is entirely implementation dependent, is 2284 unknown to the other party, and can be easily changed. 2286 Since these operations involve several time-consuming modular 2287 exponentiations, moving them to the "background" substantially 2288 improves the apparent execution speed of the Photuris protocol. 2289 It also reduces CPU loading sufficiently to allow a single pub- 2290 lic/private key-pair to be used in several closely spaced Photuris 2291 executions, when creating Security Associations with several dif- 2292 ferent nodes over a short period of time. 2294 Other pre-computation suggestions are described in [BGMW93, LL94, 2295 Rooij94]. 2297 8.5. Defective Exchange Values 2299 Some exponents do not qualify as secret. The exponent 0 will gener- 2300 ate the Exchange-Value 1, and the exponent 1 will generate the 2301 Exchange-Value g. Small exponents will be easily visible and SHOULD 2302 be avoided where: 2304 g**x < p. 2306 Depending on the structure of the moduli, certain exponents can be 2307 used for sub-group confinement attacks. For "safe" primes (p = 2308 2q+1), these exponents are p-1 and (p-1)/2, which will generate the 2309 Exchange-Values 1 and p-1 respectively. 2311 When an implementation chooses a random exponent, the resulting 2312 Exchange-Value is examined. If the Exchange-Value is represented in 2313 less than half the number of significant bits in the modulus, then a 2314 new random exponent MUST be chosen. 2316 For 512-bit moduli, Exchange-Values of 2**256 or greater are 2317 required. 2319 For 1024-bit moduli, Exchange-Values of 2**512 or greater are 2320 required. 2322 In addition, if the resulting Exchange-Value is p-1, then a new ran- 2323 dom exponent MUST be chosen. 2325 Upon receipt of an Exchange-Value that fails to meet the require- 2326 ments, the Value Exchange message is silently discarded. 2328 Implementation Notes: 2330 Avoidance of small exponents can be assured by setting at least 2331 one bit in the most significant half of the exponent. 2333 9. Basic Exchange-Schemes 2335 Initial values are assigned as follows: 2337 (0) Reserved. 2339 (1) Reserved. 2341 (2) Implementation Required. Any modulus (p) with a recommended 2342 generator (g) of 2. When the Exchange-Scheme Size is non-zero, 2343 the modulus is contained in the Exchange-Scheme Value field in 2344 the list of Offered-Schemes. 2346 An Exchange-Scheme Size of zero is invalid. 2348 Key-Generation-Function "MD5 Hash" | 2349 Privacy-Method "Simple Masking" | 2350 Validity-Method "MD5-IPMAC Check" | 2352 This combination of features requires a modulus with at least 2353 64-bits of cryptographic strength. 2355 (3) Exchange-Schemes 3 to 255 are intended for future well-known 2356 published schemes. 2358 (256) Exchange-Schemes 256 to 32767 are intended for vendor-specific 2359 unpublished schemes. Implementors wishing a number MUST 2360 request the number from the authors. 2362 (32768) 2363 Exchange-Schemes 32768 to 65535 are available for cooperating 2364 parties to indicate private schemes, regardless of vendor 2365 implementation. These numbers are not reserved, and are sub- 2366 ject to duplication. Other criteria, such as the IP Source and 2367 Destination of the Cookie_Request, are used to differentiate 2368 the particular Exchange-Schemes available. 2370 10. Basic Key-Generation-Function - 2371 10.1. MD5 Hash 2373 MD5 [RFC-1321] is used as a pseudo-random-function for generating the 2374 key(s). The key(s) begin with the most significant bits of the hash. 2375 MD5 is iterated as needed to generate the requisite length of key 2376 material. 2378 When an individual key does not use all 128-bits of the last hash, 2379 any remaining unused (least significant) bits of the last hash are 2380 discarded. When combined with other uses of key generation for the 2381 same purpose, the next key will begin with a new hash iteration. 2383 11. Basic Privacy-Method 2384 11.1. Simple Masking 2386 As described in "Privacy-Key Computation", sufficient privacy-key 2387 material is generated to match the message length, beginning with the 2388 next field after the SPI, and including the Padding. The message is 2389 masked by XOR with the privacy-key. 2391 12. Basic Validity-Method 2392 12.1. MD5-IPMAC Check 2394 As described in "Validity Verification", the Verification field value 2395 is the MD5 [RFC-1321] hash over the concatenation of 2397 MD5( key, keyfill, data, datafill, key, md5fill ) 2399 where the key is the computed verification-key. 2401 The keyfill and datafill use the same pad-with-length technique 2402 defined for md5fill. This padding and length is implicit, and does 2403 not appear in the datagram. 2405 The resulting Verification field is a 128-bit Variable Precision 2406 Integer (18 bytes including Size). When used in calculations, the + 2407 Verification data includes both the Size and Value fields. 2409 13. Basic Attributes 2411 Implementors wishing a number MUST request the number from the 2412 authors. Initial values are assigned as follows: 2414 Use Type 2415 - 0* padding 2416 - 1* AH-Attributes 2417 - 2+ ESP-Attributes | 2418 AEI 5* MD5-IPMAC | 2419 AEIX 255+ Organizational | 2421 A AH Attribute-Choice | 2422 E ESP Attribute-Choice | 2423 I Identity-Choice | 2424 X dependent on list location | 2425 + feature must be recognized even when not supported | 2426 * feature must be supported (mandatory) | 2428 Other attributes are specified in companion documents. 2430 13.1. Padding 2432 +-+-+-+-+-+-+-+-+ 2433 | Attribute | 2434 +-+-+-+-+-+-+-+-+ 2436 Attribute 0 2438 Each attribute may have value fields that are multiple bytes. To 2439 facilitate processing efficiency, these fields are aligned on inte- 2440 gral modulo 8 byte (64-bit) boundaries. 2442 Padding is accomplished by insertion of 1 to 7 Attribute 0 padding 2443 bytes before the attribute that needs alignment. 2445 No padding is used after the final attribute in a list. 2447 13.2. AH-Attributes 2449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2450 | Attribute | Length | 2451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2453 Attribute 1 2455 Length 0 2457 When a list of Attributes is specified, this Attribute begins the 2458 section of the list which applies to the Authentication Header (AH). 2460 13.3. ESP-Attributes 2462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2463 | Attribute | Length | PayloadType | 2464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2466 Attribute 2 2468 Length 1 2470 PayloadType 1 byte. Indicates the contents of the ESP Transform 2471 Data field, using the IP Next Header (Protocol) 2472 value. Up-to-date values of the IP Next Header 2473 (Protocol) are specified in the most recent 2474 "Assigned Numbers" [RFC-1700]. 2476 For example, when encrypting an entire IP datagram, 2477 this field will contain the value 4, indicating IP- 2478 in-IP encapsulation. 2480 When a list of Attributes is specified, this Attribute begins the 2481 section of the list which applies to the Encapsulating Security Pay- 2482 load (ESP). 2484 When listed as an Offered-Attribute, the PayloadType is set to 255. 2486 When selected as an Attribute-Choice, the PayloadType is set to the 2487 actual value to be used. 2489 13.4. MD5-IPMAC 2491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2492 | Attribute | Length | 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2495 Attribute 5 | 2497 Length 0 2499 Symmetric Identification + 2501 When selected as an Identity-Choice, the immediately following 2502 Identification field contains an unstructured Variable Precision 2503 Integer. Valid Identifications and symmetric secret-keys are pre- 2504 configured by the parties. 2506 There is no required format or content for the Identification 2507 value. The value may be a number or string of any kind. See "Use 2508 of Identification and Secrets" for details. 2510 The symmetric secret-key (as specified) is selected based on the 2511 contents of the Identification field. All implementations MUST 2512 support at least 62 bytes. The selected symmetric secret-key 2513 SHOULD provide at least 64-bits of cryptographic strength. 2515 As described in "Identity Verification", the Verification field 2516 value is the MD5 [RFC-1321] hash over the concatenation of: 2518 MD5( key, keyfill, data, datafill, key, md5fill ) 2520 where the key is the computed verification-key. 2522 The keyfill and datafill use the same pad-with-length technique 2523 defined for md5fill. This padding and length is implicit, and 2524 does not appear in the datagram. 2526 The resulting Verification field is a 128-bit Variable Precision 2527 Integer (18 bytes including Size). When used in calculations, the + 2528 Verification data includes both the Size and Value fields. 2530 For both "Identity Verification" and "Validity Verification", the 2531 verification-key is the MD5 [RFC-1321] hash of the following con- 2532 catenated values: 2534 + the symmetric secret-key, 2535 + the computed shared-secret. 2537 For "Session-Key Computation", the symmetric secret-key is used 2538 directly as the generation-key. 2540 Regardless of the internal representation of the symmetric secret- 2541 key, when used in calculations it is in the same form as the Value 2542 part of a Variable Precision Integer: 2544 - most significant byte first. 2545 - bits used are right justified within byte boundaries. 2546 - any unused bits are in the most significant byte. 2547 - unused bits are zero filled. 2549 The symmetric secret-key does not include a Size field. 2551 Authentication | 2553 May be selected as an AH or ESP Attribute-Choice, pursuant to 2554 [RFC-1828] et sequitur. The selected Exchange-Scheme SHOULD pro- 2555 vide at least 64-bits of cryptographic strength. 2557 As described in "Session-Key Computation", the most significant 2558 384-bits (48 bytes) of the Key-Generation-Function iterations are 2559 used for the key. 2561 Profile: - 2563 When negotiated with Photuris, the transform differs slightly 2564 from [RFC-1828]. 2566 The form of the authenticated message is: 2568 MD5( key, keyfill, datagram, datafill, key, md5fill ) 2570 where the key is the SPI session-key. 2572 The additional datafill protects against the (impractical) | 2573 attack described in [PO96]. The keyfill and datafill use the | 2574 same pad-with-length technique defined for md5fill. This 2575 padding and length is implicit, and does not appear in the 2576 datagram. 2578 13.5. Organizational 2580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2581 | Attribute | Length | OUI 2582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 ... | Kind | Value(s) ... 2584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2586 Attribute 255 2588 Length >= 4 2590 When the Length is four, no Value(s) field is pre- 2591 sent. 2593 OUI 3 bytes. The vendor's Organizationally Unique Iden- 2594 tifier, assigned by IEEE 802 or IANA (see [RFC-1700] 2595 for contact details). The bits within the byte are 2596 in canonical order, and the most significant byte is 2597 transmitted first. 2599 Kind 1 byte. Indicates a sub-type for the OUI. There is 2600 no standardization for this field. Each OUI imple- 2601 ments its own values. 2603 Value(s) 0 or more bytes. The details are implementation 2604 specific. 2606 Some implementors might not need nor want to publish their propri- 2607 etary algorithms and attributes. This OUI mechanism is available to 2608 specify these without encumbering the authors with proprietary number 2609 requests. 2611 A. Automaton 2613 An example automaton is provided to illustrate the operation of the 2614 protocol. It is incomplete and non-deterministic; many of the 2615 Good/Bad semantic decisions are policy-based or too difficult to rep- 2616 resent in tabular form. Where conflicts appear between this example 2617 and the text, the text takes precedence. 2619 The finite-state automaton is defined by events, actions and state 2620 transitions. Events include reception of external commands such as 2621 expiration of a timer, and reception of datagrams from a peer. 2622 Actions include the starting of timers and transmission of datagrams 2623 to the peer. 2625 Events 2627 DU13 = Communication Administratively Prohibited 2628 SF0 = Bad SPI 2629 SF4 = Need Authentication 2630 SF5 = Need Authorization 2631 WC = Want Confidentiality 2633 RCQ+ = Receive Cookie_Request (Good) 2634 RCQ- = Receive Cookie_Request (Bad) 2635 RCR+ = Receive Cookie_Response (Good) 2636 RCR- = Receive Cookie_Response (Bad) 2638 RVQ+ = Receive Value_Request (Good) 2639 RVQ- = Receive Value_Request (Bad) 2640 RVR+ = Receive Value_Response (Good) 2641 RVR- = Receive Value_Response (Bad) 2643 RIQ+ = Receive Identity_Request (Good) 2644 RIQ- = Receive Identity_Request (Bad) 2645 RIR+ = Receive Identity_Response (Good) 2646 RIR- = Receive Identity_Response (Bad) 2648 RUN+ = Receive SPI_Needed (Good) 2649 RUN- = Receive SPI_Needed (Bad) 2650 RUM+ = Receive SPI_Update (Good) 2651 RUM- = Receive SPI_Update (Bad) 2653 RBC = Receive Bad Cookie 2654 RRL = Receive Resource Limit 2655 RVF = Receive Verification Failure 2656 RMR = Receive Message Reject 2658 TO+ = Timeout with counter > 0 2659 TO- = Timeout with counter expired 2660 UTO = Update TimeOut 2661 XTO = Exchange TimeOut 2663 Actions 2665 scq = Send Cookie_Request 2666 scr = Send Cookie_Response 2668 svq = Send Value_Request 2669 svr = Send Value_Response 2671 siq = Send Identity_Request 2672 sir = Send Identity_Response 2674 sum = Send SPI_Update 2676 se* = Send error message (see text) 2677 sbc = Send Bad Cookie 2678 srl = Send Resource Limit 2679 svf = Send Verification Failure 2681 brto = Backoff Retransmission TimeOut 2682 buto = Backoff Update TimeOut 2683 rto = Set Retransmission TimeOut 2684 uto = Set Update TimeOut 2685 xto = Set Exchange TimeOut 2687 log = log operator message 2689 A.1. State Transition Table 2691 States are indicated horizontally, and events are read vertically. 2692 State transitions and actions are represented in the form action/new- 2693 state. Multiple actions are separated by commas, and may continue on 2694 succeeding lines as space requires; multiple actions may be imple- 2695 mented in any convenient order. The state may be followed by a let- 2696 ter, which indicates an explanatory footnote. The dash ('-') indi- 2697 cates an illegal transition. 2699 Initiator 2701 | 0 1 2 3 4 2702 | Initial Cookie CookieBad Value ValueBad 2703 ------+-------------------------------------------------- 2704 DU13 |rto,scq/1 rto,scq/1 rto,scq/1 3 4 2705 SF0 |rto,scq/1 1 2 3 4 2706 SF4 |rto,scq/1 1 2 3 4 2707 SF5 |rto,scq/1 1 2 3 4 2708 WC |rto,scq/1 1 2 3 4 2709 | 2710 RCR+ | - rto,svq/3 rto,svq/3 3 4 2711 RCR- | 0 1 2 3 4 2712 RVR+ | - - - rto,siq/5 rto,siq/5 2713 RVR- | 0 1 2 3 4 2714 RIR+ | - - - - - 2715 RIR- | 0 1 2 3 4 2716 | 2717 RUN+ | - - - - - 2718 RUN- | sbc/0 sbc/1 sbc/2 sbc/3 sbc/4 2719 RUM+ | - - - - - 2720 RUM- | sbc/0 sbc/1 sbc/2 sbc/3 sbc/4 2721 | 2722 RBC | - - - 4 4 2723 RRL | - brto/2 brto/2 brto/4 brto/4 2724 RVF | - - - - - 2725 RMR | - - - - - 2726 | 2727 TO+ | - scq/1 scq/2 svq/3 svq/4 2728 TO- | - 0 scq/1 0 scq/1 2729 UTO | - - - - - 2730 XTO | - 0 0 0 0 2732 Initiator 2734 | 5 6 8 2735 |Identity IdentityBad Update 2736 ------+----------------------------- 2737 DU13 | 5 6 8 2738 SF0 | 5 6 rto,scq/1 2739 SF4 | 5 6 rto,scq/1 2740 SF5 | 5 6 rto,scq/1 2741 WC | 5 6 sun/8 2742 | 2743 RCR+ | 5 6 8 2744 RCR- | 5 6 8 2745 RVR+ | 5 6 8 2746 RVR- | 5 6 8 2747 RIR+ | uto/8 uto/8 8 2748 RIR- | svf/5 svf/6 8 2749 | 2750 RUN+ | - - sum/8 2751 RUN- | sbc/5 sbc/6 se*/8 2752 RUM+ | - - 8 2753 RUM- | sbc/5 sbc/6 se*/8 2754 | 2755 RBC | 6 6 rto,scq/1 2756 RRL | 5 6 buto/8 2757 RVF | log/5 log/6 log/8 2758 RMR | log/5 log/6 log/8 2759 | 2760 TO+ | sim/5 sim/6 - 2761 TO- | 0 scq/1 - 2762 UTO | - - sum/8 2763 XTO | 0 0 0 2765 Responder 2767 | 0 7 8 2768 | Initial Ready Update 2769 ------+----------------------------- 2770 WC | - 7 sun/8 2771 | 2772 RCQ+ | scr/0 scr/7 scr/8 2773 RCQ- | srl/0 srl/7 srl/8 2774 RVQ+ |xto,svr/7 svr/7 svr/8 2775 RVQ- | sbc/0 sbc/7 sbc/8 2776 RIQ+ | - uto,sir/8 sir/8 2777 RIQ- | sbc/0 se*/7 se*/8 2778 | 2779 RUN+ | - - sum/8 2780 RUN- | sbc/0 sbc/7 se*/8 2781 RUM+ | - - 8 2782 RUM- | sbc/0 sbc/7 se*/8 2783 | 2784 RBC | - 7 rto,scq/1 2785 RRL | - - buto/8 2786 RVF | - - log/8 2787 RMR | - - log/8 2788 | 2789 UTO | - - sum/8 2790 XTO | - 0 0 2792 A.2. States 2794 Following is a more detailed description of each automaton state. 2796 The "Bad" version of a state is to indicate that the Bad_Cookie or 2797 Resource_Limit message has been received. 2799 A.2.1. Initial 2801 The Initial state is fictional, in that there is no state between the 2802 parties. 2804 A.2.2. Cookie 2806 In the Cookie state, the Initiator has sent a Cookie_Request, and is 2807 waiting for a Cookie_Response. Both the Restart and Exchange timers 2808 are running. 2810 Note that the Responder has no Cookie state. 2812 A.2.3. Value 2814 In the Value state, the Initiator has sent its Exchange-Value, and is 2815 waiting for an Identity_Message. Both the Restart and Exchange 2816 timers are running. 2818 A.2.4. Identity 2820 In the Identity state, the Initiator has sent an Identity_Request, 2821 and is waiting for an Identity_Response in reply. Both the Restart 2822 and Exchange timers are running. 2824 A.2.5. Ready 2826 In the Ready state, the Responder has sent its Exchange-Value, and is 2827 waiting for an Identity_Message. The Exchange timer is running. 2829 A.2.6. Update 2831 In the Update state, each party has concluded the Photuris exchange, 2832 and is unilaterally updating expiring SPIs until the Exchange Life- 2833 Time expires. Both the Update and Exchange timers are running. 2835 B. Use of Identification and Secrets 2837 Implementation of the base protocol requires support for operator 2838 configuration of participant identities and associated symmetric 2839 secret-keys. 2841 The form of the Identification and Secret fields is not constrained 2842 to be a readable string. In addition to a simpler quoted string con- 2843 figuration, an implementation MUST allow configuration of an arbi- 2844 trary stream of bytes. 2846 B.1. Identification 2848 Typically, the Identification is a user name, a site name, a Fully 2849 Qualified Domain Name, or an email address which contains a user name 2850 and a domain name. Examples include: 2852 user 2853 node.site. 2854 user@node.site. 2855 rcmd@node.site. 2856 "Mundane Name" 2858 There is no requirement that the domain name match any of the partic- 2859 ular IP addresses in use by the parties. 2861 B.2. Group Identity With Group Secret 2863 A simple configuration approach could use a single Identity and 2864 Secret, distributed to all the participants in the trusted group. 2865 This might be appropriate between routers under a single administra- 2866 tion comprising a Virtual Private Network over the Internet. 2868 Nota Bene: 2869 The passwords used in these examples do not meet the "MD5-IPMAC 2870 Symmetric Identification" recommendation for at least 64-bits of 2871 cryptographic strength. 2873 The administrator configures each router with the same username and 2874 password: 2876 identity local "Tiny VPN 1995 November" "abracadabra" 2877 identity remote "Tiny VPN 1995 November" "abracadabra" 2879 When the Initiator sends its Identity_Request, the SPI Owner Identi- 2880 fication field is "Tiny VPN 1995 November" and the SPI Owner secret- 2881 key is "abracadabra". 2883 When the Responder sends its Identity_Response, the SPI Owner Identi- 2884 fication field is "Tiny VPN 1995 November" and the SPI Owner secret- 2885 key is "abracadabra". The SPI User Identification is "Tiny VPN 1995 2886 November" (taken from the request), and the SPI User secret-key is 2887 "abracadabra". 2889 Note that even in the face of implementations with very poor random 2890 number generation yielding the same random numbers for both parties 2891 at every step, and with this completely identical configuration, the 2892 addition of the SPI User Verification field in the response calcula- 2893 tion is highly likely to produce a different Verification value (see 2894 "Identity Verification"). In turn, the different Verification values 2895 affect the calculation of SPI session-keys that are highly likely to 2896 be different in each direction (see "Session-Key Computation"). 2898 B.3. Multiple Identities With Group Secrets 2900 A more robust configuration approach could use a separate Identity 2901 and Secret for each party, distributed to the participants in the 2902 trusted group. This might be appropriate for authenticated firewall | 2903 traversal. 2905 An administrator has one or more networks, and a number of mobile 2906 users. It is desirable to restrict access to authorized external 2907 users. The example boundary router is 10.0.0.1. | 2909 The administrator gives each user a different username and password, 2910 together with a group username and password for the router. 2912 The administrator configures (in part): 2914 identity local "199511@router.site" "FalDaRah" 2915 identity remote "Happy_Wanderer@router.site" "FalDaRee" 2917 Each mobile user adds commands to tunnel and authenticate. 2919 route addprivate 10.0.0.0/8 tunnel 10.0.0.1 2920 secure 10.0.0.1 authenticate-only 2921 identity local "Happy_Wanderer@router.site" "FalDaRee" 2922 identity remote "199511@router.site" "FalDaRah" 2923 identity remote "199512@router.site" "FalDaHaHaHaHaHaHa" 2925 When the mobile Initiator sends its Identity_Request, the SPI Owner 2926 Identification field is "Happy_Wanderer@router.site" and the SPI 2927 Owner secret-key is "FalDaRee". 2929 When the firewall Responder sends its Identity_Response, the SPI 2930 Owner Identification field is "199511@router.site" and the SPI Owner 2931 secret-key is "FalDaRah". The SPI User Identification field is 2932 "Happy_Wanderer@router.site" (taken from the request), and the SPI 2933 User secret-key is "FalDaRee". 2935 In this example, the mobile user is already prepared for a monthly 2936 password changeover, where the router might identify itself as 2937 "199512@router.site". 2939 B.4. Multiple Identities With Multiple Secrets 2941 Greater security might be achieved through configuration of a pair of 2942 secrets between each party. As before, one secret is used for ini- 2943 tial contact to any member of the group, but another secret is used 2944 between specific parties. Compromise of one secret or pair of 2945 secrets does not affect any other member of the group. This might be 2946 appropriate between the routers forming a boundary between cooperat- 2947 ing Virtual Private Networks that establish local policy for each VPN 2948 member access. 2950 One administrator configures: 2952 identity local "Apple" "all for one" 2953 identity local "Apple-Baker" "Apple to Baker" "Baker" 2954 identity remote "Baker" "one for all" 2955 identity remote "Baker-Apple" "Baker to Apple" 2957 Another configures: 2959 identity local "Baker" "one for all" 2960 identity local "Baker-Apple" "Baker to Apple" "Apple" 2961 identity remote "Apple" "all for one" 2962 identity remote "Apple-Baker" "Apple to Baker" 2964 When the Initiator sends its Identity_Request, the SPI Owner Identi- 2965 fication field is "Apple" and the SPI Owner secret-key is "all for 2966 one". 2968 When the Responder sends its Identity_Response, finding that the spe- 2969 cial pairing exists for "Apple" (in this example, indicated by a 2970 third field), the SPI Owner Identification field is "Baker-Apple" and 2971 the SPI Owner secret-key is "Baker to Apple". The SPI User Identifi- 2972 cation is "Apple" (taken from the request), and the SPI User secret- 2973 key is "all for one". 2975 Operational Considerations 2977 The specification provides only a few configurable parameters, with 2978 defaults that should satisfy most situations. 2980 Retransmissions 2981 Default: 3. 2983 Initial Retransmission TimeOut (IRTO) 2984 Default: 5 seconds. 2986 Exchange TimeOut (ETO) 2987 Default: 30 seconds. Minimum: Retransmissions * IRTO. 2989 Exchange LifeTime (ELT) 2990 Default: 30 minutes. Minimum: 2 * ETO. 2992 SPI LifeTime (SPILT) 2993 Default: 5 minutes. Minimum: 3 * ETO. 2995 Each party configures a list of known identities and symmetric 2996 secret-keys. 2998 In addition, each party configures local policy that determines what 2999 access (if any) is granted to the holder of a particular identity. 3000 For example, the party might allow anonymous FTP, but prohibit Tel- 3001 net. Such considerations are outside the scope of this document. 3003 Security Considerations 3005 Photuris was based on currently available tools, by experienced net- 3006 work protocol designers with an interest in cryptography, rather than 3007 by cryptographers with an interest in network protocols. This speci- 3008 fication is intended to be readily implementable without requiring an 3009 extensive background in cryptology. 3011 Therefore, only minimal background cryptologic discussion and ratio- 3012 nale is included in this document. Although some review has been 3013 provided by the general cryptologic community, it is anticipated that 3014 design decisions and tradeoffs will be thoroughly analysed in subse- 3015 quent dissertations and debated for many years to come. 3017 Cryptologic details are reserved for separate documents that may be 3018 more readily and timely updated with new analysis. 3020 History 3022 The initial specification of Photuris, now called version 1 (December 3023 1994 to March 1995), was based on a short list of design require- 3024 ments, and simple experimental code by Phil Karn. Only one modular 3025 exponentiation form was used, with a single byte index of pre- 3026 specified group parameters. The transform attributes were selected 3027 during the public value exchange. Party privacy was protected in the 3028 identification signature exchange with standard ESP transforms. 3030 Upon submission for review by the IP Security Working Group, a large 3031 number of features were demanded. A mere 254 future group choices 3032 were not deemed enough, was expanded to two bytes (and renamed 3033 schemes), and was expanded again to carry variable parameters. The 3034 transform attributes were made variable length to accomodate optional 3035 parameters. Every other possible parameter was made negotiable. 3036 Some participants were unable to switch modes on the UDP sockets to 3037 use standard ESP transforms for only some messages, and party privacy 3038 was integrated into the protocol. The message headers were reorga- 3039 nized, and selection of transform attributes was delayed until the 3040 identification exchange. An additional update message phase was 3041 added. 3043 Version 2 (July 1995 to December 1995) specification stability was 3044 achieved in November 1995 by moving most parameters into separate 3045 documents for later discussion, and leaving only a few mandatory fea- 3046 tures in the base specification. Within a month, multiple interoper- 3047 able implementations were produced. 3049 Unfortunately, in a fit of demagoguery, the IP Security Working Group 3050 decided in a straw poll to remove party privacy protection, and the 3051 Working Group chair terminated the meeting without allowing further 3052 discussion. Because the identification exchange messages required 3053 privacy to function correctly, the messages were reorganized again. 3054 Party privacy and other optional schemes were split into a separate 3055 document. 3057 The implementors established a separate discussion group. Version 3 3058 (April 1996 to June 1997) enjoyed a long period of specification sta- 3059 bility and multiple implementations on half a dozen platforms. 3061 Meanwhile, the IP Security Working Group has developed a competing 3062 specification with large numbers of negotiable parameters. Also, the 3063 PPP Extensions Working Group has deployed link security transforms. 3065 Version 4 (July 1997 onward) attempts to maintain a semblance of 3066 interface compatibility with these other efforts. Minor changes are 3067 specified in transform padding format and key generation. More than 3068 one value is permitted per scheme, giving greater latitude in choice 3069 for future extensions. The opportunity is taken to return party pri- 3070 vacy to the base document, and make small semantic changes in auto- 3071 mated updates and error recovery. All ESP transform attributes are 3072 moved to separate documents, to (hopefully) avoid future incompatible 3073 changes to the base document. 3075 Acknowledgements 3077 Thou shalt make no law restricting the size of integers that may 3078 be multiplied together, nor the number of times that an integer 3079 may be multiplied by itself, nor the modulus by which an integer 3080 may be reduced. [Prime Commandment] 3082 Phil Karn was principally responsible for the design of the protocol 3083 phases, particularly the "cookie" anti-clogging defense, developed 3084 the initial testing implementation, and provided much of the design 3085 rationale text (now removed to a separate document). 3087 William Simpson was responsible for the packet formats and 3088 attributes, additional message types, editing and formatting. All 3089 such mistakes are his responsibility. 3091 This protocol was later discovered to have many elements in common 3092 with the Station-To-Station authentication protocol [DOW92]. 3094 Angelos Keromytis developed the first completely independent imple- 3095 mentation (circa October 1995). Also, he suggested the cookie 3096 exchange rate limitation counter. 3098 Paul C van Oorschot suggested signing both the public exponents and 3099 the shared-secret, to provide an authentication-only version of iden- 3100 tity verification. Also, he provided text regarding moduli, genera- 3101 tor, and exponent selection (now removed to a separate document). 3103 Hilarie Orman suggested adding secret "nonces" to session-key genera- 3104 tion for asymmetric public/private-key identity methods (now removed 3105 to a separate document), and provided extensive review of the proto- 3106 col details. 3108 Bart Preneel and Paul C van Oorschot in [PO96] recommended padding | 3109 between the data and trailing key when hashing for authentication. 3111 Niels Provos developed another independent implementation (circa May | 3112 1997), ported to AIX, Linux, OpenBSD, and Solaris. Also, he made | 3113 suggestions regarding automated update, and listing multiple moduli 3114 per scheme. 3116 Bill Sommerfeld suggested including the authentication symmetric 3117 secret-keys in the session-key generation, and using the Cookie val- 3118 ues on successive exchanges to provide bi-directional user-oriented 3119 keying (now removed to a separate document). 3121 Oliver Spatscheck developed the second independent implementation 3122 (circa December 1995) for the Xkernel. 3124 International interoperability testing between early implementors 3125 provided the impetus for many of the implementation notes herein, and 3126 numerous refinements in the semantics of the protocol messages. 3128 Randall Atkinson, Steven Bellovin, Wataru Hamada, James Hughes, Brian 3129 LaMacchia, Cheryl Madson, Lewis McCarthy, Perry Metzger, Bob Quinn, 3130 Ron Rivest, Rich Schroeppel, and Norman Shulman provided useful cri- 3131 tiques of earlier versions of this document. 3133 References 3135 [BGMW93] E. Brickell, D. Gordon, K. McCurley, and D. Wilson, "Fast 3136 Exponentiation with Precomputation (Extended Abstract)", 3137 Advances in Cryptology -- Eurocrypt '92, Lecture Notes in 3138 Computer Science 658 (1993), Springer-Verlag, 200-207. 3140 Also U.S. Patent #5,299,262, E.F. Brickell, D.M. Gordon, 3141 K.S. McCurley, "Method for exponentiating in crypto- 3142 graphic systems", 29 Mar 1994. 3144 [DH76] Diffie, W., and Hellman, H.E., "New Directions in Cryp- 3145 tography", IEEE Transactions on Information Theory, v 3146 IT-22 n 6 pp 644-654, November 1976. 3148 [DOW92] Whitfield Diffie, Paul C van Oorshot, and Michael J 3149 Wiener, "Authentication and Authenticated Key Exchanges", 3150 Designs, Codes and Cryptography, v 2 pp 107-125, Kluwer 3151 Academic Publishers, 1992. 3153 [Firefly] "Photuris" is the latin name for the firefly. "Firefly" 3154 is in turn the name for the USA National Security Admin- 3155 istration's (classified) key exchange protocol for the 3156 STU-III secure telephone. Informed speculation has it 3157 that Firefly is based on very similar design principles. 3159 [LL94] Lim, C.H., Lee, P.J., "More flexible exponentiation with 3160 precomputation", Advances in Cryptology -- Crypto '94, 3161 Lecture Notes in Computer Science 839 (1994), Springer- 3162 Verlag, pages 95-107. 3164 [Prime Commandment] 3165 A derivation of an apocryphal quote from the usenet list 3166 sci.crypt. 3168 [PO96] Bart Preneel, and Paul C van Oorshot, "On the security of 3169 two MAC algorithms", Advances in Cryptology -- Eurocrypt 3170 '96, Lecture Notes in Computer Science 1070 (May 1996), 3171 Springer-Verlag, pages 19-32. 3173 [RFC-768] Postel, J., "User Datagram Protocol", STD 6, August 1980. 3175 [RFC-791] 3177 [RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC-1321, 3178 MIT Laboratory for Computer Science, April 1992. 3180 [RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, 3181 USC/Information Sciences Institute, October 1994. 3183 [RFC-1812] Baker, F., Editor, "Requirements for IP Version 4 3184 Routers", Cisco Systems, June 1995. 3186 [RFC-1828] Metzger, P., Simpson, W., "IP Authentication using Keyed 3187 MD5", July 1995. 3189 [RFC-1829] Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC 3190 Transform", July 1995. 3192 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 3193 Requirement Levels", BCP 14, Harvard University, March 3194 1997. 3196 [RFC-xxxx] Karn, P., and Simpson, W., "ICMP Security Failures Mes- 3197 sages", draft-simpson-icmp-ipsec-fail-02.txt, work in 3198 progress. 3200 [Rooij94] P. de Rooij, "Efficient exponentiation using precomputa- 3201 tion and vector addition chains", Advances in Cryptology 3202 -- Eurocrypt '94, Lecture Notes in Computer Science, 3203 Springer-Verlag, pages 403-415. 3205 [Schneier95] 3206 Schneier, B., "Applied Cryptography Second Edition", John 3207 Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. 3209 Contacts 3211 Comments about this document should be discussed on the pho- 3212 turis@adk.gr mailing list. 3214 Questions about this document can also be directed to: 3216 Phil Karn 3217 Qualcomm, Inc. 3218 6455 Lusk Blvd. 3219 San Diego, California 92121-2779 3221 karn@qualcomm.com 3222 karn@unix.ka9q.ampr.org (preferred) 3224 William Allen Simpson 3225 DayDreamer 3226 Computer Systems Consulting Services 3227 1384 Fontaine 3228 Madison Heights, Michigan 48071 3230 wsimpson@UMich.edu 3231 wsimpson@GreenDragon.com (preferred) 3233 Full Copyright Statement 3235 Copyright (C) Philip Karn and William Allen Simpson (1994-1998). All 3236 Rights Reserved. 3238 This document and translations of it may be copied and furnished to 3239 others, and derivative works that comment on or otherwise explain it 3240 or assist in its implementation may be prepared, copied, published 3241 and distributed, in whole or in part, without restriction of any 3242 kind, provided that the above copyright notice and this paragraph are 3243 included on all such copies and derivative works. However, this doc- 3244 ument itself may not be modified in any way, except as required to 3245 translate it into languages other than English. 3247 This document and the information contained herein is provided on an 3248 "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR 3249 IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF 3250 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3251 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.