idnits 2.17.1 draft-simpson-photuris-secret-01.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-03-29) 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. 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 (March 1999) is 9146 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DayDreamer' is mentioned on line 2, but not defined == Unused Reference: 'RFC-2510' is defined on line 981, but no explicit reference was found in the text == Unused Reference: 'RFC-2511' is defined on line 983, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2440 (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210) ** Obsolete normative reference: RFC 2511 (Obsoleted by RFC 4211) ** Downref: Normative reference to an Experimental RFC: RFC 2522 ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2537 (Obsoleted by RFC 3110) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier95' Summary: 17 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W A Simpson 2 Internet Draft [DayDreamer] 3 expires in six months March 1999 5 Photuris: Secret Exchange 6 draft-simpson-photuris-secret-01.txt (B) 8 Status of this Memo 10 This document is an Internet Draft, and is in full conformance with 11 all provisions of Section 10 of RFC2026, except that the right to 12 produce derivative works is not granted. 14 Internet Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its Areas, and its Working Groups. Note that 16 other groups may also distribute working documents as Internet 17 Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months, and may be updated, replaced, or obsoleted by other documents 21 at any time. It is not appropriate to use Internet Drafts as 22 reference material, or to cite them other than as "Work In Progress." 24 The list of current Internet Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 To view the list of Internet Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Note that the first paragraph of this section is a meaningless 33 bureaucratic requirement of the IESG. It is provided so as to 34 satisfy those bureaucratic requirements, and serves no other purpose 35 whatever. No assumption should be made that the author(s) have 36 assented to any of it. 38 Information as to any intellectual property rights, beyond the right 39 to redistribute this document and make use of it for the purposes of 40 an Internet Draft, should be sought in other parts of this document. 42 Distribution of this memo is unlimited. 44 Copyright Notice 46 Copyright (C) William Allen Simpson (1995,1998-1999). All Rights 47 Reserved. 49 Abstract 51 Photuris is a session-key management protocol. Extensible Messages 52 are provided to enable future implementation changes without 53 affecting the basic protocol. 55 The Secret Exchange messages provide the capability to create 56 ephemeral symmetric secrets between parties. 58 1. Introduction 60 The packet format and basic facilities are already defined for 61 Photuris [RFC-2522]. 63 In addition to establishing session-keys, Photuris is easily capable 64 of generating high quality unpredictable secrets. This facility can 65 be useful to augment or expand lower quality user passwords, and to 66 substitute for computationally expensive public-key operations. 68 Existing identities are exchanged between the parties, and new 69 identities with symmetric secrets are created. Upon successful 70 completion of the Photuris exchange, the existing access permissions 71 and other delegated authorizations are associated with the 72 corresponding substitute identities. 74 1.1. Terminology 76 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 77 "recommended", "required", "SHOULD", and "SHOULD NOT", are to be 78 interpreted as described in [RFC-2119]. 80 nonce A value that is not used more than once for the same 81 purpose. The value is recommended to be generated 82 by a cryptographically random method, which may be 83 concatenated with a timestamp or sequence number. 85 Party Secret Index (PSI) 86 A number that indicates a particular symmetric 87 secret. The value is recommended to be generated by 88 a cryptographically random method. 90 The use of this value is orthogonal to usage of 91 similar values by other related security protocols, 92 such as the Security-Parameters-Index (SPI). That 93 is, the same value MAY be used by multiple protocols 94 to concurrently indicate different Security 95 Association parameters. 97 1.2. LifeTimes 99 Each PSI identity and secret has an associated LifeTime, specified by 100 the PSI Owner (sender). This PSI LifeTime (PSILT) is usually long- 101 lived (typically 4 to 8 weeks), but it MUST NOT be greater than the 102 lifetime of original identity used in its creation. 104 There is no requirement that a long LifeTime be accepted by the PSI 105 User. A PSI identity may be used only for the current Photuris 106 exchange, or be purged at any time. 108 Whenever a new PSI identity is established, a common implementation 109 technique is to immediately expire all previous identities associated 110 with the same pair of original identities. However, selecting 111 randomly among several PSIs to expire might provide some defense 112 against traffic analysis. 114 When a PSI identity expires (or is replaced by a newer value), 115 existing Photuris exchanges and any unexpired derived SPIs are not 116 affected. 118 Although PSI identities and secrets can be stored in an external 119 database in the same manner as other long-lived identities and 120 secrets, care MUST be taken that PSI identities and secrets are 121 purged as they expire, and are not retained in backup storage. The 122 paranoid operator might store the data in a memory-only cryptographic 123 file system. 125 1.3. Value Exchange Parameter Selection 127 Photuris exchanges employing the Secret Exchange MUST select Value 128 Exchange parameters with at least the equivalent cryptographic 129 strength of the identities that will be utilized. Later exchanges 130 MAY use less strength to reduce computational cost, relying on the 131 quality of the PSI secrets for protection. 133 Implementations enjoying party privacy protection SHOULD select the 134 greatest cryptographic strength available. This inhibits discovery 135 and linking of the original identities of the parties with the 136 substitute PSI identities in later exchanges. 138 2. Secret Exchange 140 The Secret Exchange will occur following the usual Value Exchange: 142 Initiator Responder 143 ========= ========= 144 Cookie_Request -> 145 <- Cookie_Response 146 Value_Request -> 147 <- Value_Response 149 [generate shared-secret from exchanged values] 151 Frequently, the Secret Exchange will occur before the Identification 152 Exchange: 154 Initiator Responder 155 ========= ========= 156 Secret_Request -> 157 make PSI 158 identify self 159 authenticate 160 make privacy key(s) 161 mask/encrypt message 162 <- Secret_Response 163 make PSI 164 identify self 165 generate nonce 166 authenticate 167 make privacy key(s) 168 mask/encrypt message 169 Identity_Request -> 170 make SPI 171 pick SPI attribute(s) 172 generate nonce 173 authenticate 174 make privacy key(s) 175 mask/encrypt message 177 [make PSI secret-keys in each direction] 179 <- Identity_Response 181 [make SPI session-keys in each direction] 183 Alternatively, the Secret Exchange can occur in the middle of the 184 Identification Exchange: 186 Initiator Responder 187 ========= ========= 188 Identity_Request -> 189 <- Secret_Request 190 Secret_Response -> 192 [make PSI secret-keys in each direction] 194 <- Identity_Response 196 [make SPI session-keys in each direction] 198 The exchange of messages is ordered, although the formats and 199 meanings of the messages are similar in each direction. The messages 200 are easily distinguished by the parties themselves, by examining the 201 Message and Identification fields. 203 Nota Bene: A Secret_Request may be sent by either the Initiator or 204 Responder. The terms Primary and Secondary are used for the Secret 205 Exchange parties. 207 2.0.1. Send Secret_Request 209 The Primary chooses an appropriate Identification, the PSI and 210 PSILT, calculates the Verification, and masks the message using the 211 Privacy-Method indicated by the current Scheme-Choice. 213 The Primary also starts a retransmission timer. If no valid 214 Secret_Response arrives within the time limit, its previous 215 Secret_Request is retransmitted for the remaining number of 216 Retransmissions. 218 When Retransmissions have been exceeded, if a Bad_Cookie message has 219 been received during the exchange, the Primary SHOULD begin the 220 Photuris exchange again by sending a new Cookie_Request. 222 2.0.2. Receive Secret_Request 224 The Secondary validates the pair of Cookies, the Padding, the 225 Verification, and the Identification. 227 - When an invalid/expired cookie is detected, a Bad_Cookie message 228 is sent. 230 - After unmasking, when invalid Padding is detected, or the 231 Verification format is invalid, the message is silently discarded. 233 - When the message verification fails, or an invalid Identification 234 format is detected, or external signature validation fails, or 235 other authorization policy failures are indicated, a 236 Verification_Failure message is sent. 238 - Whenever such a problem is detected, the Security Association is 239 not established; the implementation SHOULD log the occurance, and 240 notify an operator as appropriate. 242 When the message is valid, the Secondary returns a Secret_Response. 244 The Secondary keeps a copy of the incoming Secret_Request values, and 245 its Secret_Response. If a duplicate Secret_Request is received, it 246 merely resends its previous Secret_Response, and takes no further 247 action. 249 Implementation Notes: 251 Validation of message formats MUST take place before determination 252 of signatures and authorization. Such determination may take a 253 substantial amount of time. 255 To improve performance, an implementation can cache the public 256 keys for the issuers that frequently sign end-user certificates. 257 These cached public keys can be used to verify the final 258 certificate, and avoid the cost of verifying each certificate in 259 the chain. 261 2.0.3. Send Secret_Response 263 The Secondary chooses an appropriate (optional) Identification, the 264 PSI and PSILT, generates an appropriate Secret-Value for the 265 Secret_Request Identity-Choice, calculates the Verification, and 266 masks the message using the Privacy-Method indicated by the current 267 Scheme-Choice. 269 2.0.4. Receive Secret_Response 271 The Primary validates the pair of Cookies, the Padding, the 272 Verification, the Secret-Value, and the (optional) Identification. 274 - When an invalid/expired cookie is detected, the message is 275 silently discarded. 277 - After unmasking, when invalid Padding is detected, or the 278 Verification format is invalid, or the Secret-Value format is 279 invalid, the message is silently discarded. 281 - When the message verification fails, or an invalid Identification 282 format is detected, or external signature validation fails, or 283 other authorization policy failures are indicated, a 284 Verification_Failure message is sent. 286 - Whenever such a problem is detected, the Security Association is 287 not established; the implementation SHOULD log the occurance, and 288 notify an operator as appropriate. 290 - Once a valid message has been received, later Secret_Responses 291 with both matching cookies are also silently discarded, until a 292 new Cookie_Request is sent. 294 When the message is valid, the Primary sends an appropriate 295 Identification Message. 297 Implementation Notes: 299 Validation of message formats MUST take place before determination 300 of signatures and authorization. Such determination may take a 301 substantial amount of time. 303 To improve performance, an implementation can cache the public 304 keys for the issuers that frequently sign end-user certificates. 305 These cached public keys can be used to verify the final 306 certificate, and avoid the cost of verifying each certificate in 307 the chain. 309 2.1. Secret_Request 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | | 313 ~ Initiator-Cookie ~ 314 | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | | 317 ~ Responder-Cookie ~ 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Message | LifeTime | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Party-Secret-Index | 323 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 324 | | 325 ~ Verification ~ 326 | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Identity-Choice | | 329 + + + + + + + + + + + + + + + + + + 330 | | 331 ~ Identification ~ 332 | | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 ... Padding | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Initiator-Cookie 16 bytes. Copied from the Value_Request. 339 Responder-Cookie 16 bytes. Copied from the Value_Request. 341 Message 6 343 LifeTime 3 bytes. The number of seconds remaining before 344 the indicated PSI expires. The value zero 345 indicates that the PSI is used for only this 346 Identification Exchange. 348 Party-Secret-Index (PSI) 349 4 bytes. The PSI to be used for this party in 350 the Identification Exchange. The value MUST NOT 351 be zero. 353 Verification Variable Precision Integer, or other format 354 indicated by the current Scheme-Choice. The 355 calculation of the value is described in 356 "Integrity Verification". 358 The field may be any integral number of bytes in 359 length. It does not require any particular 360 alignment. The 32-bit alignment shown is for 361 convenience in the illustration. 363 Identity-Choice 2 or more bytes. An identity attribute is 364 selected from the list of Offered-Attributes sent 365 by the peer. 367 The field may be any integral number of bytes in 368 length, as indicated by its Length field. It 369 does not require any particular alignment. The 370 16-bit alignment shown is for convenience in the 371 illustration. 373 Identification Variable Precision Integer, or alternative format 374 indicated by the Identity-Choice. See the 375 "Additional Attributes" for details. 377 The field may be any integral number of bytes in 378 length. It does not require any particular 379 alignment. The 32-bit alignment shown is for 380 convenience in the illustration. 382 Padding 8 to 255 bytes. This field is filled up to at 383 least a 128 byte boundary, measured from the 384 beginning of the message. The number of pad 385 bytes are chosen randomly. 387 In addition, when a Privacy-Method indicated by 388 the current Scheme-Choice requires the plaintext 389 to be a multiple of some number of bytes (the 390 block size of a block cipher), this field is 391 adjusted as necessary to the size required by the 392 algorithm. 394 Self-Describing-Padding begins with the value 1. 395 Each byte contains the index of that byte. Thus, 396 the final pad byte indicates the number of pad 397 bytes to remove. For example, when the unpadded 398 message length is 120 bytes, the padding values 399 might be 1, 2, 3, 4, 5, 6, 7, and 8. 401 The portion of the message after the PSI field is masked using the 402 Privacy-Method indicated by the current Scheme-Choice. 404 The fields following the PSI are opaque. That is, the values are 405 set prior to masking (and optional encryption), and examined only 406 after unmasking (and optional decryption). 408 2.1.1. Integrity Verification 410 The Secret_Request is authenticated using the Validity-Method 411 indicated by the current Scheme-Choice. The Verification value is 412 calculated prior to masking (and optional encryption), and 413 verified after unmasking (and optional decryption). 415 The Validity-Method authentication function is supplied with two 416 input values: 418 - the integrity-key, 419 - the data to be verified (as a concatenated sequence of bytes). 421 The resulting output value is stored in the Verification field. 423 The Scheme-Choice specified Key-Generation-Function is used to 424 create a special integrity-key. This function is calculated over 425 the computed shared-secret. 427 The verification data consists of the following concatenated 428 values: 430 + the Initiator Cookie, 431 + the Responder Cookie, 432 + the Message, LifeTime and PSI fields, 433 + the Identity-Choice and Identification, 434 + the Padding. 436 Implementation Notes: 438 The exact details of the Identification included in the 439 Verification calculation are dependent on the corresponding 440 Identity-Choice. 442 Failure to find an Identification in either an internal or 443 external database results in the same Verification_Failure 444 message as failure of the verification computation. 446 2.2. Secret_Response 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 ~ Initiator-Cookie ~ 451 | | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | | 454 ~ Responder-Cookie ~ 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Message | LifeTime | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Party-Secret-Index | 460 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 461 | | 462 ~ Verification ~ 463 | | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | | 466 ~ Secret-Value ~ 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | (Identity-Choice) | | 470 + + + + + + + + + + + + + + + + + + 471 | | 472 ~ (Identification) ~ 473 | | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 ... Padding | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Initiator-Cookie 16 bytes. Copied from the Secret_Request. 480 Responder-Cookie 16 bytes. Copied from the Secret_Request. 482 Message 5 484 LifeTime 3 bytes. The number of seconds remaining before 485 the indicated PSI expires. The value zero 486 indicates that the PSI is used for only this 487 Identification Exchange. 489 Party-Secret-Index (PSI) 490 4 bytes. The PSI to be used for this party in 491 the Identification Exchange. The value MUST NOT 492 be zero. Also, the value SHOULD NOT equal the 493 PSI from the Secret_Request. 495 Verification Variable Precision Integer, or other format 496 indicated by the current Scheme-Choice. The 497 calculation of the value is described in 498 "Integrity Verification". 500 The field may be any integral number of bytes in 501 length. It does not require any particular 502 alignment. The 32-bit alignment shown is for 503 convenience in the illustration. 505 Secret-Value Variable Precision Integer, or alternative format 506 indicated by the Secret_Request Identity-Choice. 507 Used for calculating a pair of symmetric secret- 508 keys between the parties. 510 The field may be any integral number of bytes in 511 length, as indicated by its Size field. It does 512 not require any particular alignment. The 32-bit 513 alignment shown is for convenience in the 514 illustration. 516 (Identity-Choice) 517 2 or more bytes. An identity attribute is 518 selected from the list of Offered-Attributes sent 519 by the peer. 521 This field may be omitted. See "During 522 Identification Exchange". 524 The field may be any integral number of bytes in 525 length, as indicated by its Length field. It 526 does not require any particular alignment. The 527 16-bit alignment shown is for convenience in the 528 illustration. 530 (Identification) Variable Precision Integer, or alternative format 531 indicated by the Identity-Choice. See the 532 "Additional Attributes" for details. 534 This field may be omitted. See "During 535 Identification Exchange". 537 The field may be any integral number of bytes in 538 length. It does not require any particular 539 alignment. The 32-bit alignment shown is for 540 convenience in the illustration. 542 Padding 8 to 255 bytes. This field is filled up to at 543 least a 128 byte boundary, measured from the 544 beginning of the message. The number of pad 545 bytes are chosen randomly. 547 In addition, when a Privacy-Method indicated by 548 the current Scheme-Choice requires the plaintext 549 to be a multiple of some number of bytes (the 550 block size of a block cipher), this field is 551 adjusted as necessary to the size required by the 552 algorithm. 554 Self-Describing-Padding begins with the value 1. 555 Each byte contains the index of that byte. Thus, 556 the final pad byte indicates the number of pad 557 bytes to remove. For example, when the unpadded 558 message length is 120 bytes, the padding values 559 might be 1, 2, 3, 4, 5, 6, 7, and 8. 561 The portion of the message after the PSI field is masked using the 562 Privacy-Method indicated by the current Scheme-Choice. 564 The fields following the PSI are opaque. That is, the values are 565 set prior to masking (and optional encryption), and examined only 566 after unmasking (and optional decryption). 568 2.2.1. Before Identification Exchange 570 When the Secret Exchange occurs before the Identification 571 Exchange, the optional Identity-Choice and Identification fields 572 are included in the Secret_Response. 574 The subsequent Identification_Request is modified. The 575 Identification field is replaced by a Secret-Value field. (The 576 Identity-Choice field remains in place.) 578 The derived Primary Secret Identity is used internally instead of 579 the usurped Identification field, with the associated Primary 580 secret-key. 582 The derived Secondary Secret Identity MUST be used in the 583 Identification_Response, with the associated Secondary secret-key. 585 2.2.2. During Identification Exchange 587 When the Secret Exchange occurs during the Identification 588 Exchange, the optional Identity-Choice and Identification fields 589 are excluded from the Secret_Response. 591 Instead, the values are taken from the Identification_Request, and 592 the secret-nonce is the associated generation-key. 594 The derived Primary Secret Identity MUST be used in the 595 Identification_Response, with the associated Primary secret-key. 597 The derived Secondary Secret Identity is unused in this exchange, 598 but MAY be used in a later exchange. 600 2.2.3. Integrity Verification 602 The Secret_Response is authenticated using the Validity-Method 603 indicated by the current Scheme-Choice. The Verification value is 604 calculated prior to masking (and optional encryption), and 605 verified after unmasking (and optional decryption). 607 The Validity-Method authentication function is supplied with two 608 input values: 610 - the integrity-key, 611 - the data to be verified (as a concatenated sequence of bytes). 613 The resulting output value is stored in the Verification field. 615 The Scheme-Choice specified Key-Generation-Function is used to 616 create a special integrity-key. This function is calculated over 617 the following concatenated values: 619 + the Secret_Request Verification field, 620 + the computed shared-secret. 622 The verification data consists of the following concatenated 623 values: 625 + the Initiator Cookie, 626 + the Responder Cookie, 627 + the Message, LifeTime and PSI fields, 628 + the Secret-Value, 629 + the Identity-Choice and Identification (optional), 630 + the Padding. 632 If the verification fails, the users are notified, and a 633 Verification_Failure message is sent, without adding any PSI 634 identities. On success, normal operation begins with the 635 remainder of the Identification Exchange. 637 The Secret Exchange depends upon the Identification Exchange for 638 ultimate verification. When later verification fails, the PSI 639 secret-keys MUST be discarded. 641 Implementation Notes: 643 The exact details of the Identification and Secret-Value 644 included in the Verification calculation are dependent on the 645 corresponding Identity-Choices. 647 Failure to find an Identification in either an internal or 648 external database results in the same Verification_Failure 649 message as failure of the verification computation. 651 2.3. Secret-Nonce 653 A secret-nonce is formed as indicated by the Identity-Choice and 654 Identification specified in the Secret_Request (and optionally in 655 the Secret_Response). 657 Asymmetric Identity Attribute 659 The Secret-Value contains the nonce encoded by the specified 660 public-key. 662 Symmetric Identity Attribute 664 The Value part of the Secret-Value is concatenated to (followed 665 by) the existing symmetric secret-key. 667 Regardless of the internal representation of the secret-nonce, 668 when used in calculations it is in the same form as the Value part 669 of a Variable Precision Integer: 671 - most significant byte first. 672 - bits used are right justified within byte boundaries. 673 - any unused bits are in the most significant byte. 674 - unused bits are zero filled. 676 The secret-nonce does not include a Size field. 678 2.4. Secret-Key Computation 680 Each pair of PSI values is used to generate a corresponding pair 681 of symmetric secret-keys (one for each party). 683 The Scheme-Choice specified Key-Generation-Function is used to 684 create the secret-key for each party. This function is calculated 685 over the following concatenated values: 687 + the Initiator Cookie, 688 + the Responder Cookie, 689 + the Owner Message, LifeTime and PSI, 690 + the Peer Message, LifeTime and PSI, 691 + the Owner secret-nonce, 692 + the Peer secret-nonce, 693 + the computed shared-secret. 695 Since the order of the Owner and Peer fields is different in each 696 direction, the resulting secret-key will usually be different in 697 each direction. 699 2.5. Secret Identities 701 The pair of PSI values also identifies the secret-keys. These 702 identities can be used with a symmetric identity attribute in any 703 subsequent Identification message. 705 The Primary identity is the Secret_Request PSI value, concatenated 706 to (followed by) the Secret_Response Verification value. The 707 Secret_Request LifeTime is used as the LifeTime. 709 The Secondary identity is the Secret_Response PSI value, 710 concatenated to (followed by) the Secret_Response Verification 711 value, concatenated to (followed by) the Secret_Request PSI value. 712 The Secret_Response LifeTime is used as the LifeTime. 714 3. Additional Attributes 716 The attribute format and basic facilities are already defined for 717 Photuris [RFC-2522]. 719 These optional attributes are specified separately, and no single 720 implementation is expected to support all of them. 722 Nota Bene: Support is always required for the [RFC-2522] 723 "MD5-IPMAC" (#5) attribute for the Secret_Request Identity-Choice. 725 This document defines the following values: 727 Use Type 728 I 27 DNS Key RR 729 I 28 OpenPGP 730 I 29 X.509 732 I Identity-Choice 734 3.0.1. Authentication 736 These attributes are never used as an AH or ESP Attribute-Choice. 738 3.0.2. Verification 740 These attributes are never used for [RFC-2522] "Identity 741 Verification" or "Validity Verification". Instead, the Secret 742 Exchange occurs to associate a pair of symmetric secrets with the 743 Identification. 745 3.1. DNS Key Resource Record 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Attribute | Length | Power | Algorithm | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 Attribute 27 753 Length 2 755 Power 1 byte. The public/private-key bits supported, 756 expressed as a power of two. 758 When listed as an Offered-Attribute, the Power is 759 set to the maximum supported. As a minimum, all 760 implementations MUST support value 10 (1024-bit 761 keys). 763 When selected as an Attribute-Choice, the Power 764 is set to the actual value to be used. 766 Algorithm 1 byte. An algorithm supported. See [RFC-2535] 767 for details. 769 Examples include: 771 1 [RFC-2537] RSA with MD5. 772 3 [RFC-2536] DSA with SHA1. 774 When more than one Algorithm is supported, 775 multiple attributes are listed in the Offered- 776 Attributes. 778 When this attribute is implemented, [RFC-2535] requires support 779 for Algorithm #3 [RFC-2536], which SHOULD be present in every 780 Offered-Attributes list. 782 3.1.1. Asymmetric Identification 784 When selected as an Identity-Choice, the immediately following 785 Identification field contains the binary form of the DNS Key 786 Resource Record. The domain name is fully expanded (no name 787 compression via pointers). 789 Any Key RR that is available for authentication (the 790 Authentication flag bit is clear) MAY be used. Currently, no 791 specific Key Protocol value has been defined for Photuris. It is 792 recommended that DNSSEC (#3), email (#2), and TLS (#1) keys be 793 used in preference to Oakley/IPSEC (#4) keys that are specific to 794 another session-key management protocol. 796 No DNS Signature Resource Records are included with the 797 Identification. Valid Identifications and corresponding signature 798 certificates are preconfigured by the parties, or maintained in 799 external databases. 801 The Identification value is not contained within a Variable 802 Precision Integer (VPI). The Key RR elements are parsed by the 803 implementation to determine the end of the Identification field. 805 The returned Secret-Value consists of a nonce encoded by the 806 specified public-key, of the form determined by the DNS Key 807 algorithm. The result is contained within a Variable Precision 808 Integer (VPI). 810 3.2. OpenPGP Identification 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Attribute | Length | Power | Version ... 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 ... | 816 +-+-+-+-+-+-+-+-+ 818 Attribute 28 820 Length 3 822 Power 1 byte. The public/private-key bits supported, 823 expressed as a power of two. 825 When listed as an Offered-Attribute, the Power is 826 set to the maximum supported. As a minimum, all 827 implementations MUST support value 10 (1024-bit 828 keys). 830 When selected as an Attribute-Choice, the Power 831 is set to the actual value to be used. 833 Version 2 bytes. A Public Key Packet version supported. 834 See [RFC-2440] for details. 836 Versioning is complicated by the number of 837 algorithms supported. For negotiation, the 838 version and algorithm combinations are treated as 839 a single quantity. 841 Examples include: 843 0x0301 RSA in PGP 2.6.x. 844 0x0401 RSA in PGP 5.x. 845 0x0403 RSA in PGP 5.x, signature only. 846 0x0411 DSA in PGP 5.x. 847 0x0414 ElGamal in PGP 5.x, encrypt or sign. 849 When more than one Version is supported, multiple 850 attributes are listed in the Offered-Attributes. 852 When this attribute is implemented, [RFC-2440] requires support 853 for Version #0411, which SHOULD be present in every Offered- 854 Attributes list. 856 Due to the widespread use of PGP 2.6.x, this specification also 857 recommends support for Version #0301. 859 3.2.1. Asymmetric Identification 861 When selected as an Identity-Choice, the immediately following 862 Identification field contains a PGP "Public Key Packet". 864 PGP "User ID Packet", "Signature Packet", or sub-packet elements 865 MUST NOT be included in the Identification. Valid Identifications 866 and corresponding signature certificates are preconfigured by the 867 parties, or maintained in external databases. 869 The Identification value is not contained within a Variable 870 Precision Integer (VPI). The PGP elements are parsed by the 871 implementation to determine the end of the Identification field. 873 The returned Secret-Value consists of a nonce encoded by the 874 specified public-key, of the form determined by the OpenPGP 875 algorithm. The result is contained within a Variable Precision 876 Integer (VPI). 878 Nota Bene: 880 The PGP Multi-Precision Integer (MPI) is very similar to the 881 Variable Precision Integer (VPI). However, the Size field is 882 not extensible, and PGP library functions truncate leading 883 significant zeroes. 885 3.3. X.509 Identification 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Attribute | Length | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 Attribute 29 893 Length 0 895 Future extensions to this attribute may add 896 parameter values. This will be indicated by a 897 non-zero value. 899 3.3.1. Asymmetric Identification 901 When selected as a Identity-Choice, the immediately following 902 Identification field contains an X.509 "TBSCertificate", 903 conforming to the profile specified in [RFC-2459]. 905 Full X.509 certificates with signatures MUST NOT be included in 906 the Identification. Valid Identifications and corresponding 907 signature certificates are preconfigured by the parties, or 908 maintained in external databases accessed by [RFC-2510 and 909 RFC-2511]. 911 The Identification value is not contained within a Variable 912 Precision Integer (VPI). The X.509 elements are parsed by the 913 implementation to determine the end of the Identification field. 915 The returned Secret-Value consists of a nonce encoded by the 916 specified public-key, of the form determined by the 917 subjectPublicKey algorithm. The result is contained within a 918 Variable Precision Integer (VPI). 920 A. DSA Secret-Value 922 When using asymmetric public/private-key identities, this protocol 923 requires the passing of a nonce encoded by the specified public- 924 key. While this has a natural fit with RSA, DSA was not intended 925 for public-key encryption of random values. 927 However, it is possible to use the DSA parameters, bypassing the 928 signature function, given a sufficiently generic programming 929 interface. A brief description can be found in [Schneier95]. 931 Using the OpenSSL library, 933 Operational Considerations 935 Each party configures a list of known identities and validation 936 certificates. 938 In addition, each party configures local policy that determines 939 what access (if any) is granted to the holder of a particular 940 identity. For example, the party might allow anonymous FTP, but 941 prohibit Telnet. Such considerations are outside the scope of 942 this document. 944 Security Considerations 946 Keys retrieved from external sources should not be trusted without 947 independent verification by the party. 949 When using asymmetric public/private-key identities, it is 950 possible that an active interception and modification attack 951 (sometimes called "Monkey in the Middle" or MITM) will use 952 entirely valid certificates. Operators should be suspicious when 953 the peer identities are all certified by a single entity, such as 954 the regional security agency equivalent. This attack can only be 955 prevented through rigorous authorization policy enforcement. 957 Acknowledgements 959 William Simpson was responsible for the packet formats, additional 960 message types, editing and formatting. 962 Robert W Baldwin provided text for X.509 Certificates and other 963 implementation details. 965 Steven Bellovin suggested enhancing existing symmetric secret-keys 966 with greater entropy. 968 Hilarie Orman suggested adding secret "nonces" to session-key 969 generation for asymmetric public/private-key identity methods. 971 References 973 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 974 Requirement Levels", BCP 14, Harvard University, March 975 1997. 977 [RFC-2440] 979 [RFC-2459] 981 [RFC-2510] 983 [RFC-2511] 985 [RFC-2522] Karn, P., and Simpson, W., "Photuris: Session-Key 986 Management Protocol", March 1999. 988 [RFC-2535] 990 [RFC-2536] 992 [RFC-2537] 994 [Schneier95] 995 Schneier, B., "Applied Cryptography Second Edition", 996 John Wiley & Sons, New York, NY, 1995. ISBN 997 0-471-12845-7. 999 Contacts 1001 Comments about this document should be discussed on the 1002 photuris@adk.gr mailing list. 1004 Questions about this document can also be directed to: 1006 William Allen Simpson 1007 DayDreamer 1008 Computer Systems Consulting Services 1009 1384 Fontaine 1010 Madison Heights, Michigan 48071 1012 wsimpson@UMich.edu 1013 wsimpson@GreenDragon.com (preferred) 1015 Full Copyright Statement 1017 Copyright (C) William Allen Simpson (1995,1998-1999). All Rights 1018 Reserved. 1020 This document and translations of it may be copied and furnished 1021 to others, and derivative works that comment on or otherwise 1022 explain it or assist in its implementation may be prepared, 1023 copied, published and distributed, in whole or in part, without 1024 restriction of any kind, provided that the above copyright notice 1025 and this paragraph are included on all such copies and derivative 1026 works. However, this document itself may not be modified in any 1027 way, except as required to translate it into languages other than 1028 English. 1030 This document and the information contained herein is provided on 1031 an "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, 1032 EXPRESS OR IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY 1033 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1034 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR 1035 A PARTICULAR PURPOSE.